Motivation of software professionals
in [Dot Net]
|
From: James Kanze on 13 Feb 2010 07:07 On 12 Feb, 22:21, Brian <c...(a)mailvault.com> wrote: > On Feb 12, 3:36 pm, James Kanze <james.ka...(a)gmail.com> wrote: > > On Feb 12, 11:42 am, Leif Roar Moldskred > > <le...(a)huldreheim.homelinux.org> wrote: > > > In comp.lang.java.programmer Arved Sandstrom <dces...(a)hotmail.com> wrote: > > > > This is what I am getting at, although we need to have > > > > Brian's example as a baseline. In this day and age, > > > > however, I'm not convinced that a person could even give > > > > away a free car (it wouldn't be free in any case, it > > > > would still get taxed, and you'd have to transfer title) > > > > and be completely off the hook, although 99 times out of > > > > 100 I'd agree with Brian that it's not a likely scenario > > > > for lawsuits. > > > Where Brian's example falls down is that the previous > > > owner of the car is, in effect, just a reseller: he isn't > > > likely to have manufactured the car or modified it to any > > > degree. However, let us assume that he _has_ done > > > modifications to the car such as, say, replacing the fuel > > > tank. If he messed up the repair and, without realising > > > it, turned the fuel car into a potential firebomb, he > > > would be liable for this defect even if he gave the car > > > away free of charge. > > He doesn't even have to have done that much. If he knows > > that the brakes doen't work, and he lets you drive it, he's > > legally responsible. > I have no problem with that. Some though believe that if you > give away a car and aren't aware of a problem with the car, > that you are still liable. I don't think I'm obligated to > have a car looked at by a mechanic before giving it away. If > it is safe to the best of my knowledge, then I should just > tell whoever wants the car about it's history and encourage > them to have the car checked out. Yes. There are two things that could make you liable: deceit or negligence. If you make claims you know aren't true, it's deceit. As a private individual giving something away, negligence (to the point of making you liable) is practically impossible. As Jerry pointed out, even in the case of a large company, with expertise in the field, it's very, very difficult. IMHO, if you don't take well known and provenly effective preventive measures, you're negligent. But Jerry is a lot better versed in the legal issues than I am, so I'll take his word for it that if everyone's doing it, you're off the hook. And there are certainly enough software firms delivering junk to count as almost everyone. (Although it probably depends on the domain. Almost every firm delivering software to NASA is taking adequate steps; for that matter, most of the telecoms software I've seen was "correctly" developed as well.) -- James Kanze
From: Arved Sandstrom on 13 Feb 2010 09:24 Jerry Coffin wrote: > In article <eab51075-377a-4714-ab9d-853df4fcae95 > @b2g2000yqi.googlegroups.com>, electricdelta(a)gmail.com says... > > [ ... ] > >> 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. > > Unfortunately, I'm afraid you're mostly wrong. If a building falls > down, grounds for a lawsuit would be that the engineer(s) involved in > the design were "negligent". In this case, "negligent" is generally > defined to mean that the care with which they did this particular job > was substantially less than would be expected of most others in the > same profession. > > To put it somewhat differently, to win such a case, you need to show > that (in essence) if virtually and of their direct competitors had > done the job instead, you'd have a reasonable assurance that you > would have received a result of substantially better quality. > > In the case of software, showing such a thing would be next to > impossible. Software disasters of truly epic proportions are > commonplace, well known and easy to cite. Offhand, I'd be hard put to > think of even one "good practice" that's sufficiently widespread that > I could testify that it was at all surprising when it wasn't > followed! All of which is true, and all of which defines the problem. Acquisition of quality software is hit and miss, and employment or contracting of quality software developers is hit and miss. Mostly miss in both cases. Peter Seebach has made a point that why worry about certifications and warranties and so forth. He states that there exist individuals who follow best practices - which is true - and that they don't need a label. Furthermore, he's made a related statement that the widespread availability of free software is very beneficial (it may or may not be, IMHO), and that warranties and liability would be detrimental to this process. My take on it is, and I've said it before, certifications and warranties and so forth are about lifting the bar. Without them purchasers and employers need to spend a great deal more time and money to establish what and who is quality, and what and who is not (because most of the products and prospective employees are _not_ quality). Having certifications/education/professional development/discipline etc which are associated with a true profession helps provide an assurance that *any* certified software developer you intend to hire is going to be somewhat competent. And having guarantees on a program helps provide an assurance that the program is suitable for a stated purpose. The issue is that we are all craftsmen, and our "profession" is in a pre-Industrial Era stage of craftsmanship. Except that we're missing even a formal classification of craftsmen (apprentices, journeymen, masters), so employers have to sort through the inflated self-labelling so common in our field. Arguments are constantly made that software development is somehow not amenable to being qualified and quantified, that it's an art (and a craft), that it's impossible to create reliable software, and so forth. These are precisely the kinds of arguments that craftsmen made back in the day, and they don't hold any water. We will eventually lift ourselves, or be lifted, into the status of a profession. I'd rather do the lifting than be lifted. AHS
From: Arved Sandstrom on 13 Feb 2010 09:40 LR wrote: > Arved Sandstrom wrote: > >> To my way of thinking there are some >> implied obligations that come into effect as soon as a software program >> is published, regardless of price. Despite all the "legal" disclaimers >> to the effect that all the risk is assumed by the user of the free >> software, the fact is that the author would not make the program >> available unless he believed that it worked, and unless he believed that >> it would not cause harm. > > Aren't some programs released with known defects? Absolutely. To me if a program comes with a clear list of known defects, with description, that's a sign of maturity. Essentially the set of known defects simply reduces the working functionality of the program - if you can form an educated opinion about what that working functionality is then you're OK to make a decision as to whether or not it's suitable for the desired purpose. >> This is common sense. > > Applied to what is most likely a branch of mathematics or applied to the > law? Applied to the law. Don't get me wrong, I'm not saying the law is like this now. It's not. >> I don't know if there is a legal principle attached to this concept, but >> if not I figure one will get identified. Simply put, the act of >> publishing _is_ a statement of fitness for use by the author, and to >> attach completely contradictory legal disclaimers to the product is >> somewhat absurd. > > I think this may be part of an ongoing controversy. Here's a taste of > what's coming. > http://www.tampaflduilawyer.com/Defenses/DUIBreathTest.aspx (Look for > "Throughout the State of Florida, DUI defense attorneys are demanding > that the State of Florida provide the source code") and there's this: > > "Reasons Why Production of the Source Code is Necessary" > "7. # The extent that known and unknown flaws in the program affect the > accuracy of the test results." > > LR And to my way of thinking, what's wrong with that? Although in this case it seems like the fault, if any, would lie more with the purchaser. Since we currently don't have any widespread mechanisms for certifying and guaranteeing software, it's up to purchasers to exercise due diligence *when they can*. I think it's unreasonable to expect private individuals to be able to test software before purchase, but a government certainly ought to be able to arrange for thorough testing and inspection before they decide to buy an application. AHS
From: Lew on 13 Feb 2010 10:09 James Kanze wrote: > Logically, I think that most of the techniques necessary for > making really high quality software would be difficult to apply > in the context of a free development. And at least up to a Nonsense. Free software has a much higher rate of adoption of best practices for high quality than for-pay software does. You say so, too. It's the "logically" with which I take issue. That free software uses the best techniques and has the highest quality in the marketplace is entirely logical, in addition to being an observed fact. You just have to avoid false assumptions and fallacies in reasoning. > point, they actually reduce the cost of development. So > theoretically, the quality of commercial software should be > considerably higher than that of free software. Practically, > when I actually check things out... g++ is one of the better C++ > compilers available, better than Sun CC or VC++, for example. > Valgrind is at least as good as any of the commercial memory > checkers under Linux. And Subversion is at least as good as any > of the version management tools, excepted ClearCase (and the two > really address different models of development). ClearCase is an unwieldy pig. You hold that up as an example of high quality? Admittedly, it's better than a lot of other version-control products, but not nearly as good as the free ones. > There used to be a lot less free stuff available, and it was > worse. (It doesn't make sense to me, either, but those are the > facts.) No, they're not the facts. Since the beginning of free software, much of it has been very high quality. I doubt very much that the ratios have changed much, or if they have, perhaps you could substantiate your "facts". I don't dispute that there used to be a lot less free software, insofar as there used to be a lot less software of any description. It's your undefined use of "worse" without evidence that I dispute. > I think that part of the problem is that a mistake in a program > will affect every instance of the program. Most recalls for > cars, on the other hand, only affect a small subset of the total > production. A mistake in a car model enough to effect a recall affects every instance of that model. Bugs in software, OTOH, affect only a small subset of the total production of software. You haven't been paying much attention to the news lately, have you? -- Lew
From: Seebs on 13 Feb 2010 11:27
On 2010-02-13, James Kanze <james.kanze(a)gmail.com> wrote: > Logically, I think that most of the techniques necessary for > making really high quality software would be difficult to apply > in the context of a free development. They might be hard to apply, but consider that a great deal of free software is written without idiots saying "you need to get this done sooner so we can book revenue this quarter to please shareholders". It's also often written by particularly good developers, who care about their code. It is also probably an influence that free software writers expect the code itself to get feedback, not just the behavior of the application. I have submitted bug reports about poorly-expressed code, not just about code which didn't work. > And at least up to a > point, they actually reduce the cost of development. So > theoretically, the quality of commercial software should be > considerably higher than that of free software. Again, I don't think there's actually any force driving that. The benefits of well-written software are significant enough that it is likely worth it to some people to improve software they have access to, and if it's worth it to them to do that, it costs them virtually nothing to release the improvements. Free software often ends up with the best efforts of hundreds of skilled programmers, with active filtering in place to keep badly-written code from sneaking in. > And Subversion is at least as good as any > of the version management tools, excepted ClearCase (and the two > really address different models of development). If you are implying that CC is actually usable to you, that marks a first in my experience. No one else I've known has ever found it preferable to any of the open source tools, of which git is probably currently the most elegant. > I think that part of the problem is that a mistake in a program > will affect every instance of the program. Most recalls for > cars, on the other hand, only affect a small subset of the total > production. Another issue is that, if you give away open source software, people can modify it. If you modify my code, and your modification is not itself buggy, and my code is not itself buggy, but your modification causes some part of my code not to work as expected, whose fault is that? This kind of thing is a lot more complicated with code than it is with physical objects. You don't have a million people using a bridge, and a couple hundred thousand of them are using the bridge recompiled for sports cars, and another couple hundred thousand are running it with a third-party tollbooth extension. -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! |