Motivation of software professionals
in [Dot Net]
|
From: James Kanze on 10 Feb 2010 17:15 On Feb 9, 11:02 pm, John Koy <John....(a)example.com> wrote: > Arved Sandstrom wrote: > [...] > > Engineering "certification" processes are considerably > > better and more comprehensive than anything that most > > software developers are ever exposed to. Starting with > > education - there's no requirement at all that software > > developers have a relevant degree or associate degree, or > > indeed any real SD training at all. Try that with > > prospective professional engineeers. > > It's not just entry-level certification that software > > developers lack. It's code of conduct, professional > > education, duty to the client, professional discipline and > > so forth. These are all standards. In order for software > > "engineering" to really be engineering it has to adopt > > similar standards. > 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. But that's really only the case for shrink-wrapped software (and presumably, it doesn't exclude your legal guarantees). Most of the projects I've worked on did have guarantees, and contractual penalties for downtime. -- James Kanze
From: James Kanze on 10 Feb 2010 17:18 On Feb 10, 10:03 am, 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. Basically no one knows how to build 100% bug-free anything. Witness Toyota. Globally, in fact, you can probably do better with software than with most other things. And I've never worked on a project where there have been liability exclusions (which probably aren't legal anyway). > 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. Well written software fails a lot less frequently than automobile brakes. -- James Kanze
From: James Kanze on 10 Feb 2010 17:24 On Feb 10, 10:42 am, Malcolm McLean <malcolm.mcle...(a)btinternet.com> wrote: > 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. Guaranteed error-free doesn't exist in any domain. It's not too difficult to achieve error rates of less than one error per 100 KLoc, however, and at least one shop does less than one error per million lines of code. Curiously enough, achieving one error per 100 KLoc typical reduces your development costs. But for whatever reasons, in many companies, this goes unnoticed---in the end, if you're selling shrink wrapped software, development costs are more or less negligible, compared to marketing costs, so it doesn't matter if you spend a bit more. > Except in a few areas customers would soon shy away from 'no > warrantry including the implied warrantry of suitability for > any particular purpose' products. Legally, of course, you have certain rights, regardless of what the "warrenty" says. It's just that as far as I know, no one has attempted to enforce them for software. > 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. Less that one error per million lines of code is achievable. And I've worked on projects where we had less than one error per 100 KLoc (going into integration). -- James Kanze
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 |