Motivation of software professionals
in [Dot Net]
|
From: Malcolm McLean on 10 Feb 2010 05:42 On Feb 10, 12:29 pm, Arved Sandstrom <dces...(a)hotmail.com> wrote: > > In other words, we have adequate processes available but tend not to > adopt them. And _then_ because the products are seriously flawed we > disclaim liability because the products are in poor shape. > > We need to get pushed from the outside, by purchasers of our software. > Unfortunately that hasn't happened. > Software management is not so stupid. If adequate procedures were available that could ensure bug-free software, at reasonable cost and time, they they would have been adopted. Except in a few areas customers would soon shy away from 'no warrantry including the implied warrantry of suitability for any particular purpose' products. The fact is that many many formal methods are in existence. Some of them might work, to some extent, and in some circumstances. But none have really proved themselves when it comes to the acid test of developing real software for non-trivial projects.
From: John Koy on 10 Feb 2010 06:32 Arved Sandstrom wrote: > Malcolm McLean wrote: >> On Feb 10, 1:02 am, John Koy <John....(a)example.com> wrote: >>> Arved Sandstrom wrote: >>> >>> As long as we disclaim all liability and give no warranties for the >>> solutions/products we build, SD cannot be an engineering field and the >>> term "software engineer" remains as an oxymoron. >>> >> Basically no-one knows how to built bug-free software, so the lability >> exclusions are necessary. They would be commercial suicide in any >> other field. That doesn't mean there is no such thing as software >> engineering, only that it is new and undeveloped. Boilers used to >> regularly explode at the beginning of the industrial revolution, now >> such accidents are almost unheard of. > > It's not a question of bug _free_ software. There aren't any other > fields I can think of where it's possible to get away with no liability > simply by claiming that it's impossible to achieve perfection. Exactly. Engineering is about measurable outcomes, quantification. What's the equivalent of "this building can withstand a quake of magnitude 7.5 for 30 seconds" in software? Can any of us state "this software will stand all virus attacks for 12 months" or "this software will not crash for 2 years, and if it does your loss won't exceed 20% of all digital assets managed by it" ? We can't even guarantee that it won't crash tomorrow, why? Well, for me, because the underlying platform (OS/JRE/CLR/VM/etc) does not give me any guarantees. I cannot build any engineering product on top of that, no matter what process I employ. Engineering is not about "during", it's about "after": accountability, liability, warranties, hence insurability. And these shape how the process of "during" must be. Without them, it's just some monkey business, hence SD. > > It's also not entirely an issue of software "engineering" being an > infant field. The fact is that there exist adequate processes that apply > to every stage of the software lifecycle, and most software shops only > pay lip service to some or all of them. Doing proper requirements > analysis is not "undeveloped". Doing proper design is not "undeveloped". > Doing proper implementation in your languages of choice is not > "undeveloped". And doing proper testing and QA/GC is not "undeveloped". > > In other words, we have adequate processes available but tend not to > adopt them. And _then_ because the products are seriously flawed we > disclaim liability because the products are in poor shape. That whole > mindset is not a problem that's going to be fixed by pushing for a > software engineering profession, because the desire for such a > professional status follows from a mindset that already follows the > basic principles in the first place. > > We need to get pushed from the outside, by purchasers of our software. > Unfortunately that hasn't happened. > > AHS
From: Wojtek on 10 Feb 2010 10:31 Arved Sandstrom wrote : > And doing proper testing and QA/GC is not "undeveloped". This is the equivalent of building a bridge, then driving over it. If it does not collapse, then proper engineering was used. If it does collapses, well then we just re-build it and try again. -- Wojtek :-)
From: MarkusSchaber on 10 Feb 2010 11:26 Hi, On 10 Feb., 12:32, John Koy <John....(a)example.com> wrote: > We can't even guarantee that it won't crash tomorrow, why? Well, for me, > because the underlying platform (OS/JRE/CLR/VM/etc) does not give me any > guarantees. I cannot build any engineering product on top of that, no > matter what process I employ. And that is the problem with the abstraction levels I mentioned. Even the OS cannot guarantee anything because our mainstream hardware is extremely underspecified (e. G. try to get any time guarantees for hard disk access) and does not guarantee for anything (see the long errata list of current CPUs, or the statistics about RAM error rates due to cosmic rays.
From: Seebs on 10 Feb 2010 11:54
On 2010-02-10, Michael Foukarakis <electricdelta(a)gmail.com> wrote: > Nobody knows how to build earthquake-immune buildings, yet engineers > give certain guarantees. When those are failed to be met, (s)he is > held liable. Maybe it's about time some "software engineers" were held > liable for their unreliable code in the same way. Why? Do you have any evidence to suggest that this kind of liability is actually reasonable, justified, and/or necessary? > That's absolutely right. But we can't sit and wait for software > development to be refined on its own, we should probably do something > about it. Collectively or whatnot. I agree. I just don't think that rants about liability or certification are going to do anything. Neither of those has a thing to do with learning to write more reliable software. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! |