Software Development Practice in the 21st (22nd?) Century

A couple of months ago I published an article about 10 Critical Requirements Principles for 0-Defects-Systems (on Ravens Brain). Anecdotal evidence on how I once achieved zero defects in one of my projects.

If you like the thought of reliable software (sic!) you might as well like Charles Fishman's article on the On-Board Shuttle Group, the producer of the space shuttle's software. Yes, they have a lot of money to spend, but many lives and expensive equipment are at stake.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. -- Charles Fishman on the software product the Group puts out

BTW, they seem to use three key pracices: very detailed requirements, inspections and continuous improvement.

The way the process works, it not only finds errors in the software. The process finds errors in the process. -- Charles Fishman on the On-Board Shuttle Group's process

Happy New Year! (Note that 2009 is a year of the 21st century. Can't we do any better?)

PS: I'm going to go on vacation from Dec 28 to Jan 20. More interesting topics still to come, please be patient.

Lewin on Theories

Just this cute little quote here, for all of you who need to be assured of their "sometimes too theoretical work":

There's nothing as practical as a good theory. - Kurt Lewin

Merry Christmas, and sorry for all the clutter around short posts ;-)

News in the Field of Systems Engineering

For a VERY comprehensive monthly newsletter on Systems Engineering go to the Project Performance International website. A quote from the site:

Project Performance International is proud to produce a monthly Systems Engineering newsletter, named "SyEN". The newsletter presents in-depth coverage of the month's news in systems engineering and directly related fields, plus limited
information on PPI's activities and relevant industry events.

The nice thing is, advertising is REALLY limited. I find the newsletter do be both interesting and easy to read. They will send you and E-Mail with an table of contents, and you can then go to the website and read it. PDF format ist also provided.
From this months contents:

• Featured Article: The ISO Way - Alwyn Smit
• Featured Society: Association for Configuration and Data Management (ACDM)
• Systems Engineering Software Tools News
• Systems Engineering Books, Reports, Articles and Papers
• Conferences and Meetings
• Education
• People
• Related News
• Systems Engineering-Relevant Websites
• Standards and Guides
• PPI News
• PPI Events

Why Re-work isn't a Bad Thing in all Situations.

Software Development has many characteristics of production. I'm thinking of the various steps that as a whole comprise the development process, in which artifacts are passed from one sub process to another. Requirements are passed on to design, code is passed on to test (or vice versa, in test driven-development), and so on.

Alistair Cockburn wrote an interesting article on what to do with the excess production capability of non-bottleneck sub-processes in a complex production process. In the Crosstalk issue of Jan 2009, he explores new strategies to optimizing a process as a whole. One idea is to consciously use re-work (you know, the bad thing you want to avoid like the plague) to improve the quality of affairs earlier rather than later.

In terms of what to do with excess capacity at a non-bottleneck station, there is a strategy different from sitting idle, doing the work of the bottleneck, or simplifying the work at the bottleneck; it is to use the excess capacity to rework the ideas to get them more stable so that less rework is needed later at the bottleneck station.

Mark-up is mine. You see the basic idea.
In conclusion he lists the following four ways of using work that otherwise would have spent idling around, waiting for a bottleneck to finish work:

* Have the workers who would idle do the work of the bottleneck sub-process.

Note: Although this sometimes is mandated by some of the Agile community, I have seldom seen workers in the software industry that can produce excellent quality results in more than one or two disciplines.

* Have them simplify the work at the bottleneck sub-process.

Note: An idea would be to help out the BAs by scanning through documents and giving pointers to relevant information.

* Have them rework material to reduce future rework required at the bottleneck sub-process.

Note: See the introducing quote by A. Cockburn. Idea: Improve documents that are going to be built upon "further downstream" to approach a quality level of less than 1 major defect per page (more than 20 per page is very common in documents that already have a 'QA passed' stamp).

* Have them create multiple alternatives for the bottleneck sub-process to choose from.

Note: An example would be to provide different designs to stakeholders. Say, GUI designs. This can almost take the form of concurrently developing solutions to one problem by different engineering teams, for the best solution should be evaluated and consciously chosen.

Lack of Engineering Practices Make 'Agile' Teams Fail

James Shore wrote a blog post that is among my TOP 5 in this quarter. Go read it! He argues that the industry sees so many agile projects fail because most teams that call themselves 'agile' mistake the real idea with the wrong set of practices. Maybe this quote says best what his article is about:

These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff--the stuff that's really Agile--they're setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won't last.

This speaks from my heart. It's exactly what happened when I tried to turn a project 'agile' in a super waterfall organization (picking up this metaphor I'd say it's an Angel Falls organization). We will have technical debt to pay off for at least a decade. However, we found that out quite quickly ;-)
If you're looking for some method that is strong both in the management and engineering field, check out Evo by Tom Gilb. I know I recommended Mr. Gilb's work over and over again in the past 2 years, and it almost seems ridiculous. Be assured, I'm not getting paid by Tom :-)
To get a very clear perspective on iterative planning check out Niels Malotaux' Time Line.

Use Case Content Patterns Updated

Martin Langlands incorporated "my" DESTRUCTOR pattern into one article, now version 2 of his Use Case Content Patterns description. Have a look here, the whole thing is easier to handle now.

Hint: Click 'files' at the bottom of the wiki page to see the pattern file. Sorry for the inconvenience!

Patterns for Use Case CONTENT, anyone? Yes, finally!

While modelling use cases, have you ever thought 'I have modelled something very similar before.'? Here's a solution to re-occuring modelling tasks. Martin Langlands has developed a bundle of patterns for the content of use cases. He developed these with an extensive backround in banking and insurance systems. After reading his well written article it I found myself in a very different field but still the patterns were applicable, to say the least. I think they are ready to use in most areas of concern, and the idea should set the use case modelling world on fire!

Visit Planet Project to see the respective Process.

Note: I proudly contributed the idea of another pattern to Martin's, the DESTRUCTOR pattern ;-) Go have a look.