Skip to main content

Why software engineering is NOT like structural engineering

121_2While cycling home from work today I was listening to the Deep Fried Bytes episode with Rico Mariani. I should have been warned by his introduction; “He has an analogy for everything”. But since he seems to be a smart person the good old “Software engineering is just like structural engineering” caught me by surprise. I thought we ditched that one together with the waterfall process.

Usually this analogy is used to get people to do big up front design. “You wouldn’t start pouring concrete for the foundations when you don’t know how many stories your building should have” In structural engineering you need to finish a design before you start building.

But in software engineering all we do is design. Sure, in waterfall you have a design and implementation phase. But if you look more closely implementation has nothing to do with building anything. It’s design on a more detailed level, code is design too just like UML. The only thing we do that looks the slightest bit like building is deploying our software. Luckilly I’ve never seen anyone deploy software that they havent designed yet.

The forces in software design are also completely different from structural engineering. Any good software design is highly decoupled. This means that you don’t have a foundation that should change whenever another part of the “building” changes. In structural engineering you don’t have that luxury. We don’t have the technology to decouple gravity yet so every time you add to your building you’re going to need a bigger foundation.

Another reason we’re so big on decoupling is that software engineering is hard for completely different reasons than structural engineering. Complexity is a much bigger factor in software. Requirements change a lot more too. I’m not trying to say software engineering is harder in any way or that structural engineers don’t have problems with complexity or customers who change their minds. But in software engineering these things play a much bigger role. Luckilly we can handle these problems by decoupling the different parts of our design so we only have to handle the complexity of the individual components and can change around pieces if the customer needs something new.

So if software engineering is all about complex and flexible designs how should we go about creating them? Waterfall tells us to finish our high level design first and then fill in the details. The problem with this is changing requirements and no feedback on the quality of the design. Should we do bottom up design then? Start small and add more pieces later like agile tells us to do? I think we should do both. Work bottom up but be shure you have a rough sketch of what you’re trying to design. Don’t spend too much time on it because you’re probably going to throw it a way at least a couple of times before your building is finished.

Comments

Popular posts from this blog

Using xUnit.Net with .Net 4.0

I’ve been using xUnit.Net for a while now. It’s just a tiny bit cleaner and slightly less abrasive than other .Net unit testing frameworks. Leaving out unnecessary stuff like [TestFixture] and shortening Assert.AreEqual to the equally clear but shorter Assert.Equal don’t seem like big improvements but when you type them several times a day tiny improvements start to add up. I also like the use of the [Fact] attribute instead of [Test]. It shifts the focus from testing to defining behavior. So how do we get all this goodness working with the Visual Studio 2010 beta?

Square One available on the Android market

This is just a short post to let you know that a first version of the Android app I’ve been working on for the last couple of weeks is available on the Android market. The app is called Square One and it’s a simple bassline synthesizer. It’s free so try it out and let me know what you think of it, but be prepared it’s still an early version. I hope to add more features in the next few months and maybe build something that can be used to create real music.The lower part of the screen contains the sequencer controls that can be used to program your own bass lines. On the left is a four by four grid of buttons where you can select a step in the sequence. On the right you can select the note to be played on that step. When you’re done you can press Start and the sequence starts playing. The knobs on the top can be used to control a couple of parameters from the synthesizer engine that creates the sound. You can control the cutoff frequency and resonance of the low-pass filter, attack and …

Building Android projects with Jenkins, Ant and Mercurial

I have recently set up a Jenkins build server for my Android projects hosted on Bitbucket. It’s not difficult but there are a couple pitfalls and the information on how to do this isn’t available from one single place so I decided to document the process and put up the information over here. Maybe other people will benefit from having a step-by-step guide too.