The truth is... and as much as it breaks my heart to say this professionally, there is no such thing as Software Engineering.
How can I make this claim? While I can tell you that I have been employed in the software development industry since 1991, that I have graduated from a two year post graduate program in Software Engineering Management, which is now incorporated as a Masters of Software Engineering at the University of Calgary, that I have worked on dozens of small and large commercial projects in North America, including my own open source project, that I have read dozen’s of wonderful textbooks on the very subject of software engineering, still might not convince you I am telling the truth.
So how about I make a claim that I defy anyone to dispute. I make the claim that there is no one on the face of this planet today that can predict the outcome (i.e. schedule, cost, resources, quality, etc.) of ANY software project of any significant size (like >10K SLOC) with any sort of accuracy (I will be generous and say + 25% as we all know it will never be a negative percentage).
If you happen to get lucky and actually hit the target once, I make the further claim that your odds are far better in Vegas then they are in the software world for repeatability – that is repeatability for success, not failure – which I would argue that we are very good at.
Big deal you say. Vast amounts of documentation have been written on the subject of Software Engineering and “how to” avoid mistakes and failures. In fact, for every ailment, we have a remedy we can trot out to counter the ailment. But we still make (the same) mistakes. In fact, just the other day, a very popular web site was down for two days that has kicked off this type of tirade on my blog again. In fact, "I am too old for this shit".
I love Steve McConnell’s books, as I do Robert Glass’s, “.” It contains 55 facts and 10 fallacies. Anyone that has been “in the biz” for any length of time is likely to have made some or all of the mistakes listed in the book. I can admit I fall into the category of having made all of those mistakes and then some. And it is not just me.
What gives then? Why is developing successful software so impossible to predict and repeat? Of sure, all of those books (and experience) outline and recommend treatments, but I sometimes feel we are no closer than the founders of the term software engineering. Of course, there are the people that point out that software development is much as art as is it is engineering (remember I said it wasn’t engineering – even though that breaks my heart to say it, given what I have written on this blog in the past) and that Software Engineering is completely a non-deterministic activity, but hey, so is life.
Stepping back a bit, I would say that our world of software development is unindustrialized compared to other industrialised “engineering” disciplines such as civil, chemical, electrical, electronics, mechanical engineering, etc. This is simply based on a time line which we can do nothing about other than wait it out.
Well, I am not a patient guy and would like to do something about this. One thought that has occurred to me, which I believe is of direct relevance to Software Engineering, is how to do we “visualize” software? Specifically, how do we visualize the “design” of software and how do we visualize the “verification” of the built software?
The closest answer I have seen is this:
Ok, so a little tongue in cheek, but ain’t that the truth about Software Engineering? The title of this blog post did not lie 
Note that other engineering disciplines all have ways of “visualizing” the design of their domain. Even designing DNA strands and application specific integrated circuits (ASIC) deal with +100 million objects. What is truly ironic about this is that most of these disciplines use computer software (CAD) to model and verify their designs.
What’s my point? I believe that we are thinking about “visualizing” software the wrong way. CASE tools in the early 90’s are proof of this as I would say that UML is soon to follow the same fate. Why? Because, in my opinion, UML stickman and the other funny looking symbols do not visualize the design of software nor the verification of software – it is simply “Lost in Translation.”
How can we design software on any scale if we can’t model it or visualize it with 100% fidelity? The answer is that we can’t. The closest we can get to modelling or visualizing software is using the same text editor we have been using for over 50 years and using our favourite programming language to design software. Ergo - the source code is the design. Certainly a favourite topic of Jack Reeves. Btw, I happen to concur, which is also the fundamental problem. Visualizing 10,000 lines of source code in any programming language is (far and away) beyond any of us mere mortals that are good for about 7 + - 2 objects at any given moment in time.
It is on this basis that I feel we are way (WAY!) off the target path for Software Engineering and the root cause of why there is no such thing today as software engineering. We have very poor approximations of Software Engineering, still using, comparatively speaking, the equivalent of the Stone Age hammer and chisel. Yet it is the year 2008 – what’s wrong with our industry?
How should we visualize software, both the design and (mathematical) verification (i.e. proof) of the runtime executable? How will visualizing software improve Software Engineering? How can we make the industrialization of software happen? Subject of my next post.