Software Engineering: Art or Science? - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Software Engineering: Art or Science?
On Fri, 21 Nov 2003 08:15:25 +0000, Mike Page

Quoted text here. Click to load it

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.

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Software Engineering: Art or Science?
snipped-for-privacy@noname.com (Ken Lee) wrote in message
Quoted text here. Click to load it

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 :)
     snipped-for-privacy@yahoo.com

Re: Software Engineering: Art or Science?
Quoted text here. Click to load it
... snip solid advice ...
Quoted text here. Click to load it

Much depends on what you mean by API.  Of course you have to
design the interface between modules before implementation (and as
far as I am concerned any OS is just another module), and once
done changes in such interfaces are grave decisions.  But the
important thing IMO is to do the design top-down.  That will do
the initial partitioning, and the interfaces will develop
naturally from the demands.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Software Engineering: Art or Science?
Quoted text here. Click to load it

I agree.  I usually follow what I call the "Christmas tree approach"
and design the gateway API's to the main modules of the system initially,
after figuring out the "galactic" questions of the high-level design.
Then, the first piece of code I'll write is the error subsystem - which,
of course, was carefully and completely designed :)  (I'm not sure why
error handling is still approached as an afterthought in so many
designs...)

After this, the gateway API's are completely coded as stubs which
report error and somehow indicate "Hey, I'm not implemented yet!".
Once this is done, the "ornaments" (ie, working code replacing the
stubs) are hung on the "tree".

The "Christmas tree approach" has the useful properties of a good
top-level partitioning, a quick shot at "something that appears
to work" - which is both useful for progress demos as well as
getting integration done as early as possible with external subsystems,
if this is relevant.  It also gives something "real" to build the
test fixture/infrastructure around so it can be built, tests can be
written, and testing in general can begin as early as possible.

    Greg Kemnitz
     snipped-for-privacy@yahoo.com

Re: Software Engineering: Art or Science?
           snipped-for-privacy@yahoo.com "Greg Kemnitz" writes:

Quoted text here. Click to load it

Hi Greg,

I like the Christmas tree analogy. When you are waiting to get your
hands on the hardware it is a very useful technique that allows you
to prepare the rest of the application. It would be helpful if you
have the means to certify the interfaces of the stubs to be correctly
functioning and reporting the errors properly (minimising the chances
that you are fooling yourself).

With an appropriate level of pre-specification and technical review
your Christmas tree approach could be considered as part of asound
engineering process.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Software Engineering: Art or Science?
On Fri, 21 Nov 2003 08:15:25 +0000, Mike Page

Quoted text here. Click to load it

Except for hard DSP applications, or realtime closed-loop control,
software design seldom has a mathematical (or even theoretical) basis,
and no predictive theory is used in software system design. People
mostly just write code based on experience, and then try it out. This
certainly isn't science, and barely qualifies as engineering.

It would only be art if the programs were beautiful, but they're
usually ugly.

John


Re: Software Engineering: Art or Science?
snipped-for-privacy@highSNIPlandTHIStechPLEASEnology.com says...
Quoted text here. Click to load it

I think the word you are looking for is craft.

Robert

 

--
" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
We've slightly trimmed the long signature. Click to see the full one.
Re: Software Engineering: Art or Science?

Quoted text here. Click to load it

IMO, a very simple and probably wrong definition of art.

Like anything people create, programs may be craft, art,
science or just crap. Most of the time, I create crap...
but there are those few highlighted moments.

Harald

--
For spam do not replace spamtrap with my name


Re: Software Engineering: Art or Science?
           snipped-for-privacy@highSNIPlandTHIStechPLEASEnology.com "John Larkin" writes:

Quoted text here. Click to load it

I don't know where you have experienced software development but it
certainly is not that way with me. I do have a theory, ahead of writing
code, of what I want achieved by the code, how it will sit on the
hardware and also a risk and reliability assessment down to the module
level. I often write the definitive description of what is required
of many of the sub-routines (certainly the upper abstraction layers
and the hardware interface layers). From this attention to detail I
can certify that the code does exactly as required as specified by
that definitive description (glossary text).
 
Quoted text here. Click to load it

If the code starts looking ugly you have taken a wrong direction
somewhere and should go back and re-think. Robust code is most often
simply elegant and beautiful to behold. I think that applies in most
languages and is not just a Forth thing.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Software Engineering: Art or Science?
On Thu, 27 Nov 2003 22:23:28 +0000 (UTC), snipped-for-privacy@amleth.demon.co.uk

Quoted text here. Click to load it

If you're like me & are a druid, tone-deaf and totally colour
un-coordinated, then I'd start to rely on software metric tools such
as McCabe's Cyclomatic Complexity index. Also it's sometimes difficult
(and possibly un-diplomatic) to criticize a team member's "beautiful"
code --- it's more palatable to let a utility be the "art" critic.
Best applied to team members who have "acceptance" issues and a large
collection of handguns & "home protection" appliances ;-)

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Software Engineering: Art or Science?
Quoted text here. Click to load it
writes:
Quoted text here. Click to load it

One of the easiest metric is the number of warnings when using -wpedantic
with gcc. I often wonder how people can write code where a warning appears
on every second line or so...

We use quite a lot of 3rd party software, that falls into that category. At
another company I had to fix a project. All compiler warnings were
switched of because they wouldn't find the errors in the output anymore !
I think you get the idea about the quality of that code.

Cheers
- Rene







Re: Software Engineering: Art or Science?

Quoted text here. Click to load it

As a metric measure, I guess one could monitor the number of C
language non-conformances, say per week (or month). Most compilers,
like GCC do a moderate job of this at best. One should use a proper
Lint tool to get a more comprehensive coverage. Where I work we don't
track Lint output, however we do assess the Lint output at code
inspections. On a monthly basis, we do look at the McCabe Index and
the delta size of all components. The defects database is reviewed by
the team leader basically everyday and usually trended every month.

Quoted text here. Click to load it


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Site Timeline