[prog] State of software engineering profession

[Jimen Ching]

On Tue, 15 Apr 2003, Robert J. Hansen wrote:
>> 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.

There are different types of documents.  Requirement documents tell you
what your goals are.  Design (high level) documents tell you how you
intend to achieve these goals.  Design (low level) documents describe
details about the implementation.  Source code, can be used as
documentation for formal reasoning and analysis.  These documents should
not be interchanged.  They should be treated different, and written
different.  Each one has their purpose and importance.

>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.

Well, given this problem, my first action would be to determine why
developers are lousy at QA.  If the QA process is internal to the
development process, unbuildable source code would not be considered an
acceptable output of the development step.

I guess there are two solutions to poor developer testing; 1. hire QA
superstars, or 2. have a process that forces your developers to test
better.  I guess you chose the first, and I prefer to choose the second.
My experiences has been that the second solution produces better quality
software.  Though the first solution makes sure you meet your goals.  So
both solutions should probably be used.  But for different purposes.

>> 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.  :)

I guess I could have used better wording.  Let me rephrase:

	Often, testing is passed to someone else, so the programmer
	gives very little thought to the testing procedure.

My intent was to imply that the programmers, when given the option to pass
the responsibility to the next group, they will do that.  Don't let them
do that.  Because the programmer is often in a better position to think
about these things.  They know more about how the software should
behavior.  Or at least they should.

I noticed you tend to read my emails literally.  If in the future, my
comments are ambiguous or incomplete, could you just point it out and ask
me to explain?  This would remove a lot of the disagreements.  I'll have
to post followup emails to correct my earlier posts anyway.  So there's no
point in going on about things that weren't meant to be said in the first
place.  From now on, I will try to select my words better.  But English is
not my first language.  So my selection of words, or leaving out crutial
sentence fragments, is likely to happen again.

--jc
-- 
Jimen Ching (WH6BRR)      jching at flex.com     wh6brr at uhm.ampr.org