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
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.
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:
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"!!
I agree with all your points except this one:
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 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
The PBS series Nova has a show about the building of a new-design suspension bridge across the Mississippi near Alton, Illinois.
It makes bridge building look a lot like software.
Regards. Mel.
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.
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.
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.
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 .................... Forth based HIDECS Consultancy ..... 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.. ********************************************************************
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
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
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
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.
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
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:
Sandeep
--
Engineering is the art of applying the appropriate science to the problem at hand.
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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
Hi Rick,
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 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".
True.
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?
Mark Borgerson
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.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... 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.. ********************************************************************
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
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
software.
Probably very few.. but then Windoze XP is not DOS either.. in fact what is it ???
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.