[Dev-C++] Software engineering is science AND art

[<ps...@ma...>]

> Date: Sun, 16 Oct 2005 05:13:19 -0700 (PDT)
> From: Vishnu M Menon <vis...@ya...>
> To: dev...@li...
> Subject: [Dev-C++] 5 somewhat-small (but excellent) books in C++/soft.
> engg. you have come across.
> 
> Hello all.
> 
> Suppose you are asked to suggest 5 somewhat small
> books that will significantly improve C++/software
> engineeering literacy in a company whose main product
> is a 500,000 line software written in (you guessed
> it!) C++. Most of the employees are
> otherwise-intelligent Electrical Engg. graduates who,
> unfortunately, write HORRENDOUS code ("it doesn't
> matter what the variable is named as long as it is
> named something", "don't worry about where I place my
> function, just use it", dynamically allocated objects
> where automatic variables would *perfectly* suffice,
> massively redundant coding, zero documentation...).
> 
> What would your suggestions be?
> 
> VM.

It occurs to me that the problem (which is very widespread, imho) isn't
so much technical as it is attitudinal.  Real software engineering is
science with a healthy dose of craftsmanship.  Based on the observations
you made, I don't think any amount of books or courses are going to do
much for those people.  A lot (most) of people are simply not suited for
designing and writing software.  Most people are utilitarian, and "good
enough" is good enough.  To make quality happen, you have to be a
perfectionist with a burning desire to make something elegant and
beautiful.  You have to care.

Sometimes, when people are mentored properly, and when they're exposed
to the right principles, attitudes, and approaches, it can bring out
greatness and great developers are born.  Other times, no amount of
exposure to things done correctly seems to do any good.

I'm very interested in the topic you brought up.  Over the years I've
seen very few truly great designers and developers; most were just
mediocre, and a lot should have never been allowed behind a keyboard.  I
think a lot of it comes with staffing properly.  If anyone thinks you
can take any smart guy, or any engineer, and make him a great developer,
I think he's missing the boat.  People have to really, really love it,
and want it, and it has to come from inside.  Another part of the
problem is that it takes one to know one.  Few people in the position to
make staffing decisions are capable of discerning which end is up.

That said, there are basic things that even poor developers should be
taught so that they approach problems in the right way.  To this end,
over the years I developed a manual of best practices which I gleaned
from a lot of exposure to the good and the bad.  I think that if you can
formalize a description of "best practices," along with explanations
about why this is the right thing to do, and why no other way is
acceptable, you can open dialog and get people thinking about the right
things.  Even time spent arguing about this or that approach has merit,
because intelligent people will begin to think about the value of the
positions taken by the proponents.  

My suggestion is to avoid buying any books- instead, maybe come up with
your own white-paper on "best practices," and start brain-storming with
the guys.  Perhaps if you have a really fine example of some software or
a really slick application (and I'm talking about design and
implementation, not what the end-user sees!) then go over the high
points in a casual setting and let people see how it's done, and why.

Regards,

Israel

-- 
http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again