Archive

Archive for December, 2008

Why is software hard?

December 23rd, 2008 No comments

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….

Time Off

December 17th, 2008 No comments

After over 20 years of software development, 15 of it contracting, I’m going to take a bit of time off. Tomorrow is my last day at Cochlear where I lead a team over the last 2 years building myCochlear.com. After that, its a move up to Noosa where I plan to take a year off, spending lots of time with my wife and kids. Hoping to build some apps for the iphone too, and maybe a website or two. I’ve got to have something to do on those rainy days.

Funny design

December 3rd, 2008 No comments