This article is based on my experience writing Java enterprise applications for the web, rich client and backend systems.
Software takes a long time to write. Way too long. Its generally much too complicated, inflexible, fragile, often doesn’t do exactly what it was meant to do and sometimes even has bugs. Why is this so?
Lets face it, software doesn’t really do much.
- It reads some data from somewhere; files, databases, sockets, screens
- It performs a bit of maths on the data; occasional complex matrix transformations but mostly just simple additions
- It executes some if-then-else statements
- It loops around a few for loops
- It writes some data somewhere; files, databases, sockets, screens
There may be a few other edge case things, but mostly its just variations on the above themes.
So why is software hard?
There are a few reasons for this, but in my experience, I think the main ones are:
Requirements
Writing software is an exact science. There isn’t normally much room for ambiguity. If your running around a for loop, you go around exactly n times. You don’t normally loop around about n times, or roughly n times.
The question is, who decides on what n should be? Ideally, there should be some requirement specifying what n should be, and why this value is needed. There doesn’t need to be a massive formal document describing this, but it should be written down somewhere – ideally somewhere where developers can find it. This business logic may be fairly fundamental to what the software is supposed to do, so its quite likely that at least these requirements will be known upfront.
The real problems start to occur when someone asks “but what happens if…?” Questions like this occur constantly during development and more often than not, they are not covered in the requirements. So, who decides what to do? Ideally it should the the client/business, but I’ve found its generally left to the developers to decide. This inevitably leads to the application not doing exactly what it was supposed to do. Not necessarily the developers fault (there was no one around to ask and I had to get it finished), but mainly because exactly what it was supposed to do was never actually specified.
Agile development practices are supposed to address this problem by having client/business representatives as part of the team and always available, but I have yet to see this actually work well in practice. I don’t believe once per day standup meetings with the client are enough. Also the client needs to be very knowledgeable in the business and have the authority, ability and courage to make decisions. I think agile development practices, if carried out how I think they should be done, end up changing the way the business/clients work more than it changes the way developers work. I think this is something that is not very well explained (especially to the client). I’m not knocking Agile (its a damn site better than waterfall!), I’m just saying that software consists of thousands of little decisions and the client should be making most, if not all of these. Otherwise, chances are, the software will not do exactly what they wanted it to do.
Too many options
To be continued….
