Software development as an engineering discipline


I'm currently working out at a customer site in Parramatta (a small city about 25 km west of Sydney). I happen to live in the Eastern suburbs of Sydney, so been spending 2 hours in traffic daily...


this means I've had a lot of time to  myself - listening to Norah Jones and pondering about all sorts of weird things...


As I drove past several magnificient bridges around Sydney, it occurred to me that the structural engineers really know how to build 'robust' things - my next thought was - are we the software architects and developers lesser beings? for building applications that don't always provide certain service quality guarantees??


So I started to think of the instances in my career path where I have seen software having reliability/robustness problems. And it striked me that they all had something in common - they were all software under unexpected load! In several instances - when I spoke to the people involved in such projects, an example comment from the developers/architects would be: “well, the application was designed to cater for 1000 users only, and over a short period of time, the application/business grew so popular, it now attracts 100,000 users, so I don't wonder why the application is no longer stable”.


Walking into the lift of the customer building - getting ready to go up to the 8th floor for the first meeting of the morning - 'beep' - too many people trying to cram into the tiny lift - a couple of people gracefully steps out of the lift, until the alarm went off, and lift proceeded to safely carry the rest of us upwards.


Perhaps we are doing a fine job of building software - I'd like to think us architects/developers are very smart beings - afterall wasn't there some academic studies that indicated programming is by far the most complex task human beings undertake? however - we probably need to start set the right expectations for the users - we need to do a better job in educating them the importance of understanding the capabilities and limitations of our software - eg. every lift I see around the place have a clear specification for the weight and recommended number of people it can carry safely at any one time - and the lift engineers don't stop there - they raise their alarm and refuse to provide the service for carrying passengers if the lift is overcrowded. As long as the 'pre-condition' of “total weight in lift is less than X” is satisfied, the lift would be happily performing the service to it's expected standard.

Comments (8)
  1. drebin says:

    I think the big difference is that since software/operating systems/languages/tools change so often – you pretty much write "what you need to" – to last you until the next "big thing".

    People who build bridges are writing them (and given the budget AND time) to build them as if they are going to be there for the next 100+ years.

    In software, we’re given neither the time nor money because that isn’t what the expectation is. There isn’t a NEED for a piece of software to work for 100 years – not even FIVE years, really!!

    For example, I was talking today about this project today. In 1999, we wrote out online offering (account balance, history, etc – I work for a brokerage firm) – and we did it right!! We had a good budget, we brought on several (competent) consultants that we could tell what to do. The design was solid – we spent just about a year designing and building it. That was probably one of the biggest and most complete projects I’ve ever worked on. And it was done proper!

    We launched it in May and by November of the same year, we ended up outsourcing out backoffice and this software we wrote was replaced by our outsourced company. It only saw 6 months of live use. And I wouldn’t say this is atypical either.

    With things like that going on – it would be foolish for management to put time, effort or money into ANYTHING long term or really robust because you just can’t count on the future – in computers. Everything changes.

  2. Mark says:

    The other problem is, rightly or wrongly, there is an expectation that it will always work. You can configure a server that if it’s too busy it simply returns a server too busy error (which can look pretty). But it’s a competitive world. People will stop coming. So things have to work. And they have to be cheap. No wonder problems happen!

  3. Patrick says:

    The advantage bridges have is that their functionality can be summarised by a tiny number of parameters – maximum load, span, height, material…. Bridge designers have 100 years or more data, gathered over hundreds or thousands of near identical structures to draw on. Further, the parameters for a bridge are known absolutely before design starts – the span is a given, the maximum required load can be reasonably estimated and the nature of the materials is well known.

    None of this holds for software – the requirements are mostly guesswork up front, programs are always meant to do something not done before (otherwise you’d just make a copy of the prior program), and the materials (language, middleware, OS) is often not well understood as it’s pretty much always new.

  4. Mac says:

    Another random thought… the same load example also translates when it comes to user input… An example, the recent IE address bar exploits or the Outlook preview exploits. Sure, we have become much better in handling such things. But there many such similar issues to be tackled.

  5. Lincoln Yeoh says:

    The real difference between civil engineering and software engineering is:

    With software engineering, the blueprint actually compiles and runs! And the company usually sells it as Version 1.0.

    Then you make the equivalent of the Plastic/Clay Model. The company sells it as Version 2.0.

    Then you make The Real Thing. The Company sells it as Version 3.0.

    Then you do some renovation to fix a number of annoying problems and cracks. That’s version 3.1.

    The other important difference is: with Software, it costs about the same to make the blueprint as it does to make the Real Thing. Same goes for the plastic and clay models.

    People can talk about all sorts of programming or project management methods, but I bet it takes a very very well drawn blueprint to beat "The Real Thing" :).

    Software would be about 3 to 4 times more expensive and take longer to do if you wanted it that reliable and robust. Who’s going to pay that much? Plus it probably takes a different type of programmer if you want the programming team to in effect do about the same thing 3 times, just better each time.

    Note: I am not a software/civil engineer.

Comments are closed.

Skip to main content