Keep It Simple (Stupid)

Do we sometimes try to make things overcomplicated for the sake of it?

As I've said, revisiting Michael J. Pont's book on Software Engineering, he starts out that software is complex.  But the only way to work with it, it to break it down and manage it as a number of smaller, simpler components.

If those components are still too complex, then maybe they need to be broken down into even smaller parts.

There is a certain elegance in simplicity.  If you look at Apple products (and I'm not one of Apples biggest fans) I will concede their products do have elegance, and an ease/simplicity to them.  It's no wonder so much of the industry look to them as setting the style of products.

In Agile too, there is a drive by using stories and slices of functionality to try and keep what's being worked on very simple.

But why?  Simple concepts are easier to understand, manage, develop and test.  Simple is good.


But when it comes to communication and documentation?  What then?

I used to have a certain amount of jealousy when I read some other people's work – their writing would feel more professional than mine.  They'd use big words, which I'd often not really understand.  And it would be impressive.

But my style was much more down to earth, and much plainer.  I then did a night course in history, where my tutor explained to the class how a historical papers used to be submitted, and they almost got extra marks for being difficult to read.  But there had been a recent fashion to keep the English much more plain and contemporary, because it made the arguments much easier to follow and made the work so much more accessible.

I know I've worked on projects where I've read huge documents of requirements, and have a “Eureka!” moment when I actually realise what they're actually saying.  That happened on the last project – I was on there first, and I a peer tester was brought in, and made to read the same requirements as me.

At the end of the day he said he'd had trouble with the document, and didn't really understand it.  I managed to sum it up for him in about 2-4 sentences of explanation.

Although I'm not an Agilist, I'm coming to the end of this, and realising how much I'm getting there.  If something can be summed up in a couple of paragraphs of explanation, why not do it that way?  Why develop so much documentation, that it's overly complex and unreadable?

We do as an industry - be it manager, analyst, developer, tester – have a fetish for trying to complicate things, primarily through the fear that simplification will diminish the value of what we do.

Take heed from Apple – keeping things simple but elegant doesn't mean they're not of value …  People value what Apple does because they manage their solutions to keep them simple, and that takes skill and ability.  And as anyone knows any Apple product that looks so simple, does not come cheap ...