Software Engineering: Art or Science?
Mike Page
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
Bill Davy
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.
"Mike Page" <mi...@SCRUBeclectic-CAPSweb.BLAMEco.SWENuk> wrote in message
news:10694025...@ananke.eclipse.net.uk...
Lewin A.R.W. Edwards
> 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 ?
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.
Grant Edwards
> 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 ?
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
visi.com "VISA"!!
Rick Merrill
I agree with all your points except this one:
>... Software, in contrast, remains
> undeteriorated forever. "Maintenance" on software consists of adding
> features or changing functionality; IOW, breaking things.
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.
> * 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.
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
Mel Wilson
"Bill Davy" <Bi...@SynectixLtd.com> wrote:
>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.
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.
Paul E. Bennett
la...@larwe.com "Lewin A.R.W. Edwards" writes:
> > What do people think about this ?
>
> 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.
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.
> 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.
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.
> * 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.
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.
> * 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.
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).
--
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Ian Bell
> In article <608b6569.03112...@posting.google.com>
> la...@larwe.com "Lewin A.R.W. Edwards" writes:
>
>> > What do people think about this ?
>>
>> 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.
>
> 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.
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
Rene Tschaggelar
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
Doug Dotson
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
"Rick Merrill" <RickM...@comTHROW.net> wrote in message
news:bxqvb.199195$mZ5.1478863@attbi_s54...
Darin Johnson
> Surprising really as there
> is not really that much difference between the cost of doing it right
> to just hacking something together.
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.
> 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.
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
EventHelix.com
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
Everett M. Greene
> Art or Science? Software like other engineering art is a blend.
Engineering is the art of applying the appropriate science
to the problem at hand.
CBFalconer
>
> 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.
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 (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Lewin A.R.W. Edwards
> I agree with all your points except this one:
>
> >... Software, in contrast, remains
> > undeteriorated forever. "Maintenance" on software consists of adding
> > features or changing functionality; IOW, breaking things.
>
> 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.
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.
> > * 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
>
> This point is pretty debatable: whole bridges are usually one-off,
> while some software COMPETES with similar software for the same job.
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".
> Art or Science? Software like other engineering art is a blend.
True.
Mark Borgerson
> 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.
>
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
Paul E. Bennett
m-a...@oes.to "Mark Borgerson" writes:
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.
Ken Lee
wrote:
>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
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
Ken Lee
<mi...@SCRUBeclectic-CAPSweb.BLAMEco.SWENuk> 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.
John Larkin
<mi...@SCRUBeclectic-CAPSweb.BLAMEco.SWENuk> 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.
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
R Adsett
jjla...@highSNIPlandTHIStechPLEASEnology.com says...
> 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
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
chew a radio signal. "
Kelvin Throop, III
TheDoc
"Mark Borgerson" <m-a...@oes.to> wrote in message
news:MPG.1a29a0091...@Netnews.Comcast.net...
it ???
Harald Kipp
> It would only be art if the programs were beautiful, but they're
> usually ugly.
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
John Larkin
The bastard son of Win 3.1 and VMS.
>
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
Paul E. Bennett
jjla...@highSNIPlandTHIStechPLEASEnology.com "John Larkin" writes:
> 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.
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).
> It would only be art if the programs were beautiful, but they're
> usually ugly.
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.
Greg Kemnitz
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 :)
fooba...@yahoo.com
CBFalconer
>
... snip solid advice ...
>
> 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.)
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.
Ken Lee
("Paul E. Bennett") wrote:
>In article <lej7sv0dsf7444et2...@4ax.com>
> jjla...@highSNIPlandTHIStechPLEASEnology.com "John Larkin" writes:
>
>> 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.
>
>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).
>
>> It would only be art if the programs were beautiful, but they're
>> usually ugly.
>
>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.
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 ;-)
news.ip-plus.ch
news:3fca5e69....@News.CIS.DFN.DE...
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
Ken Lee
wrote:
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.
>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
Greg Kemnitz
> Greg Kemnitz wrote:>
>[deleted]
> >
> > 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.)
>
> 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.
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
fooba...@yahoo.com
Paul E. Bennett
fooba...@yahoo.com "Greg Kemnitz" writes:
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.