A.K.A. The Version 3.0 Myth. A.K.A. The Rewrite Myth.

I recently overheard a developer telling his manager a variant of what I call “The Version 2.0 Myth”, it went something like this:

If I could write this module again it would be half the size and so much faster… It would be worth doing just to fix all the bugs

Sensibly, his manager didn’t take him up on the this idea; this promise which seems to persist in development circles of a mythical “Version 2.0” that delivers improved efficiency, cleaner code and no bugs.

I’ve also heard it as the Version 3.0 Myth, where Version 1.0 is ugly and buggy, the second version is over-engineered and the 3rd… the 3rd is a masterpiece of software craftsmanship!

Here’s why it’s never so…

Continue reading →

We’re regularly told to keep things simple; to produce simple designs, to keep your application “globally simple”, to reduce complexity. But it can often seem as if simplicity is itself a goal, regularly quoted as best practice without explanation. So what should it mean in practice and how can the “simplest solution” be achieved?

I believe the origins of this quest for simplicity lie in Extreme Programming’s (XP) suggestion that we produce “The simplest design that could possibly work” (based on the subjective TUBE qualities of simple code design). It’s great but rather vague advice which is regularly used as a justification for pedestrian solutions, never ending “refactorings” and both naive and, ironically, over complicated designs.

There is an excellent chapter in “Extreme Programming Explained” (Ken Auer, Roy Miller) all about this idea, unfortunately I’ve been unable to find it online but you will certainly not regret buying the book. In it Ken Auer explains:

Simple Design Can Be a Business Decision

And it is this focus on involving the customer that is too often ignored. Here’s an example from a recent project:

Continue reading →