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: MarkusSchaber on 11 Feb 2010 02:45 Hi, On 10 Feb., 22:53, Andy Champ <no....(a)nospam.invalid> wrote: > 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. Maybe not the locksmith itself, but there are insurance companies which calculate how high the risk is, and they take that liability. For locks, cars, even airplanes, insurance companies do that all the time. But there are only a few cases where this is done for software.
From: Arved Sandstrom on 11 Feb 2010 03:56 Seebs wrote: > On 2010-02-10, Arved Sandstrom <dcest61(a)hotmail.com> wrote: >> Seebs wrote: >>> 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. > >> Well, yeah, it does. Unless you believe that most software developers >> and their employers are going to spend the extra time and money to do >> all these things out of the goodness of their hearts. We already know >> that the market will not force software quality to improve - it hasn't >> happened yet. > > Not in general, but: > 1. Some people will do these things because they believe it is important > to do their work to the best of their ability. > 2. Some people with contracts and such in place will still produce shoddy > code. > > In short, while there's certainly a correlation, liability and certification > are neither necessary nor sufficient to produce reliable software. Insisting > on them strikes me as missing the point; they're a proxy value at best for > the actual goal. > > -s I agree with your specific statements. It's impossible not to - I see evidence often enough of software developers who have no relevant formal education, have no certifications, and have only OJT, who nonetheless have applied themselves in their own time to study their field. These are the people who read the formal language and API specifications, own copies of books on concurrency and software testing and software design, regularly read the better programming website articles, and subscribe to good articles. In fact, in some cases people who follow programming NGs on Usenet. :-) Generally speaking the majority of programmers who do these things do have some relevant formal education, and often certifications, but since currently a CS degree rarely prepares a person to be a good software developer it's not an important factor: what counts is the other stuff I mentioned. For sake of argument the fraction of such software developers may be 1 in 10. I doubt it's more, because in my 25 years or so in the field, spread out over nearly 35 years, I've encountered hundreds of developers in many different employment settings as co-workers and colleagues, and I've seen no evidence that it's higher than that. Here's the thing: the main reason for having the codes of conduct, required education and certifications, professional associations, regulated professional development, legal guarantees and so forth, is to prove to the consumer (employer of software developers, purchaser of computer software etc) with a reasonable degree of assurance that they are getting a known, reliable quantity, whether that be an employee or a product. All that stuff is there is to help regulate the market in software professionals and software itself, so that the consumer is not flying in the dark when it comes to choosing services and products. It's not a be-all and end-all by any means. It simply raises the bar, just as it does in existing professions. It's defining the minimums, and currently we truly have none. Such a system also protects the true software development professionals. As it is employers have a tough time selecting good people, and consumers have very little idea of what they are getting. Shoddy programmers can last a long time (and God knows they do), and while they're at it they damage or destroy the credibility of people who are really trying to do a proper job. Employers become accustomed to having mediocre employees, and customers get used to shabby software. When an employer gets an employee who really knows what they are doing they are lauded as superstars - well, they're not, they're just doing their job. And when customers get a reliable piece of software it gets 5 stars just for being good software, which is also pretty sad. The system should not be so hit and miss. And it does not have to be. You're quite right in a narrow sense. If you are talking about the 10% of developers who try, and the 10% of software shops that get it, and the 10% of software that is truly quality stuff, they don't need the extra push or the regulations. But the other 90% do. AHS
From: Arved Sandstrom on 11 Feb 2010 04:07 Brian wrote: > On Feb 10, 4:18 pm, James Kanze <james.ka...(a)gmail.com> wrote: >> 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). > > > Software from Ebenezer Enterprises is free. I think only > an idiot would attempt to sue us for a problem they find > in the software. I think the same things goes for Boost. > I don't think they've ever been sued for defects. > > > Brian Wood > http://webEbenezer.net > (651) 251-9384 Free (as in beer) software brings up an interesting set of arguments. If I understand your point as being, if a product is free how can one possibly sue the maker of it for flaws in the product? Correct me if I'm wrong. I have my own thoughts on this topic but I simply want to make sure what we're discussing. AHS
From: Dancing Fingers on 11 Feb 2010 04:21 For me, a non-pro, it's like solving a crossword puzzle. You're trying but can't quite figure it out. But when you finally do it's a huge rush and you can't wait for more. OMG I'm addicted to programming -- my wife was right. Chrizs
From: Nick Keighley on 11 Feb 2010 04:30
On 10 Feb, 10:42, 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. sometimes it is. Sometimes quality is seen as being too expensive. The cost of a pissed off customer isn't always factored in. > If adequate procedures were > available that could ensure bug-free software, at reasonable cost and > time, they they would have been adopted. they are available, they do have reasonable cost (in many fields) and they have been adopted. Telecommunication systems mostly invisibly work. There's a good reason for this. > Except in a few areas > customers would soon shy away from 'no warrantry including the implied > warrantry of suitability for any particular purpose' products. we've pretty well brain washed the consumer to accept this as reasonable. > 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. talk to the telcommunications people, talk to the military, talk to avionics and space, talk to automotive (ok, bad example!). |