Traps Developers fall into #1 - Flexibility Bloat

I thought it would interesting to write about some of the traps developers frequently fall into. Hopefully, reading these articles you'll be able to avoid these development pitfalls.

In software development there is always a tradeoff between flexibility and complexity. When you're designing a component to be flexible you need to think about all the possible cases where you might want to use the component in the future. Rather than just writing a date you would create a date object. It's clear that this kind of abstraction will lead to more lines of code. It's also clear that, if well written, this new date object will be re-usable in other projects. As the date object develops it will become more flexible incorporating new date formats until it becomes a 1,000MB juggernaut like the Drupal date module.

I'm not saying that flexibility and re-usability are bad. In this article I'm going to highlight the importance of keeping things in perspective.

Lets look at real world example. Lets say that I'm buying a car which I'm going to use to drive to the shops and back. A small cheap car could do this for $10,000. But wait! Since I'm buying a car, and since I'm spending $10,000, I should probably think of other scenarios where I might use the car. What if I have a family - then I'd need a family sized car. And, what if I decide I want to go touring in South America. Then I'd need a 4x4 with air conditioning. Ok, while I'm buying a 4x4 I might as well buy one with a winch and snorkel for fording rivers and seven extra tyres in case I get stranded in the desert… This is obviously ridiculous in real life so why do developers do something similar in software?

I need a text box… Well I should really think about the future. The text box is going to be part of a form and I don't want to have to type out the text box every time! I'll create a Form and TextBox will be a sub element. I'll have a weighting for the text box which determines it's position in the form. The name of the text box will be mapped to the database field. I'll create builder method to create the form from an XML document which I can create in my form builder application… Which I'll write! That way I won't have to do any coding to create my forms.

I know this is a bit over the top but it really does happen. For some reason, lots of developers have a kind of phobia for writing boilerplate code. They prefer to write a thousand line form manager class than spend half an hour writing out a form manually.

I spent some time working for a technology company. Their main product was a piece of software written in an ancient programming language from the 70s. The code editor for this language was a green on black terminal screen and was originally designed to accept code from punch cards!

The company wanted to update their software to run on Windows. The developers were very enthusiastic and clever. One of them knew Delphi they they wanted to crack on so decided to write it in Delphi. Being very intelligent they wanted to write an extremely elegant program. They abstracted EVERYTHING! The code was full of adapters and bridges and contexts. They wrote a clever piece of software to handle database mappings via XML config files. It was all very complicated and very clever. The problem? It was a nightmare to maintain. Only about two people in the company know how the whole thing worked. The second problem is that it wasn't future proof. After 5 years the Delphi interface was looking a bit tired and XPish. In the end, the company decided to scrap the framework and start again in Java. The original developers had been so excited about architecting an elegantly complex object orientated beast that they didn't see the wood for the trees and had lost sight of the most important thing. The business case. Was it worth spending 500,000 man hours to write a piece of software which was only going to be used with two clients? In retrospect, maybe they should have written a less flexible, less complex program which would have taken half the time.

So what's the moral? Generally, flexibility is good bit it's important to keep the things in perspective. There's always a tradeoff. Flexibility comes with complexity. That means more lines of code and a program which is harder to understand. It is quicker to write less flexible code. It only becomes more efficient to write flexible code if you're going to use the flexibility.

For example, to build one chair it's cheaper to do it by hand. To build 100 chairs a days it's worth investing in machinery to make the job easier. Don't fall into the trap of building the chair factory to manufacture one chair!

Tweet: 

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.