[prog] State of software engineering profession

[Robert J. Hansen]

> 3.  Always have a plan.  In other words, know what you need and want to do
> before you do it.  This goes back to the 'show us the code' vs. 'show us
> the plan' topic.  They ARE different things.  Code should not be used as
> documentation, because code can be wrong.

So can documentation.  In fact, I suspect documentation is more likely
to be wrong than code is.  At least code you can apply formal reasoning
and analysis to.

>   If the code is also used as
> documentation, how would you know that it is wrong, unless there is
> something else that describes the correct behavior.

That's what requirements documents are for.

> rely on an external QA group to test your software.  An external group
> will never be able to test the software as well as the group that
> developed it.  Usually, black box testing can only verify the use case is

This is, as near as I can tell, in contradiction to the best current
practice.  Every shop I've worked in has kept QA separate, precisely
because developers are so lousy at QA.  We often received builds which
wouldn't compile and we had to fix it ourselves.  Just making sure the
code compiles is the simplest, most basic of checking, and developers
would repeatedly not do it.

> 6a.  Know HOW you plan to test the code when you design and implement it.

This leads to writing test cases which are meant to pass the design, not
to test the code.  "We plan to test the code by entering up to
80-character ASCII strings" leads to some developer thinking "okay, so
all I need are 80 bytes and I'm safe", instead of "I don't know how long
this string is going to be, so I'd better resize it on the fly".

> Often, testing is passed to someone else, so very little thought is given
> to the testing procedure.

Which is insulting to those of us who've worked in QA, and who devoted
quite a bit of thought to figuring out new and interesting ways to make
developers cry.  :)  

QA geeks are not people who give "very little thought" to testing
procedure: a lot of the people who work in QA, and all of the QA people
I know who are worth calling software professionals, take the job
serious as the grave.

ObDisclosure: I started my career doing QA for the software running
telephone switches and exchanges.

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