# Monday, 03 August 2009

Quick, tell me what is common between, “” and Software Engineering?   Answer: They are both stories about engineering and one has tragedy in human lives.


The Tragedy at Second Narrows is an absolutely compelling story about engineering design. The tragedy is the number of lives lost due to what appears to be an engineering design oversight.  Ironworkers Memorial is of very special meaning to me as I live near Vancouver and occasionally have the privilege to drive over the Ironworkers Memorial Bridge.  I have a lot of respect for the Ironworkers, Engineers and the entire craftsman who worked on this piece of art.  The art is that traffic flows across the bridge at the same speed as the #1 Highway in Canada – the user experience is seamless and that’s its beauty, it is also by design (i.e. it has been engineered that way).


The Ironworkers Memorial Bridge also has a special meaning to me as it relates to software engineering.  I believe software design and development is an engineering activity.  In fact, the more years I do this (since 1977 in electronics engineering and slowly moving to software engineering since 1991) the more I believe it.  So do others, including educational institutions. You can get a 4 year degree in Software Engineering  and the States have been doing since 1996 when I saw it at RIT while working at Eastman Kodak in Rochester, NY.  Damn man, you can even get a PhD in Software Engineering.


Software Engineering in the province of BC is recognized as a professional practice and since 1999, you can apply to APEGBC to become a licensed Professional Software Engineer.  Aside from having an ABET recognized 4 year engineering degree, 4 years documented experience, 4 P. Eng.’s to stand up and vouch for your sorry ass, attend a 2 day law and ethics seminar or consume the equivalent in CD-ROM, and pass a 2 hour Professional Practice examine, there are additional requirements.  You need to fill out a Software Engineering Checklist and you need to complete the Software Engineering Experience Guidelines. 


It is very interesting to read over the last two documents, Software Engineering Checklist and Software Engineering Experience Guidelines.  The point being, if you want or need a description of what Software Engineering is and how to document it, spend a bit of time reading these short documents.  While a bit old, the first principles hold true, which is what I refer to the lost art in my title (more later). 


As mentioned previously, Software Engineering is a recognized professional practice in British Columbia.  Check out the benefits of becoming a licensed Professional Software Engineer. Meet the first licensed Software Engineer, Philippe Krutchen, who was licensed in 1999 in BC.


Software Engineering to many people have many different meanings.  Some think/feel software development or programming is an artistic endeavor.  Others think of it as craftsmanship. From my perspective, I agree with everyone. In fact, it is all those things and much more. Some people feel that the La Sagrada Famillia is art.  Some would say the craftsmanship that went into it was second to none.  But it was also engineered (i.e. designed). Check this out, Gaudi designed the weight-bearing of his buildings, upside-down with string and bearings.  So when you looked in the mirror, of course it was right side up.  I saw this first hand.  Engineering at its finest, well before modern engineering with all our fancy calculators and our StarTrek Communicators. 


So Software Engineering is design, art, craftsmanship and any other word that people want to use that is not engineering.  Call it what you will, I agree with you.  But it is also part engineering.  That to me is the lost art, specifically the engineering design part.


In fact, I would say Software Engineering, at its very core, has four fundamental activities: requirements analysis, design, code, and test.  Of course you have to deploy and operate, maintain, and a whole pile of other things (reports, UI enhancements, skinning, ad infinitum), but I just want examine these four core activities.  Let’s put some definition around what I am getting at:


  • Requirements Analysis:  I don’t care if you use story points, scenarios, use cases, flowcharts, or animated puppets to gather and package software requirements.  The question is how accurate is your transformation and how good you are at repeating it.  Understand what I mean?  How do we as a team communicate “what” needs to be built?  To answer the question, I am suggesting use whatever methods and tools you want as long as the result (i.e. the transformation) is accurate and you can repeat that accuracy on multiple projects consistently and eventually, predictable.  That to me is the lost art of software engineering in requirements analysis.  What is the percentage accuracy of our requirements gathering and packaging? i.e. relative to the intent of what the users actually require.  And btw, if the users or community can’t tell you, in gory detail, what they want, then no amount of software is going to solve the problem.  Capiche?  What’s our percentage repeatability and predictability?  That’s the theory and in practice it does works.  But it is a lot of very hard work, so you really don’t see it too often in our field, hence the lost art.


  • Design: Ah, the crux of software engineering.  Your choice of design methods and tools should be determined on which methods and tools will result in the least complex, but most (easily) extensible design possible.  In short, at its essence is a mathematical formula for reducing complexity, but the art is your application of the formula at the problem at hand.  Again how accurate is your design transformation relative to the requirements you used to produce that design?  Can you do it consistently as new and old problems come your way?  Whether you choose a formal design method like MIT’s Alloy, (if you have never used Alloy before, try it on for size, it really demonstrates software complexity through modeling. ) or a traditional OOD method, is really not the ultimate issue here – choose whatever method/tool yields the most accurate Requirements -> Design transformation.


  • Code – it seems everyone knows how to code in their favorite programming language.  Again ultimately, from a software engineering perspective, use whatever programming language yields the least complex representation or transformation of the design.  Oh, yeah, I know what about the human factor – where are we going to find programmers?  Or the million other factors that occur when selecting a programming language. Does it really matter?  Not if you want to produce the least complex implementation.


  •  Test – There seems to be a dazillion and one testing methodologies/tools. Does it really matter which one you use or what tool?  I don’t think so.  Again, what percentage accuracy is our testing against the 3 previous transformations? Oh sure, at what level of effort you ask? What was the requirement for testing accuracy and coverage?  Don’t have one, better get one.  More lost art.

Oh, I know I am greatly simplifying the above, but isn't that a lost art also?  It seems to me that year after year we further complicate our art, not simplify it.  One lost art of software engineering is trying for the most accurate transformations from requirements to test (and eventually deployment, operations, and maintenance.).


Another lost art it seems is designing for a least complexity solution or at least making it a priority.  But that takes time, commitment and data.  And that’s my point.  It appears the trend I see in our industry, and if Jeff Atwood’s blog on Software Engineering: Dead  is any indicator, reading the comments there are an eye opening experience about people’s thoughts on Software Engineering.  I have been there myself, on more than one occasion, and in fact, is normal for most companies that are trying to design software, but really don’t know how.


The only way to improve what we do as Software Engineers is to measure what we do and how we do it.  Oh sure, that old tired saw.  I have seen it work with my own eyes to know the truth and value behind it.  Yet, we as an industry seem to have completely forgotten the value of measuring what we do and how we do it.  Other industrialized industries would cease to function without this feedback control loop.  Can you imagine pro sports without stats? It would never happen, but the trend in our industry seems to be moving away from measuring anything and just going for it.  I wonder why that is?


My hope is that over time Software Engineering, while a Professional Practice in British Columbia, becomes more widespread, and what I used to take for granted as standard operating procedure (SOP) in Electronics Engineering, will become SOP in Software Engineering.  But like anything, this is going to take time and education, particularly for folks that don’t know about the engineering part, or for others like me that have lost it from time to time.

Monday, 03 August 2009 21:12:02 (Pacific Daylight Time, UTC-07:00)  #    Comments [6]
Tuesday, 04 August 2009 12:29:26 (Pacific Daylight Time, UTC-07:00)
I think a large part of the "just going for it" is that the business people who foot the bills for a lot of software work are not building a bridge. In many cases they need something cobbled together that will fill their need for the next X months (often less than a year) and then will be abandoned. This kind of "meatball" programming is ugly but effective. It fulfills the basic capture / store / analyze / output functions and is rapidly iterated through to add a few more functions. Very often the business person expressing the need does not have a complete understanding of what they want let alone what they need. I think that this kind of development is what is gaining momentum with Agile and its ilk. On the other hand, if there is any kind of danger involved in software (e.g., control systems for medical equipment, guidance systems for weapons, etc.) I believe that there very much IS a role for a formalized engineering style methodology, and people who are involved in such endeavors most likely also believe so. At the end of the day software is expensive to build. The people paying the bill are the ones who will drive how it is done, even though it might stain our technological souls to bastardize something to just "make it go".
Wednesday, 05 August 2009 08:15:22 (Pacific Daylight Time, UTC-07:00)
Hi Todd, Thanks for your comment. Generally, I agree. Software is expensive to build and no question, people who pay the bill will drive how it is done. But I think that is also the issue. The problem is that if the meatball software turns out to be useful and people actually use it, then it typically does not go away after a year or so. In my experience, the software then has more features bolted on to it, more people depend on it, and eventually the cost of maintaining/enhancing it exceeds the cost of had it been designed and engineered from the very beginning. That is my point. Just getting it done perpetuates the myth that software cannot be designed and engineered. All this does is delay the inevitable, which is the industrialization of software.
Wednesday, 05 August 2009 19:26:08 (Pacific Daylight Time, UTC-07:00)
We still have software engineering out there. You don't hear about us often. That's because we are not spending a lot of time blogging about it. We are engineering great solutions to tought customer problems. An engineer is best when he is hard at work cooking up that design. Now the goal is to make sure the next generation is ready to take on the hard work. Maybe we need to be better at an apprenticeship program. Isn't that how the engineers in the other fields do it?
Thursday, 06 August 2009 00:49:24 (Pacific Daylight Time, UTC-07:00)
Hi, I agree. I had been in the webdevelopment for some time now and I discover that the mainstream departments do not know how to build software. While it is the time now that applications shift further onto the web, companies are more demanding. It is not just a homepage anymore what they need online. But any kid on the block can script in Ruby or PHP and follow a few tutorials on using a database. And they don't know much about information systems and the flow of processes etc. So, these companies end up with expensive webapplications that are spaghetti coded and do not fill the requirements. If you want to help them, they state that Bob the student had built it in a few weeks, why can't we? The people who decide, the owners, don't see what is behind the application. It is not visual anymore. It's different with buildings, like housing. If someone took a course in tailoring, that doesn't make him a good skilled tailor and it shows quick enough. The owners of software don't care if the requirements aren't met as long as it 'works'. But soon enough they discover they want a 'bathroom' too and that needs a redo of the plumbing. That is where the kid on the block quits and a software engineer would have helped. For now, I'm following a course in Software Engineering, just to know what it takes to build solid and endurable software. I don't want to be that kid on the block anymore... I want to be a professional.
Thursday, 06 August 2009 07:30:25 (Pacific Daylight Time, UTC-07:00)
The flaw in the argument about software design being an engineering discipline is that the end result is rarely the product envisioned at the beginning of the process.

A well engineered bridge has a set of well defined goals: move 1000 cars across a river which is 100m wide per day (or whatever).

However, what if the following happened after the bridge was completed:

Make the bridge move 10000 cars per day.
Make it accessible for trains.
Make it possible to move really big boats underneath it.
Make it blue.

At the end, the elegant, beautiful bridge is hardly recognizable. This is software design. The fact that is so "easy" to change makes people want to constantly change it.

Building software which has predefined criteria which *does not change* is possible and could be an considered an engineering discipline.

However, this never (or very rarely) happens.

Until this changes, building software in the real world has very little in common with engineering.
Friday, 07 August 2009 04:39:28 (Pacific Daylight Time, UTC-07:00)
Thanks for your comments, Maintenance Man, Unomi, and Shawn.

Maintenance Man – re: “Maybe we need to be better at an apprenticeship program. Isn't that how the engineers in the other fields do it?” That’s exactly how engineers in other fields do it. Our field does not have enough professional software engineers to support an apprenticeship program… yet.

Unomi – Good for you, keep taking Software Engineering courses. Look into seeing if you can get a degree in Software Engineering and become a licensed Professional Software Engineer.

Shawn – re: “The flaw in the argument about software design being an engineering discipline is that the end result is rarely the product envisioned at the beginning of the process.” And “…that software is so easy to change.” I respectfully disagree. The company I work for builds large scale, ecommerce software systems. The end result does indeed reflect the original specification quite closely. The variability is captured through Engineering Design Change Requests, which mirror other engineering disciplines. You might find Software Product Lines an interesting read. With respect to software is so easy to change, I would argue that is another myth in our industry. While software may “appear” to be easy to change, the issue is that software should only be changed from an approved specification with a formal change request so that all can see the impact of the change – meaning getting the people who pay the bills to authorize the change. Once you have this in place, much like other engineering disciplines, the truth about how easy software is to change becomes quantifiably known.
Home page

Comment (Some html is allowed: a@href@title, b, strike, u) where the @ means "attribute." For example, you can use or

Enter the code shown (prevents robots):

Live Comment Preview
© Copyright 2009 Mitch Barnett - Software Industrialization is the computerization of software design and function.

newtelligence dasBlog 2.2.8279.16125  Theme design by Bryan Bell
Feed your aggregator (RSS 2.0)   | Page rendered at Monday, 10 August 2009 17:09:36 (Pacific Daylight Time, UTC-07:00)