Designing for perfection - a fools errand

Ever heard of 2nd project syndrome? Its the concept that engineers when they have delivered a successful first project they will then tend to over engineer the next solution putting in all the bits that they wished they had done on the first project.

YAGNI is my favourite "agile" principle. Now personally I didn't realise it was agile until I was told, I'd been happily asking "why do we need that?" for years without realising it was agile, I just thought it was standard engineering. I've had some discussions recently, online and offline, where fairly smart people seem to be suffering some sort of collective brain freeze around "flexibility".

The basic argument tends to go with me asking how their solution is simple and them telling me how its flexible and will automatically adapt to change in the future. Now sometimes this requires a big bunch of intelligent coding on the client side (i.e. by someone else) but that's okay because the "service" is flexible. Pointing out that there will be multiple clients for the service so in effect its just creating more work doesn't seem to wash. Then you dig a little deeper and find out that there is a bunch of additional development being planned on the service side as well to deliver all this flexibility... with no requirements today that demand any of it.

The other bit of the argument tends to go around whether there needs to be flexibility in a given area. One conversation recently was around submitting a particular financial report and then accessing the information later. The old batch file approach wasn't cutting it (genuinely wasn't) so they wanted to replace this with a new XML/SOA/WOA/WTFA solution. There were three options.

1. Replace the batch with an XML dump (not great as just wrapped the old problem in new technologies
2. Create a single record submission approach
3. Create a fully flexible invoicing management solution

Now the correct answer was 2. but the team pushed hugely for 3 as they could do lots of cool technology and create infinite flexibility and adaptability.

Then I asked a question

there are 30 fields in the invoice, how long has that been the case

The answer was that the 30 fields, of which only 10 were normally used, had been static for about 20 years.

So what was the point of option 3?

The answer was that the developers wanted to demonstrate being technologically clever rather than business clever.

The Clifton Suspension Bridge was over engineered, but at least Brunel [corrected] still just aimed to build a bridge. Some software developers (I won't use the term engineers) seem to believe that unless the bridge can be used as a rocket ship them it isn't flexible enough. For myself I say it gets from A to B, it does what it needs to and its been there over a hundred years.

Business Effectiveness is the goal, not technological perfection.

Technorati Tags: SOA, Service Architecture