Software Engineering

My lecture this morning was on project management. Specifically how it applies within the games industry. So I was pleasntly surprised to find an almost identical post over at Coding Horror.

The name “software engineering” is apt enough. Computer Science is about creating pretty little algorthims ( don’t get me wrong, I use BubbleSort all the time).

Software engineering is about getting a given piece of software to work, no matter what the code looks like. 

Jeff says:

But software projects truly aren’t like other engineering projects. I don’t say this out of a sense of entitlement, or out of some misguided attempt to obtain special treatment for software developers. I say it because the only kind of software we ever build is unproven, experimental software. Sam Guckenheimer explains:

To overcome the gap, you must recognize that software engineering is not like other engineering. When you build a bridge, road, or house, for example, you can safely study hundreds of very similar examples. Indeed, most of the time, economics dictate that you build the current one almost exactly like the last to take the risk out of the project.  

I agree. Let me explain.

It has “engineering” in the title for a reason. You don’t need a fully qualified engineer to fix the gas boiler ( though thats what they’re called in the UK). You do need an engineer to build the world’s longest rail tunnel. Thats why its engineering. Thats the semantics

Also, like engineers, we tweak things constantly. My lecturer gave the example of the motorway just down the road. They built it in a marsh. But the thing is that you can’t build in a marsh. So they froze, yes froze, the ground with freon and built on top of that. Thats engineering.  

Thats why its like real, civil enginering. 

As far as unproven, experimental software goes, I’d like to give an example. I get project management software, a trial version. I test it to see if i’d be willing to shell out for the full version. I don’t like the program. So i take the basic idea ( “keeping track of development schedules”) and build a better project mangment software tool, with the all the cluncky bits stripped out. Both programs will work and do the job of keeping track of development schdules. One will be better than the other becuase end user input has been taken into account.  

My point is that. Most of what we as software developers do comes from the real work. Surely Pharaoh must have had project management in his time? The challenge is create something better than the previous iteration. So we port proven tasks, in this case project mangement, to the computer, while still being ready to improve on the product. Engineers build a bridge once and have to wait till the next bridge comes along to apply what they learnt on the last one. We write software that evolves, yes evolves. Snapshots of the  same bit of software take in the middle and the end, will be completely unrecodnizable. So in this sense, we do write experimental programs.

So, in response Jeff, it depends on your point of view.