[LINK] Where Are the Software Engineers of Tomorrow?

[Stephen Wilson]

I'm an ex software guy.*  The software-engineering-as-a-profession 
debate is decades old.  I find it fascinating that the debate continues 
almost completely untouched by each generation's innovations in 
production: high level languages, object orientation etc.  Most of us in 
the 90s thought that re-use and enforced modularity would introduce to 
software some of the hallmarks of real engineering -- predictability, 
repeatability, measurability etc.  Yet it seems that many of the human 
traits of software-as-a-craft remain with us.

Moreover, I suspect that a deep problem is that the stuff of software is 
so very different from the stuff of other professions (soil, metals, 
electronics, flesh and blood, people, planes ...) that we might 
underestimate the challenge of forging a software profession.

Two years ago I wrote a letter to Computer World about these matters, in 
response to a consultants' report at the time that IT projects (hence 
software development) needed a more corporate governance.  Yup, like a 
hole in the head.  The original letter follows (it was published with a 
light edit).

------------------------------

Yes indeed, IT is made the scapegoat for a great many project disasters 
(ComputerWorld 28 September 2005, page 1).  But it may prove fruitless 
to force orthodox project management and corporate governance 
methodologies onto big IT projects.  And at the same time, IT 
"professionals" are not entirely free of blame.

So the KPMG Global IT Project Management Survey found that the vast 
majority of technology projects run over budget.  In the main, 
"technology" means software, whether we build or buy.  The "software 
crisis" – the systemic inability to estimate software projects 
accurately and to deliver what's promised – is about 40 years old.  And 
it's more subtle than KPMG suggests in blaming corporate governance.  It 
is fashionable at the moment to look to governance to rectify business 
problems but in this case, it really is a technology issue.

Software project management truly is different from all other technical 
fields, for software does not obey the laws of nature.  Building 
skyscrapers, tunnels, dams and bridges is relatively predictable.  You 
start with site surveys and foundations, erect a sturdy framework, fill 
in the services, fit it out, and take away the scaffolding. 
Specifications don’t change much over a several year project, and the 
tools don't change at all.

But with software, you can start a big project anywhere you like, and 
before the spec is signed off.  Metaphorically speaking, the plumbing 
can go in before the framework.  Hell, you don't even need a framework! 
  Nothing physical holds a software system up.

And software coding is fast and furious.  In a single day, a programmer 
can create a system more complex than an airport that might take 10,000 
person-years to build.  So software development is fun.  Let's be 
honest: it's why the majority of programmers chose their craft in the 
first place.

Ironically it's the rapidity of programming that contributes the most to 
project overruns.  We only use software in information systems because 
it's fast to write and easy to modify.  So the temptation is 
irresistible to keep specs fluid and to change requirements at any time. 
  Famously, the differences between prototype, "beta release" and 
product are marginal and arbitrary.  Management and marketing take 
advantage of this fact, and unfortunately software engineers themselves 
yield too readily to the attraction of the last minute tweak.

The same dynamics of course afflict third party software components. 
They tend to change too often and fail to meet expectations, making life 
hell for IT systems integrators.

It won't be until software engineering develops the tools, standards and 
culture of a true profession that any of this will change.  Then 
corporate governance will have something to govern in big technology 
projects.

Meanwhile, programmers will remain more like playwrights than engineers, 
and just as manageable.

------------------------------


Cheers,

Steve Wilson.


* FOOTNOTE Before getting into PKI, I spent seven years developing and 
managing real time control software for implantable defibrillators -- 
technically very demanding, and obviously mission critical.  We wrote 
our own multi-tasking operating system (easier to validate), wrote our 
own C compiler (so we could test it too), used a formal specification 
language (Z), formal design reviews and independent test teams, and 
undertook a line-by-line code inspection of the entire system (40,000 
lines; the code inspection took six people two months).  It was 
interesting and effective blend of modern tools, quality processes, 
individual skills, and brute force.  Our demonstrated bug rate was less 
than one per 10,000 lines, by far the best in the world of real time 
software circa 1990.


Lockstep
www.lockstep.com.au
-------------------
  * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
  * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.