[prog] State of software engineering profession

[Robert J. Hansen]

> My position is that software implementation IS design, down to finer and
> finer amounts of detail.

On a related note... here's the way software was implemented when I was
working at <unnamed major US telephone company currently in bankruptcy>:

The way it worked in theory:

1.  Customer requirements document gets created (what things must the
software do to pass muster).  Customer test cases get created.

2.  Design document gets created (overview of how the software will work
so as to meet #1).

3.  Specification document gets created (implementation of #2).

4.  Code gets written

5.  Code gets QA tested.

6.  Code gets shipped.


The way it worked in practice:

1.  Requirements doc gets created.  (Supposedly, QA wrote test cases at
this point; realistically, we usually didn't do it until Step 4.)

2.  Code gets written.

3.  Code, minus any documentation, gets handed to QA.

4.  QA reads the CR doc and writes the test cases.

5.  QA reads the code and writes Technical Design and Technical Spec
documents.

6.  QA validates the code against test cases QA has come up with.

7.  It's stamped with a "Pass" and sent on down the line.


... Obviously, that's a recipe for disaster.  It'd be simple to say the
solution is just to do it properly (i.e., according to theory), but that
doesn't work, either.  In fact, our practices came about _as a response
to_ failures of the theory... if you think the practice is bad (I
certainly do), the theory was even worse.

The reason why the theory failed so badly, near as I can tell, is
because of the consequences of what Jenn just said.  Software
implementation _is_ design--or rather, design is software
implementation.  Because any design document which is clear enough,
precise enough, and unambiguous enough to be useful would be precise
enough and unambiguous enough to be compiled directly into machine code.

When we did things according to theory, what wound up happening was we
got design documents with subtle contradictions, corner cases which were
left unhandled... i.e., we found bugs in the design.  Sometimes the bugs
could be fixed while still keeping the design intact; and other times we
had to totally break the design.  Sometimes, small and subtle changes
had catastrophic effects.  So the only sensible way to design the
software was to _write_ the software, and let the source code be the
design.

Writing the code first, and then writing a design from the code, is a
horribly broken way to do business.  But it's a lot smarter than to
write a design document first, get bureaucratically married to it, and
be unable to overcome its inertia when you have to deviate from the
document later to overcome unforeseen bugs.


-- 
Robert J. Hansen <rjh at sixdemonbag.org>