Motivation of software professionals
in [JavaScript]
|
Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
From: James Kanze on 10 Feb 2010 17:35 On Feb 10, 11:32 am, John Koy <John....(a)example.com> 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? A contractual indemnity for each second of downtime? (Most of the projects I've worked on have had such clauses in their contracts.) > 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" ? Most of the projects I've worked on have had clauses to the effect that "we will pay you x Euros per minute downtime". It seems to be a more or less standard clause. > 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. True, the underlying platform is always a risk. But then, you don't have to push it, and you're normally not the first user of it, and you've validated it, so you have some confidence that it won't crash for what you're using it for. -- James Kanze
From: James Kanze on 10 Feb 2010 17:38 On Feb 10, 7:13 pm, Pete Becker <p...(a)versatilecoding.com> wrote: > Seebs wrote: > > The job of the engineer is to know enough to build something as reliably > > as possible with the available tools, > And within the available budget. > and tell you how reliable that is. > Anyone can build a bridge that stands up. It takes an engineer > to build on that barely stands up. Or to tell you exactly what it will stand up to, or how much it will cost before you start building it. And of course, that's exactly what we do every day when we develop software. Customers won't give us the contract unless we can provide concrete guarantees with regards to downtime, etc., and unless we can specify a guaranteed fixed cost in advance. -- James Kanze
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 |