From: Bob Stout 

On Sun, 4 Apr 2004, Bruce D. Wedding wrote:

> > As you can see by how long it took me to respond, things have been
> > busy. The project I've been working on since early last year is
> > starting field trials on a real well next week, so I've been pretty
> > much buried in last minute adjustments and documentation for the past
> > month. I just finished the 120 page detailed design/implementation
> > spec yesterday. My partner on the project is taking the spec with him
> > to the field for further revisions, so I have a week of
> > lower-intensity stuff to do, hence my return here.
>
> Aren't you supposed to write the SRS and SDD BEFORE you write the code? :-)

Hey, this is the first firmware project this company has ever done that had
a real honest-to-goodness functional spec of any sort! I insisted on it
when I started. The detailed design spec is actually more of an
implementation spec. The functional spec actually delved into the design
more than a functional spec actually should do, so the whole process became
a trade-off. By the time the functional spec was done, I sensed that I'd
burned up enough good will so that I should write the implementation spec
as an after-the-fact process.

Now that they've seen what can be gained from actually specifying and
designing firmware, as opposed to it just happening or being hacked on the
fly, they might decide it turned out well enough to do it again. One
significant change I did institute at the outset of the project was to set
a VCS repository (none of the extant firmware is under any sort of VCS) and
to show them with software complexity metrics and Lint why their old code
was so fragile. This was all new stuff to them. In their defense, I should
note that the company is mostly mechanical and hydraulic engineers.
Firmware of this complexity in downhole tools is a relatively new idea to
them.

The real problem is that it's all been a mixed bag. Some of the guys on
some of the projects really do know how to do professional development.
However, the conventional wisdom has been to hide that knowledge and do the
right thing away from prying eyes. As a result, there's some stuff good and
some stuff bad, but no way to assure which way any individual project will
turn out. The worst part is that without any VCS, all historical insights
into the code are lost. There are numerous horror tales of programmers
there having to rewrite products over and over simply because no one could
locate the proper version (or maybe *any* version) of the old code.

IOW, not even state-of-the-art firmware development even if we turn the
clock back 2 decades!

-------------------------------------------------------------
Consulting: http://www.MicroFirm.biz/ Web graphics development:
http://Image-Magicians.com/ Software archives:
http://snippets.snippets.org/
  c.snippets.org/   cpp.snippets.org/      java.snippets.org/
  d.snippets.org/   python.snippets.org/   perl.snippets.org/
  dos.snippets.org/ embedded.snippets.org/ apps.snippets.org/
Audio and loudspeaker design:
  http://LDSG.snippets.org/   http://www.diyspeakers.net/

--- BBBS/LiI v4.01 Flag-5