Re: Software Engineering: Art or Science?

[EMAIL PROTECTED] (Ken Lee) wrote in message news:<[EMAIL PROTECTED]>...
> On Fri, 21 Nov 2003 08:15:25 +0000, Mike Page
> <[EMAIL PROTECTED]> wrote:
> 
> >Gerard Berry of Esterel opens his article in IEE Careers Review of the 
> >above name with the following paragraph :
> >
> >"Software development will qualify as a true engineering discipline only 
> >when it adopts the same scientific and correct-by-construction methods 
> >as other technological fields and applies them throughout the entire 
> >development process."
> >
> >What do people think about this ?
> >
> >TIA,
> >Mike.
> 
> On the question of Art or Science, I believe that this is a perception
> by the developer/software engineer.
> 
> A developer would think that software engineering is an Art if the
> following are evident:
> - that there's no clear path or process by which can be adopted to
> attain a certain level of quality in the software deliverable.
> - that the appropriate level of software "quality" was attained
> fortuitously by the developer's skill and experience alone.
> - that the developer sees no value of using a process.
> - that delivery schedules are a management problem & a hinderance to
> creating.
> - that "perfection" is "quality"  irrespective of cost.
> 
> A software engineer sees software engineering as a Science because:
> - general "Engineering Principles" apply
> - sees the value of a process to ensure a certain level of software
> quality.
> - he/she is a control freak & wants to know the bad news before it
> happens.
> - that software quality doesn't mean "perfection"
> - that a successful software delivery also means meeting schedules as
> well as meeting customer requirements.
> - he/she sees the "Software Process" as the common denominator when
> working within a team of software engineers.

Speaking as a "code cowboy" who's done his engineering mostly as a
lone-wolf programmer or member of a small number of programmers in
a tightly-funded startup, with all the trimmings of impossible deadlines,
zero funding, and moving market targets, I agree.  Even those of us
prone to a bit of Yee Hah! can approach software development
scientifically - even if the bureaucratic approaches that involve vast
paperwork and endless meetings favored by many Big Organizations make
my blood freeze - and, more importantly, just ain't gonna happen.

As someone whose often among the first engineers in a startup, my
approach is to have a few processes rigorously adhered to.  Even one
or two person "teams" should have the following:

1.  Source code control (obviously).  If it is "transactional" (ie,
    permits multiple file submits in one ingress into the source code
    control system), so much the better - I've found plenty of
    hard-to-find bugs by rolling forward change-logs in source code
    control systems until a bug appears.  (Also, #include <std/goodreasons.h>)
    Natch, everything should be there, including specs, notes, marketing 
    collateral, manuals, build scripts, etc...

2.  Good design with API's graven in stone, including reasonably precise
    documentation.  In a startup, good coding fences make for good
    neighbors, particularly when programmers have to work 
    at warp speed - and, by necessity, are often domain experts in different
    fields - so peer strategies like code reviews are of limited utility.

    API's should be designed before much code (if any), is written.  API's 
    should be stub implemented and integration done early as well, so that 
    gotchas in API design can be isolated and rooted out before they break
    the world.  (Stub-implementation of API's has the additional useful
    property of permitting "real" demos.)

3.  Don't be afraid to toss throwaway demo code that has to be cobbled up
    early to get funding.  IMO, this causes tons of problems in startups:
    the fact that a demo appears to trivially function confuses management
    into thinking that there's more there than there really is, and the
    hacked-together throwaway demo source becomes the codebase for the Real 
    Product.  This must be avoided at all costs, even if means getting into
    the face of management.  My own take: if management isn't willing to
    allow at least some level of proper engineering to be done, the startup 
    isn't going to fly anyway.

4.  API's should be testable in isolation.  This one is hard, and takes
    precious time, but is worth the effort in having measurable progress
    of each piece of the system.

5.  Test early, test often.  Early on, one should probably be putting as much
    engineering effort into the test infrastructure as one puts into product
    development.  Frankly, you can't deliver a deadline until you have a
    test environment worthy of the name so you can see what's working, what's
    still broken, and what still needs to be implemented.  Note that if 
    performance matters in the product, one will need both "correct answer"
    testing as well as timed testing.

6.  The only Rational tools I'll plug are Purify (memory leaks and corruption)
    and Pure Coverage (for coverage analysis).  Having a well-covered
    testsuite pass and running purify-clean with good coverage means you have
    a solid product.  I also like gprof for profiling - it's especially good
    for cleaning up performance issues.

    Greg Kemnitz, Programming Cowboy :)
    [EMAIL PROTECTED]