[prog] State of software engineering profession

[Jimen Ching]

On Mon, 14 Apr 2003, Mary wrote:
>Let's rephrase. Discuss your experiences.
>
>What bad experiences have you had? How long have you been in the
>industry? What sort of design-implementation cycles have you been part
>of? What was wrong with them? Why are you saying this? Have you had a
>chance to lead a team using your ideas, or anyone else's for that
>matter? How did it turn out? Who have you talked to about this? What did
>they say?

If you knew my answers, you might not want to ask.  ;-)  But since you
did, here goes...

Most of my experiences have mostly been negative.  This is why I have such
a negative view point of the software industry as a whole.  Note, I didn't
base this solely on what I see within my own experiences, but on
descriptions of other's experiences as well.  In my previous job, I work
for a commercial company (meaning, it is totally customer based).  The
development process (if you can call it that) is horrible.

Requirements change constantly, because it is based on customer requests,
and the customer keeps changing their minds because the market keep
changing.  I did have an opportunity to lead a project/group.  But because
the requirement keeps changing, and support of older products are
required, people are kept being pulled away for other work.  As a result,
things are always half done, and code is passed through multiple hands
before it is made to work.  This is made worst by the fact that each set
of hands has their own idea of what is the best way to implement the
design.  Things I've learned that are good practices?

1.  Keep the same group of people throughout the project's cycle.  When
people are moved in and out of a project, the goal and design loses focus.
This is never a good thing for a project.

2.  Rotate responsibility.  I.e. don't pigeon hole your engineers.  It
gets boring when you do the same thing over and over again.

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

4.  Never schedule the entire project.  It will never work out anyway.
Instead, identify major milestones, and schedule only to the next
milestone.  Of course, you should know the alotted time for the project.
And, this may be obvious but, have a prioritized plan before coming up
with a schedule.  How else can you develop a schedule?  ;-)

4a.  Always give youself two weeks of slack when dealing with hardware.
Note, the slack should not include delivery of hardware.  In other words,
if you've scheduled a month for a driver for some hardware, starting from
the PO to a working driver, add two weeks to that.

4b.  Try to identify the highest risk hardware as soon as possible and set
it in motion.  High risk hardware are defined as hardware that is new (to
the market), or that you haven't worked with before.

4c.  If you need to work with 3rd party libraries, its a good idea to try
to select one that comes with source code.  It is a lot easier to control
the schedule when you don't have to schedule around the 3rd party vendor's
whims.  Note, I'm not talking about free/open source software.  Many
library vendor's are willing to ship source code.  Its just that most
people don't ask.

5.  Understand your data movement and design with this knowledge in mind.
One of the biggest problems I seen is that designs are put together
without knowing how the data moves inside the application.  As a result,
the data is scattered all over the place, and then massive amounts of
effort is expended to try to merge everything back together.  Data
movement is very important to a design.  Of course, this might be specific
to the type of application I've developed.  But I'd imagine data movement
is important to most applications.

6.  QA is a duty, not a position.  Testing should be tightly integrated
with the development cycle and to the development group.  If you're told
that you'll have a 'QA person', treat this person as a first level
customer.  In other words, you should always have your own QA process.
Treat an external QA group as a customer.  To put it another way, don't
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
met.  It can't make any assurances about quality.

6a.  Know HOW you plan to test the code when you design and implement it.
Often, testing is passed to someone else, so very little thought is given
to the testing procedure.  As a result, testing is difficult, and only a
little of it is done.  This is why the previous rule is so important.
Said another way--design and implement with testing in mind.

Last, and most important of all, nothing is ever written in stone.  You
can always go back and 'update' things.

In case you might ask what qualification I have to back up these
best-practices.  Well, my only qualification is experience.  I have used
most of the above in my own work, and things have turned out well.  For
those that I have no control over, I've left my previous employer after 7
years because I was tired of the chaos from not following these practices.
Yes, I did mention these practices to them.  All I got back were excuses
for not implementing them.  I got the impression they simply weren't
interested, and I got tired of waiting for them to change their mind.

>Jimen: "Software engineeing should be better."
>Others: "Yes. How?"

I don't know about the others, but it seems to me that Robert and I have
been disagreeing through out the thread.  But that's probably due to
miscommunication more than anything else.  Of course, you and Jenn
(Vesperman) have been continually giving me counter-examples for each of
my responses to Robert.  But perhaps I've misunderstood the purpose of
those counter-examples.

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