Software Engineering: Art or Science?

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

Translate This Thread From English to

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

--
Mike Page BEng(Hons) MIEE           www.eclectic-web.co.uk


Re: Software Engineering: Art or Science?
Hmmmm.  Is bridge building a "true engineering discipline"?  Only when
building the umpteenth similar bridge.  Try and solve a new problem, or an
old problem in a new circumstance, and suddenly you have Tacoma, box section
bridges collapsing during build, and London's beautiful Millennium Bridge.

Same with s/w.  If you are solving an old problem, s/w should be correct.
If not, well, there's always the unforeseen waiting to ambush you.

Disciplines advance by mistakes.  No mistakes, no discipline.

Just my 2d.

Quoted text here. Click to load it



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

   The PBS series Nova has a show about the building of a
new-design suspension bridge across the Mississippi near
Alton, Illinois.

http://www.pbs.org/wgbh/nova/bridge /

   It makes bridge building look a lot like software.

        Regards.        Mel.

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

Not knowing what's in the rest of the article, I'll take a guess that
it's trite and/or unrealistic dross. Software development *CAN* be
approached as a "true engineering discipline", but commercial
realities mean that it is rarely seen that way for the vast majority
of shipped applications.

Building software is not like building bridges, for a plethora of
reasons that have been discussed here and elsewhere. This issue has
been flogged harder and more frequently in here than a lone submissive
at a dominatrix resort, but I'll go through a few points anyway:

* Bridges are made of components that are exactly specified and
guaranteed to meet performance criteria. Perhaps more importantly, all
the vital criteria of, say, a bolt or an I-beam can be enumerated.

* Bridges are built to an *exact* specification, which virtually never
exists in software projects.

* Bridges are built, installed and then slowly begin to fall apart,
requiring regular maintenance that restores defective parts to their
original as-installed condition. Software, in contrast, remains
undeteriorated forever. "Maintenance" on software consists of adding
features or changing functionality; IOW, breaking things.

* Bridges are a low-volume product with a high cost of failure and a
simple feature set. You need look no further than Microsoft to see
that the "best" (speaking from a profitability standpoint) model for
writing software is to target some high-volume need, assume there is a
low cost of failure, and build an excessively complex product with a
vast feature set that appears to be more attractive than competing
products.

Re: Software Engineering: Art or Science?

I agree with all your points except this one:

Quoted text here. Click to load it

Software "breaks" because the environment changes: people use data
that hadn't been tried before (y2k); h/w and o/s changes; Database
sizes and disks grow to unanticipated sizes; user come to expect
"more" that was never in there in the first place.


Quoted text here. Click to load it

This point is pretty debatable: whole bridges are usually one-off,
while some software COMPETES with similar software for the same job.

Art or Science?  Software like other engineering art is a blend.
  - RM


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

Whole bridges are ceratinly one of, as much as custom software.
Depending on the budget you may get different bridges with different
safety factors, when all else (length, width, load, ..) is equal.
The difference being you unlikely driving such hard bartering for
a bridge as is usual for software.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Re: Software Engineering: Art or Science?
In these cases the software has not broken. It is still operating
within the requirements in place for which it was written. What you
cite is a case of requirements being exceeded or changing functionality.
I can't think of anything similar to metal fatigue or corrosion in software.
Not one bit of the code changes as a result of time or use. Software
does not wear out.

Doug

Quoted text here. Click to load it



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

Please do not toppost.

Software does not function in isolation, it requires a machine on
which to run.  The combination DOES wear out.  Just as bridge
traffic may get rerouted to avoid potholes, or newly required
weight limits, software may be modified to avoid equivalent
problems.

I used to have a machine with a failed key on the keyboard.  I
installed something that allowed an escape sequence (via a
function key) to emulate that key, and used the machine for quite
some time without repairs.

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

True,  but it is not uncommon for software to fail as the underlying
OS changes.  How many old DOS apps,  particularly those directly
accessing the hardware,  will still run properly under Win XP?

<SNIP>

Mark Borgerson


Re: Software Engineering: Art or Science?
           snipped-for-privacy@oes.to "Mark Borgerson" writes:

Quoted text here. Click to load it

If you change the underlying OS you have just changed the requirements
of the application. The specification for software must include the
environment in which it is expected to run. Change the OS you need to
re-do validation and make new statements of performance under the
changed operational environment. To not do so is sheer negligence.

As to the costs of developing software in an appropriate engineering
manner, this is not that much greater than merely hacking code together.
Those who just hack code together without much by way of design are
going to spend an innordinate amount of time seeking out the bugs that
they will have introduced. They will have no idea how many bugs are
in their software and so will not know how many they need to eliminate.

A proper engineering process for software is not that complicated or
onerous to implement. It does not have to cost very much to apply and
there are benefits in minimising the testing that must be done (due
to what can be inferred about modules prior to final integration).
This latter may be seen to apply where there is a high level of re-use
of software modules and a level of trust built up in the compiler tools
in use in a development team. Naturally, if you change the tools you
need to revisit building the trust in those tools.

A hardware developer will have access to a component datasheet for
each component he designs into the product. There is absolutely no
reason for a software developer not to have access to similar levels
of documentation about every software component he uses. If you have
none of this then you are really just guessing at your solutions.

In conclusion, if you are not following an engineering process to
develop your software then you are not engineers. Those who are not
engineers should steer well clear of mission critical applications.

--
********************************************************************
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
software.
Probably very few.. but then Windoze XP is not DOS either.. in fact what is
it ???



Re: Software Engineering: Art or Science?

Quoted text here. Click to load it

The bastard son of Win 3.1 and VMS.

Quoted text here. Click to load it

I just wrote a simulation program to track the timing and paths of
ions moving through time-variant electric fields. I used PowerBasic
for DOS, with full graphics. It works fine under XP. DOS apps that do
serial i/o seem OK too. I've always thought that '98 and up were
damned fine DOS platforms.

'98 allows i/o port access from a DOS app, and 2K/XP can be hacked
with 'totalio' or similar add-ons.

John


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

Engineering is the art of applying the appropriate science
to the problem at hand.

Re: Software Engineering: Art or Science?
Hi Rick,

Quoted text here. Click to load it

This is kind of a side-swipe along what I was saying. Bridges can get
unexpected inputs too; a bridge designed 200 years ago to carry
pedestrians and the occasional horse will probably not endure the
weight a Kenworth 18-wheeler hauling a shipment of Yugos to the
junkyard.

What I was saying is that *software* does not deteriorate. (The
hardware that's storing and running it can and does deteriorate, but
the software itself remains immutable, much like the King James Bible;
by definition, every copy of software version 1.0000 - or the KJV - is
exactly the same as every other copy).

So the idea of "maintenance" has very different meanings between
bridges and software.

Quoted text here. Click to load it

Bridges have competition too. Should the bridge be a road bridge or a
rail bridge, or both? How many levels should it have? Where exactly
should it cross the river? Should there be multiple redundant bridges?

It just so happens that it's much more expensive to replace a bridge
than to upgrade given hardware with a new software version. So you
don't often get bridge "upgrades".

Quoted text here. Click to load it

True.

Re: Software Engineering: Art or Science?
           snipped-for-privacy@larwe.com "Lewin A.R.W. Edwards" writes:

Quoted text here. Click to load it

There are a few application areas (Safety Critical ones) where the
cost of failure is so high the software does get developed with the
proper level of engineering discipline. It is, sadly, not the majority
of applications that get this treatment. Surprising really as there
is not really that much difference between the cost of doing it right
to just hacking something together.
 
Quoted text here. Click to load it

Yet, with a little more fore-thought, it is possible to provide a closer
specification for software that details performance  and robustness
requirements. Those among us aspiring to be truly "Software Engineers"
should already be seeking to improve specifications they produce or
receive.
 
Quoted text here. Click to load it

Now, this is where we should really begin to change our attitudes.

Maintaining a bridge does not change its functionality therefore
maintaining software should not do so either. I know that some
bridges (in the UK) are currently being strengthened to cope with
the increased traffic demands (a performance enhancement). I can
think of no example in software where adding more code (functions)
improved performance (changing up to faster processors does that
for us).

While software may not deteriorate there may be some aspects that
need adjustment (although this should be quite rare). If a change
of functionality is required (including performance improvement)
then the product of such changes is "new" software and as such should
be subject to complete revalidation and verification.
 
Quoted text here. Click to load it

The only thing about mass-producing software is that the production
tools do not leave their wear signature on the end product. If the
software being mass-produced was much better thought-out and of better
quality we would all, I am sure, be happier users (or do you think we
might then find something else to moan about).

--
********************************************************************
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 think a better phrase would be 'appropriate' level of engineering
discipline. Not surprisingly there is significantly higher cost of
engineering in safety critical applications.

Ian


Re: Software Engineering: Art or Science?
snipped-for-privacy@amleth.demon.co.uk ("Paul E. Bennett") writes:

Quoted text here. Click to load it

Usually the cost difference is large.  The pressure is to design code
faster and with fewer people.  I've never encountered top down
pressure to slow down or over engineer things.

The difference isn't between "just hacking something together" and
doing it right.  The teams that create extremely reliable code (space
shuttle stuff) often rely on multiple levels of redundancy, every line
of code is scrutinized by many people, etc.  That effort is not put
into typical professionally designed code, because companies can't
afford it.  If the market demands the product be done in one year,
then that's what is going to be pushed down to the developers, even
before the design starts.

Quoted text here. Click to load it

Which is, again, too expensive for most companies to do.  There's a
market expectation too.  Most customers that buy bridges realize that
there's a massive cost to adding a few more lanes, maybe the same cost
as building a new bridge.  Most software customers don't think that
way though; they know that company X, Y, and Z all support the new
standard today, so you should too (and without any noticeable price
increases or significant delays).

--
Darin Johnson
    "Look here.  There's a crop circle in my ficus!"  -- The Tick

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

It's about half bullshit.  Otherwise bridges and buildings
would never fail...

--
Grant Edwards                   grante             Yow!  This PORCUPINE knows
                                  at               his ZIPCODE... And he has
We've slightly trimmed the long signature. Click to see the full one.
Re: Software Engineering: Art or Science?
He is right. We still do not have software processes that can
deliver software on a predictable schedule.

What we really need is a focus on the CMM. Achieving CMM
level 3 or above can lead to a predictable software development
schedules.

Use of object oriented design and Keep It Simple techniques
will also help. Too often software architects complicate
the design much more than it needs to be.

See the following article:
http://www.eventhelix.com/RealtimeMantra/KeepItSimple.htm

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool

Re: Software Engineering: Art or Science?
On 22 Nov 2003 17:00:10 -0800, snipped-for-privacy@hotmail.com (EventHelix.com)

Quoted text here. Click to load it

Very apt. Every Software Engineer should keep a copy of your  "Keep It
Simple" mantra, pinned up in front of them.

Ken.


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

Site Timeline