Forgive them, for they know not what they are doing..

I am currently working with a great customer, and the people around me are reasonably sharp and have done a pretty good job of the development given the organisational constraints they faced. I’m trying to “fly the agile flag” around the group, and haven’t really had much success at present. It’s not because they’re bad, or stupid, if anything it’s the opposite, they just can’t see how a Domain Model (in particular) and software can grow as new requirements are bought into play. They can’t see how doing the simplest thing leads to more flexible designs that allow the software to be come malleable and more easily changed. They can’t see how a system can be built without a large up front planning and design exercise so you can “work out all the problems”.
But I persist, and I do really like asking questions about their designs, especially when they are puzzling over how to change things. I had a couple of pretty good conversation the other day and it went along these lines.

So, why is this allocation scheme built this way ? Surely it would have been easier to just store each allocated number in a separate row, rather than this bitmap
That’s so we didn’t have any performance problems later on
Oh, but this only works if your allocation is contiguous, is that what really happens ?
No. It would have been much easier to build it the other way, and easier to debug

and then later on:

Why do you persist all your objects this way ?
That’s because we thought we’d need this additional functionality
Did you ?
No. It would have been much, much simpler and easier to build it the other way.

So, after spending a significant time up front doing design and analysis activities. They were still wrong. How often do you make the same mistakes on your projects ? All I ask is, give it a go. Try to get away by only designing and building what you know is needed, and build your software so that it is malleable enough to accomodate the features should they become required. This isn’t an appeal to do no design, or architecture, or more importantly thinking. Edmund Blackadder had it right, “I think thinking is very important Baldric”.


Eclipse 3.0 M9 – The story so far

Being the early adopter that I am, I’ve installed and upgraded my workspaces to Eclipse M9. It was relatively painless and what’s even better they appear to have the emacs keybindings working properly. Yay!
However, there are 2 things that I’ve noticed that suck, and one thing that’s just a bit ooky.

  1. The “Perspective Switcher” which has moved to the top right corner, running horizontally has the option to move to the left, running vertically (as with last time) via a dropdown. Using the dropdown, the switcher moves to the left, but when you restart Eclipse, it is back to the top right.
  2. My Checkstyle plugin no longer works. This really sucks. I upgraded to the latest version from sourceforge (I’m using eclipse-cs) and that didn’t help. I deleted everything, I deleted my workspace, I deleted any hope of caches surviving and it just doesn’t load. My Simian, Metrics and DBEdit plugins all work just fine. Anybody got a clue on this one ?
  3. The scrolling in the line numbers has a noticeable lag. When you move around the file you are editing, the line numbers don’t update until after a delay. It’s not really a major suck, but it is ooky.

I’d give this release a “Coming second in the 100m at High School Athletics” on the Sid and Nancy Scale.
UPDATED: Thanks to Matt and his comment, I’ve got checkstyle working. Yay!. Any plugins that require Xerces will no longer load, so what I did was to drop the org.apache.xerces.* that came with M7 (I didn’t use M8) into my local plugins directory, and everything worked just fine.
Minor Update: I’ve got it mirrored here: which should be significantly faster for most Australia users.

Building Alien Artifacts

I work for a consulting organisation which specialises in solving hard problems and working with in house development teams to transform the way that software development teams work. I haven’t always worked there, and this particular blog isn’t solely about my experiences with ThoughtWorks, but a general observation about working with other people.
One of the things that I worry about is a behaviour which I shall call “building alien artifacts“. This is where an external team (it may be external consultant, or in-house people, or even just senior people within the same department) help build a project in a manner that the incumbent team cannot fathom, maintain or update safely. Essentially an alien has dropped this highly useful, well built device into your lap, and if you press the wrong button, or combination of buttons, it’s likely to explode or at the very least give you a nasty shock. To reinforce what I’m talking about here, the aliens have built a good system, not some piece of crap that can’t be maintained, but the how and why is beyond the capabilities of the team who must take it over.
To me, this is an important part of working with other teams of people. I don’t want to leave people with an alien artifact, I want to leave them with something they can understand, tinker with and improve in safety. I do want to stress that this isn’t a function of absolute experience, or absolute skill, as the same effect occurs if a “database guy” develops a bunch of stored procedures or a data model that the development team doesn’t have the ability to work with. Both groups (database and development team) may have equivalent skill level in their domain, but the effect is the same, the development team ends up with an alien artifact.
Now that I’ve described the situation, what do we do about it ?
The most important thing is to talk to the team and understand where there strengths and weaknesses are. It’s never been my observation that the teams that I’ve worked with in this situation are raving lunatics that should be taken out and shot, they’re generally reasonable quality, hard working developers that know a certain amount of stuff about various things.
After you understand what the team is like, the next thing to do is to understand what can be done. Can we improve the skill levels to the point that might be required, or do we have to look at building a solution that is relevant to the team.
Generally it’s not a binary choice, but there is somewhere in between that is the right place. Sometimes organisations want to embrace change, organisations that have a culture of excellent, or a desire to grow their people are great at pushing the envelope. Sadly there are organisations that resist change, and this is where it’s important to not let enthusiasm for developing a fantastic system get in the way of understanding the sort of legacy you will be leaving behind. All the unit tests, checkstyle rules, jdepend controls that have helped during development will slowly be dismantled after you leave if the incumbents do not understand what’s going on. The project will become brittle and fail. Maintenance will become harder and harder.
Sadly, I’ve come across far too many people with the view of “well, screw them if they’re too stupid to keep it working”. Everybody who works as a consultant, or as an advisor, or as a mentor to teams needs to understand the legacy they are leaving and while they’re working on these projects need to continually ask the question, “Am I leaving an alien artifact as a legacy ?”
If you do, then that’s your fault, and not the fault of the team unfortunate enough to be left with the results.

Neat feature in MT-Blacklist

I just noticed that if you have enabled comment/trackback email in MT and you’ve installed MT-Blacklist, then the emails will have a direct link in the footer to enable you to clean up the comment directly.
That really rocks. Thank you Jay Allen.

Camelot, Camelot, Camelot ! It’s only a model…..

A frequent confusion about Agile/Iterative development in general and XP in particular is surrounding the cultural clash of up front modelling and incremental development of the data/domain model. Cries of “How can it possibly work?” and “I’m sure that they’ll never be able to handle anything complicated without modelling”. I don’t wish to deny people the right to believe what they want, because they’ve probably got years of “doing it this way” and the cultural shift is hard for people to take.
Sadly, most of the time I hear these cries, I look at the code, or run some metrics tools over the code and it’s a load of crap. Quite often the model is clean, well considered, but the implementation is unmitigated rubbish. I’m sure there are people that can predict exactly how the application shall be modelled, and have enough experience in development to know how that will translate to code and do a great job. Those people appear to be very thin on the ground.
However what I have noticed is that developers who use TDD as a development technique as a way of incrementally growing the domain model develop substantially better code than systems that have been developed using a modelling tool up front (think Rational Rose, XDE) and then coded. This is a result of both qualitative and quantitative observations.
Why ? Well, I don’t really know, but I’d guess that it has to do with the following quote I heard from Jason Yip.
No plan for combat survives first contact with the enemy
A modelling tool is planning for implementation. It’s planning the code, it’s working out how stuff should be implemented. It’s not actually doing the work. It’s not until you actually write the code and have the environment impact on your code, and your fellow workmates impact on the code and the customer changes the focus that you really know what you’re going to build. What’s more, there appears to be a “we modelled it up front, so there is no need to re-evaluate the decisions” to this sort of development. Incremental development techniques are constantly working on the code and revisiting decisions. There is constant review and validation of decisions, rather than a single, up front guess.
So, while I think it’s possible to specify a system using a modelling tool and have that model implemented in code and have this occur successfully, I don’t think it’s something that should be seen as a desirable mechanism for building software. This is mostly due to the human factors involved. If people think that the “design is done” as a result of the modelling, then what remains is just to type the code, and sadly it appears that people will park their brains at the door and development will proceed poorly. If the development team can manage to continually revisit the design decisions and validate the progress by way of metrics and reviews then I believe that the results can be sucessful.
To the claims of “Modelling is the only way to develop complicated software”, well, I think the French Knight said it best, “I fart in your general direction, now go away before I taunt you a second time.”