Motivation of software professionals
in [Dot Net]
|
From: James Kanze on 10 Feb 2010 17:41 On Feb 10, 3:31 pm, Wojtek <nowh...(a)a.com> wrote: > 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. :-) That's the way things were in software thirty or fourty years ago. But it's true that some people have relabeled the procedure, and are trying to sell it today. (See TDD.) -- James Kanze
From: James Kanze on 10 Feb 2010 17:42 On Feb 10, 10:38 am, Michael Foukarakis <electricde...(a)gmail.com> wrote: > On Feb 10, 12:03 pm, Malcolm McLean <malcolm.mcle...(a)btinternet.com> > 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. > 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. They are. That's why independent contractors have liability insurance. -- James Kanze
From: James Kanze on 10 Feb 2010 17:44 On Feb 10, 4:54 pm, Seebs <usenet-nos...(a)seebs.net> wrote: > On 2010-02-10, Michael Foukarakis <electricde...(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? Reasonable, justified or necessary, I don't know. But it's a fact of life. If you deliver software, and it fails, you're liable for it. Most of the time, the liability is spelled out in the contract, but that still doesn't exclude any legal guarantees the buyer may have. -- James Kanze
From: Arved Sandstrom on 10 Feb 2010 17:59 John Koy wrote: > 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. [ SNIP ] Car and computer and TV manufacturers don't guarantee that their products are 100% absolutely going to work either - why should we have to? The point being that with existing and understood software development methodologies, if those are assiduously applied then we can safely state that for a given population of application deployments that such and such a percentage of them will fail badly, another fraction will encounter serious problems that require dedicated support under warranty, another fraction will encounter minor problems, and so forth. It's precisely this kind of statistical knowledge that lets you provide consumers with certain protections - warranties, support offers, and so forth. We're already doing it with major applications - we could do this with the majority if we just bothered to write quality software in the first place. Seriously, though, why the insistence on perfection? We don't get perfection from engineers (or other professionals) either, nor from manufacturers of tangible goods and structures. Transportation infrastructure crumbles before its time. We are resigned to consumer goods that must be regarded as disposable (and not all are _designed_ to be disposable). We accept that not so long after buying a new car that we will be regularly repairing it. Sick buildings are common. Tens of thousands of surgical mistakes are made every year just in North America. Manufacturers of electronics and electrical equipment make a mint off people who can't be bothered to return broken stuff, and buy new replacements instead. A software engineering profession would not require perfect software any more than traditional engineers are expected to design perfect equipment or machinery or structures. All I'm saying is that we can do considerably better, and we can do that to the extent that we can provide the same protection to consumers for software as we already for cars or vacuum cleaners. AHS
From: Arved Sandstrom on 10 Feb 2010 18:03
Seebs wrote: > 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. Well, yeah, it does. Unless you believe that most software developers and their employers are going to spend the extra time and money to do all these things out of the goodness of their hearts. We already know that the market will not force software quality to improve - it hasn't happened yet. AHS |