Motivation of software professionals
in [Dot Net]
|
From: Seebs on 10 Feb 2010 11:53 On 2010-02-10, MarkusSchaber <msr(a)soloplan.de> wrote: > 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. Yeah, and if all you have is improvised materials, you can't be sure the things you build will work. That doesn't mean you're not an engineer. The sign of being not-an-engineer would be promising that they'll work anyway. The job of the engineer is to know enough to build something as reliably as possible with the available tools, and tell you how reliable that is. Usually, with software, the answer is "not all that reliable". But since software engineers know that, and tell people that, and give clear evidence that they've carefully analyzed the components to be able to tell you that, it sounds to me like they're doing exactly what engineers ought to do. I think the obsession with whether or not there is liability misses the point; that's a social convention adopted for fields where the tools are much simpler, it's nothing to do with the substance of what engineers are doing. -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!
From: Lew on 10 Feb 2010 12:43 Arved Sandstrom 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. Malcolm McLean wrote: > 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 Bullshit. Management doesn't adopt effective practices for a variety of reasons, but the fact is that far too many projects are managed in fashions contrary to best practices. It's a combination of application of an inappropriate management paradigm (factory work vs. talent work), ignorance or disbelief of the fundamentals, mistrust of the commitment and understanding of the developers, and a desire to keep the process inefficient in order to collect more money. The observable fact is that software projects are managed as though management were stupid. That's why half to two-thirds (depending on whose figures you go by) of all major software projects never go into production, and so many that do have major, preventable bugs. > customers would soon shy away from 'no warrantry including the implied > warrantry of suitability for any particular purpose' products. Adequate procedures are available, or haven't you been studying the subject? > 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. Again, not true. Iterative development alone greatly increases productivity and quality. Add in other elements of agile programming, or whatever the rubric is for effective practices these days, and you asymptotically approach perfection. The field of software project management is well studied and well documented. Effective techniques are known and published. And have been for decades. They simply are not followed. -- Lew
From: Pete Becker on 10 Feb 2010 14:13 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. -- Pete Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The Standard C++ Library Extensions: a Tutorial and Reference" (www.petebecker.com/tr1book)
From: Andy Champ on 10 Feb 2010 16:53 John Koy wrote: <snip> > 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" ? </snip> To some extent that's an unfair comparison. Can any locksmith or burglar alarm maker guarantee that a building will withstand all attacks for 12 months? _That_ is the equivalent of withstanding all virus attacks for 12 months - and it's on a far simpler system. And "your loss won't exceed 20% of all digital assets"? That's a very soft target. I have put together systems designed to safeguard data, and have lost no data, and would not expect to lose data. It's called redundancy. Software failures really do not wipe a fifth of the stored data - we're _much_ better than that. The residents of Haiti might have a few words about buildings designed to withstand 7.5 magnitude earthquakes. And after all, it was due: http://www.sciencedaily.com/releases/2005/02/050205102502.htm Andy
From: Volker Borchert on 10 Feb 2010 16:23
Pete Becker 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. What about Galloping Gertie? -- "I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy(a)ncc1701.starfleet.fed> "I'm a mechanic, not a doctor." Volker Borchert <v_borchert(a)despammed.com> |