Motivation of software professionals
in [Dot Net]
|
From: Lew on 11 Feb 2010 11:17 Michael Foukarakis wrote: > How can anybody ignore this? Do more people have to die for us to > start educating software engineers about responsibility, liability, > consequences? Right now, CS students learn that an error in their > program is easily solved by adding carefully placed printf()'s or > running inside a debugger, and that the worst consequence if the TA > discovers a bug in their project solution is maybe 1/10 lesson > credits. You say that like the developers were at fault. I cannot tell you how many times I've seen management overrule developers who wanted to make things right. It's been the overwhelming majority, though. I recall a manager in 1982 refusing to let a team fix the Y2K bug in the project. Many good developers have grown resigned to the policies and have given up pushing for quality. Many more use stealth quality - they simply don't tell management they're doing things in an unauthorized way that's better than the official process. Only rarely in the last thirty years have I encountered management alignment with known best practices. Nearly all projects I've worked on involved many programmers, dozens even. Parts are written independently of each other, often over a period of years. Often each part test perfectly in isolation and only reveal bugs emergently under production conditions. Many of those projects had large test teams. Products have passed all the tests, yet still failed to meet spec in production. Sometimes the provided test environment differed significantly from the production environment. Before you make the developer liable, you'd better darn well be certain the developer is actually the one at fault. -- Lew
From: Andy Champ on 11 Feb 2010 14:46 Lew wrote: <snip> > You say that like the developers were at fault. I cannot tell you how > many times I've seen management overrule developers who wanted to make > things right. It's been the overwhelming majority, though. I recall a > manager in 1982 refusing to let a team fix the Y2K bug in the project. > Many good developers have grown resigned to the policies and have given > up pushing for quality. Many more use stealth quality - they simply > don't tell management they're doing things in an unauthorized way that's > better than the official process. Only rarely in the last thirty years > have I encountered > management alignment with known best practices. </snip> In 1982 the manager may well have been right to stop them wasting their time fixing a problem that wasn't going to be a problem for another 18 years or so. The software was probably out of use long before that. Right isn't necessarily perfect, or bug free. It's kind of important to be able to sell the thing and get the income for the next release. The trade off of course being (1) if you do it right you won't have to do it again and (2) if you do it really badly there will be no further sales anyway. We offer no warranty on my current project. We also know that if we screw up badly enough we'll be job hunting in six months - the trade will go elsewhere. Andy
From: Ivan Marsh on 11 Feb 2010 15:03 Stefan Kiryazov wrote: > Hi all, > > I am doing a research about motivation in software development, the > most efficient practices to motivate software engineers, their > popularity, etc. > > As a part of the research, I am doing an online survey for software > engineers and managers in software development. It takes just several > minutes and filling it is a good opportunity to share your opinion > about the motivation practices being used in the software industry > today: > http://ask.wizefish.com/en/MotivationSurvey.aspx > > Anyone who does the survey and leaves any contacts will be sent the > results. > > Also, if someone is running a web site or blog dedicated to any aspect > of software development we can do some link exchange. > > Regards, > Stefan Kiryazov ....I'm not feeling very motivated at all today. -- "All right, all right, if it will make you happy, I will overthrow society." - Philip J. Fry
From: Lew on 11 Feb 2010 15:22 Lew wrote: >> You say that like the developers were at fault. I cannot tell you how >> many times I've seen management overrule developers who wanted to make >> things right. It's been the overwhelming majority, though. I recall >> a manager in 1982 refusing to let a team fix the Y2K bug in the >> project. Many good developers have grown resigned to the policies and >> have given up pushing for quality. Many more use stealth quality - >> they simply don't tell management they're doing things in an >> unauthorized way that's better than the official process. Only rarely >> in the last thirty years have I encountered >> management alignment with known best practices. > </snip> Andy Champ wrote: > In 1982 the manager may well have been right to stop them wasting their > time fixing a problem that wasn't going to be a problem for another 18 > years or so. The software was probably out of use long before that. Sure, that's why so many programs had to be re-written in 1999. Where do you get your conclusions? -- Lew
From: James Kanze on 11 Feb 2010 15:25
On Feb 11, 10:05 am, Phil Carmody <thefatphil_demun...(a)yahoo.co.uk> wrote: > James Kanze <james.ka...(a)gmail.com> writes: [...] > >> 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. > > They are. That's why independent contractors have liability > > insurance. > In that case they're *not* liable for their unreliable code. It depends. For large projects, it's unlikely that the contractor did the work alone, and it's the prime contractor, who gave him the job, who's liable. But I've also worked on smaller projects, where I was responsible, and liable, for all of the software in the project. -- James Kanze |