Check this article out on CNN, “Why website crashes are unavoidable -- at least for now”  

No-one wants to say why it really is.  Money, of course it is.  Quality costs money.  Same as the car industry, or any other “item”, you get what you pay for.  And good software is expensive.  Why, because it still has not become a “well known” practice.

So what’s a well known practice?  Building houses, cars, skyscrapers, bridges, airplanes, etc.  And as always, quality is what you pay for on top of the artwork.  Quality goes way beyond “materials” in our software world.  We rely heavily on the training, skills and experience of our engineering people and their “know how” to produce “quality” software.

The point being, we are just getting there in terms of software engineering and today it varies widely, just like the CNN article not fully understanding the real reason those web site are crashing.  It’s all about the design. 

A really good design will have been re-factored many times as several implementation prototypes, going though iterative improvements, some incremental and some experimental, before a particular variation meets the customer requirements and design goals.  Many people confuse this with “Big Design Up Front.”  

What we are doing is iterating the software design by having several iterations for x number of software prototypes.  The prototypes are designed to not only meet the customer requirements, but us as professional Software Engineers, are making design bets on what several iterations of this project over a multi-year release strategy might look like.  This is called Software Product Line Engineering.  This varation in the process itself is a well known practice used in the design and engineering of cars, cell phones, electronics, airplanes, and just about damn near any produced item, and has had several design/prototype iterations before it ever made its way to the customer.

Let me contrast that with why businesses web sites are making news on CNN.  This is how it really goes, whether the business knows it or not, we developed our first “just get a working” prototype and showing it to “management” to show progress.  They say great! Let’s use it right now and BAM!  The prototype that I just slapped together, just to get something working, is now a production application, which needs to be supported.  How about re-architected?  A one off, “just get me a working prototype” does not constitute a product ready application Mr. Business.

Well, that was many years ago and I don’t work that way anymore.  Among the pro software engineers out in the world, designing and building quality software is not a Scooby Doo mystery.  It’s engineering.  And just like any quality engineered product, it costs money.  And right now in our business, designing and building software with a high level of quality is expensive.  And most businesses, who may not have access to professional software engineers, or do it on the cheap, of course, hello CNN Headline News.

So bottom line CNN, if there was some investigation behind what really was the root cause for these web sites going down, it is all about the quality of the software product (i.e. the web site) and the so-called 5 9’s infrastructure that runs the software where engineers can operate and monitor quality of service levels and take instant corrective action. 

So the next time a car careens into a data center and takes out both the power plant and emergency generators, your doing it wrong!  As the saying goes, the design is the thing!  If that is a possible scenario, then design for it, prototype it and verify the design works.  That means there is likely to be several design iterations of several different implementation prototypes.  That costs much more than having your first attempt go into “production.”  But over the planned lifecycle of a designed  product versus, hacking, well... 

It also takes skill.  What I am about to say will be blasphemy to some  I blame the software development methodology (fad?) “Agile” for our current set back in our bid to have software engineering a licensed, professional practice.  The latter statement being another can of worms served up another day.  

The problem with Agile are these two items from the “Manifasto” 

“Individuals and interactions over processes and tools”  As several other engineering disciplines have found out over the decades is, the quality of a product is directly related to quality of the processes (especially design) and tools (especially automation) used to build the product.  Try designing an iPhone without computer aided design and building it with a hammer and chisel. 

“Responding to change over following a plan”  You may feel I am interpreting these wrong and that could be right.  But what my experience has been working with Agile teams in general is that there is so much responding to change that there is no plan!  And btw, If you don't know where you're going, any road will do. ...

If I am the CEO of a company and I was asked to ok an estimated multi-million dollar software project, I damn sure want to not only see the plans, but I want to read a business case that states exactly what this software is going to do for the business, why and what the ROI is before anything happened. 

And btw, I do expect to see detailed business requirements, process maps, use cases, user stories, I don’t really care, as long as it is very clear to me and in gory detail exactly what I am “getting” for those millions.  Otherwise, I ain’t spending a dime.  My expectation is that given the amount of salary/options/bonuses, etc., the CEO’s are getting in today’s market and how heavily most if not all businesses rely on software, they know this and should go hard core on not just rubber stamping someone’s software pipedream.

Of course, there is the obligatory well, requirements change all the time.  In reality, ever changing business requirements = the business does not know what the hell it’s doing.  Ya dig.

So like most professional software engineers, we know what to do and how to do it.  But doing it right = more money.  IMO, that’s where we are at as far as the evolution of software engineering is from someone that spent 10 years in the electronics design engineering world and the last 19 years in the software engineering world.

As an industry, we must resist the urge to jump on any bandwagon that flashes by and stay focused on what other engineering disciplines have come to realize, even the basic of measure twice and cut once we are still learning in our software world.  It has not yet become a well known practice.

It is getting better.  Microsoft has a financial guarantee associated with its pay for online services of 99.9% uptime. That’s pretty damn good if you ask me.

I patiently wait for the business world to realize that if you want a web site that needs to be up 99.9% of the time, you need to pay for it man!  It requires proper design and engineering.  That takes talent and good talent is hard to find... and expensive.  In the meantime, we can watch more businesses make the headlines until the people paying for those products deem that level of performance (CuSat) unacceptable and go with a different brand.  It’s just a matter of time where quality will be a deciding factor in the software world and that’s when our industry will have reached becoming a well know practice.  When?  I can’t say for sure, but I feel we are at the knee of the exponential curve – hang on man!

It is also science, math, engineering, physics, , etc.  At least one other has a similar opinion.

So what then is the definition of Software Engineering?

Wikipedia’s definition, to me, is the most pragmatic:

"Software engineering is a profession and field of study dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build.”

But what does that mean?  If you believe the above definition, then you believe that in order to achieve the CBF (cheaper, better, faster) factor, you need to measure, not only the results of your effort, but the effort itself.  Meaning your process - how good is it?  How predictable and repeatable is it?  Can it be better?

Our industry is so... young, that we still have not learned the simple lessons found in other engineering disciplines, like “measure twice, cut once.”  It so reminds me of that scene in Monty Python’s, the Holy Grail, where the Black Knight, “although supremely skilled in swordplay, he suffers from unchecked overconfidence and a staunch refusal ever to give up.”  That’s us in the software industry – refusing to believe that software engineering is just another profession, like electrical, electronics, civil, mechanical, chemical, industrial, and other engineering disciplines are.

It seems to me that at some point in time (hopefully soon), critical mass will drive software engineering into a fully fledged profession.  For those that follow, it has been underway for many years and following the path of other engineering disciplines.  Or at least, since my first career was in electronics engineering many years ago, I am witnessing a similar process path to what I was involved in the early 80’s in the electronics engineering world.

Since it is possible to become a licensed Professional Software Engineer in British Columbia, I have been going down that path for the last year.  It’s a multi-year process to become a licensed professional.  Why?  The requirements for becoming a licensed Professional Software Engineer are extensive.  And so are the domain specific areas of (PDF Warning!) the Software Engineering Checklist and Software Engineering Experience Guidelines. Also, BC lacks many professional software engineers, relative to other engineering disciplines, so getting my application reviewed by the number of people required by the process takes quite a bit of time.

What’s my point?  Software Engineering as a Profession will happen – it is just a matter of time.  Why am I so concerned about this?  To me it is all about the quality of what we as software engineers produce.  Several running jokes should explain what I mean.  A 30 year vet software professional once told me that if we managed money the way we managed our source code, we would all be in jail.  Or how about, if this was a car, it would only have three wheels, brakes that don’t work, and a gas pedal that gets stuck from time to time (oh the irony Toyota! and I own a Tundra – love it).  If you physically saw this car, would you buy it?  Probably not as it is obvious that it cannot even be driven off the lot.

Oh boy, but do we ever buy software like that?  Hell yes folks, the truth is that the software we buy, relative to the quality of other designed and engineered products like a Ducati 1198 (look at that page man – hard core engineering specs for a work of art!), is poor.

So am I worried about not having “licensed” software engineers?  No, that will sort itself over time as our discipline becomes a real bona fide, first class profession, like a lawyer, doctor or... engineer. It will simply become a requirement just as it is for Professional Engineers today in other disciplines.

What I am concerned about is our consumers accepting low quality software because they can’t “see” if the software has three wheels or four wheels.  The latter, of course, being what the spec asked for.  Eventually, as more and more software is used in our daily lives, people will insist on better quality. Well, that comes at a price, and some will want or demand that level of quality.  That’s a shop I would work for.  I would rather work on designing the next generation Ducati as opposed to the next generation Ford truck (no offense Ford, but you might want to put some art back into those highly CAD trucks).  And just a small aside – how come the car industry has not figured out that I would pay extra to get a retro car that “looked” exactly like a 69 Cuda or 70 GTO 0r 69 Camaro or 71 Trans-Am or... pick your retro work of art.  The body and interior is the replica, but the tech is the latest stuff.  Instead, they produce the Challenger that kinda, sorta looks sort like the original, but not really – so I don't want it.  I could also speak to Product Line Engineering here as the car industry has it down pat and only a small percentage of us in the software world even know what it means and even less having experience applying the technique in our domain.

So where is the art in Software Engineering?  All you talk about is discipline, measurement, control systems, etc. 

Right you are, but if you have been paying attention, you will have noticed I have already said what the art is.  The software is the art.  The process of creating the software is the engineering discipline.  And like other engineering disciplines, the passion drives the art.  Have another look at that Ducati, (or whatever does it for you) and tell me ain’t that the truth!

 

In the mid to late 80’s, in the audio electronics industry, I recorded several rock bands in a couple of professional recoding studios located in Western Canada.  The Northern Pikes were my favorite band for a variety of reasons.  From a software technology standpoint, there was little used in audio recording at the time.  In those days, it was the peak of analog sound equipment including 24 track (2 inch wide tape) recorders, large physical mixing consoles, expensive sound proofed and tuned recording studio facilities, real instruments/amplifiers/effects, real drums, vocal booths, etc.

 

The first digital 24 track recorders (from Sony) were just coming on the scene.  The only gear that was really controlled by software at the time were a few digital effects processors (for guitars/vocals) and a SMPTE time code controller that synched the 24 track tape recorder to the software controlled faders (i.e. the mixing consoles volume and mute controls) on each track.  So when you mixed the sound on the console, you can program the volume, mute, effects on each individual track during playback - yes we used all 24 tracks and heard the song repeated several hundred times.  You would build this “program” up over time, sometimes mixing one track at a time and muting everything else, or tweaking while listening to the overall mix.  Point being, that was the limit (along with early MIDI recording on Mac’s) of software controlled audio.

 

During recording sessions, the recording process was called “live off the floor” recording.  Meaning the band was spread out in the studio, sometimes in various rooms, but all hooked together through audio headsets so the band could all play together live off the floor.  A trick, used by many sound producers before me, was to tell the band that you want them to warm up by going through the song a couple of times before we put it “on tape.”  Unbeknownst to the band, I was rolling tape the first time they played the song in the studio (i.e. a first take) and as some would argue, myself included, that the first take has a good chance of being the best take.  Meaning you caught the band at their best.  This was called a bed track with a ghost (guide) vocal track and then the other tracks would be overdubbed on this bed track ovetime (i.e. more guitars, solos, vocals, harmonies, embellishments, etc.), until all 24 tracks were used.  And in some cases, never to be recreated again – meaning a moment in time was captured on tape and no matter how the same players tried to recreate it, they could not come up with the same groove/sound they had the first time they played the song.

 

The thing of it is, this was millions of dollars of gear to record a live band.  Plus operations and maintenance of a professional recording studio shows why the rates can be +$200 per hour to rent the place.

 

Fast forward to 2009.  I purchased Rock Band 2 (on PS3) for my 6 year old daughter.  PS3 was $299 CDN, Rock Band 2 was $159, and another controller $59 (for Little Big Planet). I already have several PC’s (being in the software business),  Asus 25” HDMI monitor and X-fi sound card with Logitech 5.1 surround sound speakers.  I was blown away with the (software controlled) sound processing on the drums, bass, guitar and vocals on Rock Band 2.  Sounds just like in the studio!  Well, not quite, but for non-audiophiles, most people could not tell the difference.

 

The point being, the latest (software driven) digital technology used for sound engineering has increased in capability that was not even dreamed of 25 years ago.  Look at Band in a Box – audiophile edition is 669 bux (they send you pre-installed software on a 1.5 Terabyte hard drive).  Look what it does - a fully equipped, 10 million dollar, professional recording studio, completely virtualized in under $1000 software.  Unbelievable!!! 

 

To me, this is witnessing an area of software industrialization that I have been a part of for over 25 years.  My conclusion is that over time the technology has exponentially increased in capability and at the same time exponentially decreased in cost (including operating and maintenance costs).  What used to be $10 million 25 years ago is now less than $5K to have a professional recording studio virtualized on your computer in your home.

 

The best part, of course, was being able to play Rock Band 2 with my daughter and watching her play the various instruments and sing.

 

Happy New Year!

 

When I use the term software engineering, the definition I am referring to is:

“Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.” 

So what then is a Software Abstraction?  Take this paragraph from the awesome book, :

“Software is built on abstractions.  Pick the right ones, and programming will flow naturally from design, modules will have small and simple interfaces, and new functionality will more than likely fit in without extensive reorganization.  Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make.  No amount of refactoring, bar starting again from scratch, can rescue a system built on flawed concepts”.

Brilliant!  It’s the first paragraph of the 1^st chapter into a world of real software design - i.e. formal specification, including the ability to model and automatically analyze your design:

“Unlike theorem proving, this analysis is not “complete”: it examines only a finite space of cases.  But because of recent advances in constraint – solving technology, the space of cases examined is usually huge – billions of cases or more – and therefore offers a degree of coverage unattainable in testing.”

“Moreover, unlike testing, this analysis requires no test cases.  The user instead provides a property to be checked, which can usually be expressed succinctly as a single test case.  A kind of exploration therefore becomes possible that combines the incrementally and immediacy of extreme programming with the depth and clarity of formal specification.”

Check out Alloy Analyzer and the Community.

It’s slow going for me, but I am getting through the book.  Until you read this and run Alloy Analyzer, you cannot imagine the number of “cases” Alloy Analyzer can run, like the text says, a billion or more.  It picks apart your design like you have never seen before.  Imagine what the number of cases would be when you combine dozens of models to formulate a software application. 

This is a leap forward in software engineering design in my opinion.  Being able to analyze your design against a billion cases without writing a single line of production or test code is unheard of in mainstream software development industry today.  Using this design approach will produce software design's that will be more robust, perhaps by orders of magnitude, than any manual method we apply today.  The software design itself, is a complete formal specification used by the “end” software programming language to transform the complete design into a runtime solution.

What about the software engineering definition comment in the opening?  I am pointing out that we are following the definition of software engineering by using Alloy for designing software; it is one way to apply a systematic, disciplined and quantifiable approach to software design.  In my opinion, we as an industry, and as professionals, should be applying more effort towards software design.  Why?  Read the “Software is built on abstractions…” paragraph again.

Daniel Jackson and his team’s work on Alloy Analyzer, to me, is the state of the art in software design today.  When will it become mainstream?  Good question, but you can help.  As a Software Designer, have a look at Alloy.  Maybe apply it to a hobby project.  With enough practice, perhaps introduce formal design specification to the workplace on one small specific issue or algorithm you are working on.  That's my approach.

I know change is hard and everyone resists, but look at it as an experiment to try out, see how it works, and if it makes sense to you.  As a software engineering practitioner, I am trying to become a better software designer by learning new concepts and techniques.  I believe Daniel Jackson’s Alloy makes me a better software designer.

 

"Software reliability engineering relies heavily on a disciplined software engineering process to anticipate and design against unintended consequences."

Wikipedia Software Reliability

The six paragraphs in this explanation on Software Reliability are bang on in my experience. In fact, the statement above best describes the difference between project success and failure. The more disciplined the software engineering process the better quality the output, in all measurable aspects, is my conclusion after 18 years as a software professional. Btw, disciplined != bureaucratic || inefficient.

I wonder if software reliability engineering had been applied to the following web sites, it would have been less likely for me to see these messages:

 

 

 

 

 

 

 

 

 

The irony here is that these two messagess occurred on two seperate dates, not just 20 minutes apart

 

An Error Has Occured?  Pics or it didn't happen! Oh... well how about directing me to another download site that is known to be working?  I can't imagine what's in the "On-line Self Help."

 

No way man!  

Aeroplan, a fairly large transactional site, was down for two days. I wonder if software reliability was on anyone’s minds when the site was designed…

You may have noticed that some of the screen shots show maintenance messages, not error messages (and other reliability messages). I find it hard to believe that there is (still) the practice of scheduling "planned outages" for web application/site maintenance on the main public domain web site. First business rule in the world wild web, you are always open for business.

Sure, some of these sites have staggering amounts of traffic and processing. However, it is 2009, where computer hardware has never been cheaper and the most powerful at the same time. Content Management Systems and Ecommerce systems, have never been more plentiful, more mature, and the most featured for the least amount of dollars.

That’s one of the points behind having a disciplined "software engineering process."  One of the most important activities, in my experience, is designing for software reliability. No, I don’t mean life and death reliability, but given the budget constraints, what is the best or most acceptable "business risk" the web application/site is able to mitigate from a reliability point of view.

What do I mean by business risk in this context? Given that Aeroplan was not able to transact business for two days, let alone how it looked to "customers", I would be surprised if the executives signed off on that their main public web site could be down for a two day period.  And no, I don’t mean "high availability" or five nines uptime, albeit related, I mean software reliability. Even if you paid for five nines up time, it is very likely your software will error out (or you planned a maintenance window!) well before you hit that uptime number.  I would say that this is predetermined by how your software was designed and engineered.

I wonder when the "tipping point" will occur where the general public will stop accepting software that is the analog equivalent of missing a wheel on a car. Sure you can drive it, but not very well. That’s the ultimate problem with software, it is completely invisible to the majority of people, but if they saw it, and it looked like a car, then they would see that missing wheel, hear the engine misfiring, and see/smell the smoke bellowing out where canola oil was used instead of engine oil. The car is clearly a lemon and would not sell. Even if it did sell, there is a lemon law.

Yet software contunues to be built, and software products exist today, that are the equivalent of the lemon of a car, but there is no lemon law or even a guarantee of any sort for software. There is a reason for that. Some would say that software is too complex or at least no-one, other than NASA can afford the level of software reliability engineering that we comparatively see in our cars today. Do you think that is true?

Based on my experience, I don’t think so. In fact, over the mid term and long run of a software lifecycle, spending the engineering time to design the software correctly (or as best as possible given budget constraints) easily costs (considerably) less than just trying to bang the software out using the latest du jour software process methodology and then fixing the heck out of it for years to come. At least my own anecdotal experience supports that position.

These software quality issues were screen snapped over a couple week time frame while I was browsing the net.  What does it mean?  I feel it means a couple of things.  One is that I am one person, the smallest possible sample size, yet look at the poor quality software I encountered during a short time frame.  I can't imagine what the impact is on millions of users sampling (hundreds of ?) thousands of web applications/sites daily.  The other is there seems to be far and few between companies that actually practice designing and engineering software in a disciplined manner...

Updated Next Day - Ha! 

Gmail outage deprives millions of e-mail

 

 

+1 WolframAlpha

I must be getting old.  I find twitter enables a curious social behavior, seemingly aimed at extroverted people, and some would say at its extreme, narcissistic.  

While I don’t use twitter myself, or even Facebook, I do blog, ergo, I must be one of them too.  Myself, I am simply interested in the technology as the human factor seems to be hurtling towards Singularity at a rate I no longer can understand.

I spend a lot of time in front of computers, I mean at least 8 hours a day for the last 18 years or so, mostly as a professional Software Engineer.  As a Software Designer, I find twitter interesting, but why don’t we design the equivalent of twitter on video (with sound) instead of text?  YouTwitter would allow you to record a video for 5 - 7 seconds (or whatever). We certainly have the computing horsepower, the bandwidth, and what seems to be a critical mass of cell phones with video/audio record functions and wifi capabilities.  Not to mention any computer/laptop/netbook/media center/(Xbox?) with a microphone, web cam, and internet connection.  Which essentially means the same size market as “regular” twitter is today, but rather than serving up text, now serving 5 second video (with audio).

As a Software Engineer, it is interesting to think of the design and implementation of such a system.  Who knows, maybe it is already happening, and this shows how out of touch I am with social networking

If YouTwitter existed, I probably would use it – not only would it be fun, but change the way we communicate via computers.  Take me for example, at 50 years old, and really been on one form of computer or another since 1980, I am (really) tired of writing text.  It would be way cool not to have to type any more text.  I write too much already and that’s why I would like to see YouTwitter.  If I had the time and capital investment, I would design and build it myself.

YouTwitter is more than that.  What about the capability to see people’s interaction without the text?  Did I mention how our overall communication style would change if I could see you speak instead of just reading your text?  Is this the next evolution in social networking?

I don’t know, but I would use it, even as an introvert.

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 it 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 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 tired old 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.

 As an 18 software development professional, I have been waiting for this day for a long time.  Honestly, I thought this day would never happen in my lifetime, but it did and in a form I would have never guessed:

 

“The future of games development has been called into question after the EU Commission suggested developers provide a two year guarantee.” 

 

Two year guarantee on… games?  I would have thought that medical software or aviation/guidance software or any other software application/system that could put people in harms way would have been the first industries to have instituted guarantees on defective software. 

 

Never did it cross my mind that it would be the gaming industry, but then again, after thinking about it, it makes perfect sense.  Video games are a multi-billion dollar business targeted at mass consumers, a.k.a. the public.  So when lots of people’s games don’t work, something has to give.

                                                                                                                      

The key clause is, "two year guarantee on all games in the event that a bug or glitch is encountered preventing you from completing the game and/or ruining the experience."

 

As the articles states:

 

“At present, retailers are not obliged to give a refund on a video game that has a bug or glitch that prevents a user completing a game. If the proposals become law, this could change as users would have the right "to get a product that works with fair commercial conditions".

 

Note it says proposal, but I say great, it is about time!  Why is it only in the software industry, people and corporations spend trillions of dollars on software and none of it is guaranteed?  No, I don’t mean delivery guarantees, or warranty periods, I mean outright quality guarantees. 

 

For me, as someone who develops software, I could not be happier.  This marks the day that there is enough critical mass in the public to demand better quality software products.  Really it means that software will need more engineering, as in software engineering.

 

“Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.”

 

At age 50, I have had two careers, the first in electronics engineering, where the application of systematic, disciplined, quantifiable approach… was never even questioned, talked about, it was simply expected, standard operating procedure, institutionalized, etc.  But when I entered my software career in 1991, I was very surprised to find that in the software world, there were debates going on, still today, whether software development is engineering or art or science or…

 

Fortunately today, many universities are offering undergraduate degrees in software engineering and have defined the difference between computer science and software engineering. 

 

This means that younger generations will be more exposed to software engineering rather than us “old guys” where there was no such thing called software engineering when we went to university.

 

I also believe that software engineers should be licensed as Professional Engineers (P.Eng. in Canada).  In fact, in British Columbia, Alberta and Ontario, you can be licensed as a professional software engineer.  

 

You can read an excellent paper on, "Licensing Software Engineers" by Philippe Kruchten  From the article, “The only purpose of licensing software engineers is to protect the public.”  I totally agree.  Now Philippe suggests that licensing software engineers who designs  and develops software that can kill is protecting the public.  I agree with that as well.  But I would take bit of a broader definition that not only includes software that kills, but again protects the public from financial impact, which basically covers most business software, like ecommerce, banking, trading insurance and any applications that deal with money, but also even t the point of gaming software, which is what this article began with and the proposed two year warranty.

 

Perhaps a little reflection is required to let what I am saying fully sink in.  For any software development project that has any impact on the public, financial or otherwise, the software engineer responsible for “sealing” the blueprints should be a licensed software engineer.  A licensed professional software engineer is bound by professional practice and code of ethics.  That means that a licensed professional software engineer is legally responsible for the design of the software.  Think about that.  Aside from the responsibility, the way software is designed and engineered is going to change in our world.  I can only be grateful for that and like I said early on, it is about time.  Today is a red letter day!

Over a half dozen years or so, I have noticed a trend in our software engineering world towards collecting less and less data about what we do and how well we are doing it.  This would be contrary to lets say professional sports where data collection (i.e. stats) is a well know practice and pastime, plus on the rise, whereas in our professional software engineering world, it appears to be on the decline.  I wonder why?

 

A history lesson first.  A fantastic short paper called, “Lessons learned from 25 years of process improvement: The Rise and Fall of the NASA Software Engineering Laboratory” provides some real insight to a problem that now seems to be rippling through our industry en mass.  I would say the Software Engineering Laboratory (SEL) was ahead of its time and has seen some possible future outcomes that may be coming true for some (most?) organizations in the corporate world.

 

The SEL collected software engineering metrics on process improvement from 1976 to 1991 and beyond.  I am not going to summarize the lessons here, you can read the excellent paper for that, and if you were/are ever a part of a real software engineering organization, none of the lessons learned should come as a surprise.  But I think that is the real lesson to be learned from this paper and the amazing contributions to software engineering that came out of the SEL and that is, very few organization are actually practicing real software engineering process improvement.  And in fact, I would suggest that the latest trends in software development lifecycles, like Agile, XP, Scrum, et al are actually going the other way.

 

Allow me to explain where I am coming from; here is one of the lessons learned from the SEL: “Establishing a baseline of an organization’s products, processes, and goals is critical to any improvement program.”  In most other industries, this is a given, including professional sports.  Heck even in non professional sports, like your college track and field events, you establish your baseline for the 100 yard/meter sprint and constantly trying to improve on that as a simple example.  Yet, in the software engineering world, where is our baseline?  We have embarrassing baselines like spending millions and billions (note - how embarrasing, in my home country!) of software that is of poor quality or doesn’t even work.  Maybe that is why we don’t measure ourselves?

 

We have “new” software development lifecycle methodologies that promote no collecting metrics on how well we are developing software.  Its astounding and disturbing, not only to me but to businesses that are forking over millions of dollars for software development projects that seem to have nothing more than an ad hoc process of going wherever the project meanders, no matter how long or at what cost, let alone even validating if the right problem is even being solved in the first place.

 

How do I know this?  I have been in the software engineering business for 18 years and had the privilege to have experienced many a software shop ranging from multinationals like Eastman Kodak, Motorola to midsize companies and to small start ups, including my own, in several different industry verticals and locations in North America.  I had the good fortune of being taught Software Engineering Management, a 2 year post graduate program from the University of Calgary, taught by Motorola University, where each of the instructors had many a year experience and stories about software engineering projects, both failures and successes and most importantly, what the differences were/are.  I have kept in touch with past employees/friends in the industry to hear interesting anecdotes over a virtual beer.  And finally, I spend a lot of time researching and reading about software engineering in general. 

 

And my conclusion is that we as an industry are (way) off track and seem to be heading further off track with the invention and adoption of new methodologies that are not based on (any) actual factual experience/metrics/historical data like the 25 years of solid software engineering experience that the SEL has produced.

 

Why do I believe that?  I see it everyday and in several companies that I may come in contact with due to my job.  I don’t need any further proof than that.  Just even the simple metric of “establishing a baseline” of anything in your organization should be proof enough for you.  What data have you collected for x software engineering projects you have undertaken, in any of the companies you have worked for?  I bet it is a small percentage, if any at all.

 

Why is that?  I think the SEL folks hit it on the head with one of their lessons learned, “It is difficult to make an engineering organization aware of the importance of software engineering to their mission.” I would substitute engineering organization with “any” organization.  Software is everywhere and in everything.  It is almost as ubiquitous as the telephone or power, yet we have no way to measure its quality, effectiveness or how productive we are at designing and constructing it.  In fact, I would say that that any given orgranization is not even aware of how important the role of software plays in their very own organization.

 

And we software engineers, developers, programmers, coders, craftsman, or whatever we believe in (I believe that software design and construction is an engineering discipline) are our own worst enemies.  Behold, I give you programming.reddit.com where almost 100,000 subscribers argue over which is the best is programming language, ever, every day, year after year.  Or CodingHorror.com, with +100,000 subscribers, with its blog name, light hearted or not, sends the wrong message to the masses that coding results in a horror show. Or even Hacker News… How would any organization looking to solve a serious business problem that costs millions of dollars in software engineering take anyone of these seriously?  Or just assume that the whole lot of us is represented by these blogs and news feeds?  No wonder we have credibility problems.  No wonder we don't collect stats!

 

So what we do about it?  Just like anything, it takes a lot of hard work and some critical mass for an organization to realize that software may be a big part of their business and that maybe they should seriously consider looking at how software could be engineered for their business based on real software engineering principles and not on the latest and greatest fad of the month.  I don’t know about you, but if I was to spend a million dollars on any software engineering project, I would want to be sure that it was on budget, on time, had some level of quality in it and actually solved the right problem.  Establishing a baseline of what you are doing and how well you are doing it, is the start of real software engineering.