Dag 1 ”Seven roads to hell” rullar igång i högtalarna och jag går ut på scenen. Natten är lugn, och det är bara fåtal kunder i...
The woe of designing softwarefungrim
Currently Cubeia Ltd is using the methodology called Scrum, which is a part of the family of so called Agile software methodologies.
Works fine for us and many others. There are some problems though. One is that it feels curious committing on hard deadlines in the future, “product X will be delivered at date Y”. Another is the lack of a design phase, and hence this little post.
Designing component X is about finding out how X is supposed to work (perhaps you’d call this “requirements”, but I think there’s a tangible difference between “requirements” and “specification”), how X can be made to work as specified, and how we can ensure X a long lifetime, in other words that X can be reused and that X will not impair future designs.
Design is hard.
Software has become a commodity. It is everywhere. The mass of software produced worldwide is staggering. And 99% of it is bug-ridden and/or badly designed.
When people ask me why software isn’t like engineering, perhaps something in the lines of “why does software always have so many bugs, I mean, we can build bridges and machines, and they don’t have that many errors do they?”, I usually sneer back: “Well, give me enough cash and I’ll give you bug-free software.” This may sound strange considering how much software costs to develop as it is, but not if you take software complexity in mind. A bridge for example is, at least in its basic forms, is simple, static and built with material which has static and reliable properties. Software on the other hand is often complex, dynamic and is very seldom build upon reliable hardware components.
Scrum works because it provides a pragmatic way forward in a rapidly shifting and changing problem domain. On the other hand, more traditional “engineering” does exist in software development. And no, I’m not primarily talking about waterfall methodologies, but something like this: How do they write software at NASA? It should be pointed out quickly though, that, say, an ordinary web developer, has no control over that hardware, whereas NASA probably knows on beforehand exactly what hardware the software is going to run on, so you can perhaps remove one tier: complex, dynamic but build on reliable components.
Seems to work well for them. I’d love to try it one day, if nothing else because I hate, with all my body and soul, to write bugs; to the point of physical nausea at times. But I doubt we’ll see any major revolution in the software industry yet for a while.
Design will remain hard.