Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
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
From: Brian on 11 Feb 2010 15:33 On Feb 11, 3:07 am, Arved Sandstrom <dces...(a)hotmail.com> wrote: > > 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. > Imagine driving by a house and seeing a car in front with this sign -- "Free car." It is your responsibility to check out the car. If I were interested in that car, I'd talk to the giver of the car, check out the car for myself (is it stolen?) and then either drive it carefully to a mechanic or have a mechanic come to the car. After that I'd be the only one that rides in the car for a month or two to be more certain that it is in fact a safe car. As long as the giver reveals any known problems about the car to me, I don't think there's any basis for suing him if the car is later found to have a serious problem. Brian Wood http://webEbenezer.net (651) 251-9384
From: Andy Champ on 11 Feb 2010 16:33
Lew wrote: > > 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? > Pretty well everything I saw back in 1982 was out of use by 1999. How much software do you know that made the transition? Let's see.. Operating systems. The PC world was... umm.. CP/M 80? Maybe MS-Dos 1.0? And by 1999 I was working on drivers for Windows 2000. That's at least two, maybe three depending how you count it, ground-up re-writes of the OS. With that almost all the PC apps had gone from 8 bit versions in 64kb of RAM to 16-bit DOS to Windows 3.1 16-bit with non-preemptive multitasking and finally to a 32-bit app with multi-threading and pre-emptive multitasking running in hundreds of megs. OK, so how about embedded stuff? That dot-matrix printer became a laserjet. The terminal concentrator lost its RS232 ports, gained a proprietary LAN, then lost that and got ethernet. And finally evaporated in a cloud of client-server computing smoke. I'm not so up on the mainframe world - but I'll be surprised if the change from dumb terminals to PC clients didn't have a pretty major effect on the software down the back. Where do you get your conclusions that there was much software out there that was worth re-writing eighteen years ahead of time? Remember to allow for compound interest on the money invested on that development... Andy. |