Motivation of software professionals
in [Java Programming]
|
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!
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) |