I could not agree more - however there would be a lot of out of work PMs if that really happened. A big part of that is the PM has no authority to say no to the board - if the order comes from above to move go-live forward generally the only authority they have is downwards to re-arrange resources to best make it happen. To be honest however I am yet to come across a single larger scale project where no requirements changed as the project progressed (I have never worked on medical / defence / real-time systems which I am *hoping* do not have the same issues!). After all - was that not why as an industry we moved away from the waterfall and towards a spiral / agile / whatever buzzword type methodology? The whole problem with waterfall was that it fell apart if the requirements changed after they had been signed off and these newer methodologies were brought in to deal with those issues. I personally feel waterfall has a lot to offer and as an industry we need to start moving back in that direction if we want to compare ourselves to the true engineering disciplines. How can we possibly consider ourselves professionals when we are willing to change fundamental design decisions only a short time before go-live and consider that a positive (ie. it is supposed to show how flexible we are)?

I don't agree there re the lazy comment. The reason poor coders release insecure code is because they are lazy. For the rest of us, it is generally because we are told we MUST release X features by go-live date. Go-live date will not slip under any circumstances. X features are non-negotiable for go-live date. The project manager (not the development PM, the project owner) has assigned a certain period for testing, however this testing is never SIT or the such, it is usually UAT of a very non-technical nature and the devs time is spent on feedback from UAT. Development itself has virtually no proper regression / SIT / design time factored in. The development team are never asked how long realistically something will take, instead some non-technical person will tell them how long they have and then tells them to figure out how to make it happen. Specs will change continuously throughout the project so a design approach at the beginning will be all but useless at the end after numerous fundamental changes (got this one on a project I'm working on now - had my part finished, fully tested and ready to deploy about 3 months ago, then change after change after change and I'm still doing dev and if I mention that I need time to conduct SIT / regression testing I'm told "but I thought you fully tested it already a few months ago?"). This leads a dev with a fast approaching deadline, who doesn't have the authority to say "no, this won't give us enough time to test properly" and the emphasis on being feature complete rather than a few features down but fully tested and secure.

This of course does not even touch on the subject of what happens if a third party library or other software sourced externally has vulnerabilities. Can you in good faith sign off that you guarantee a piece of software is totally secure without knowing how third party libraries, runtime environments or whatever were developed? This is not just isolated to open source, try holding MS liable for a security vulnerability that was uncovered after you deployed and see how far you get. This then starts taking us out of the realm of absolutes and into the realm of "best practices" etc. So how good is a contract that expects the signatory to follow "best practices" in regards to security. Who determines these best practices? So the contract has two possibilities, it is either too strict to make it practically meaningful (people will still sign if that is the only way to get employment but it will not make the software any more secure) or it is to vague to have any meaning.

The bridge analogy works very well as the work software developers do would be unheard of while building a bridge. Imagine a civil engineer having to sign off on a contract that went something like "We reserve the right to change the completion date, including move it forward, any time we see fit. A panel of marketers will determine how long the bridge will take to complete with no consultation of any technical people, any timeline set is non-negotiable. We can add new features that you are currently not aware of at any stage of the build process, right up to a week before completion date. If we so choose we can tell you mid project to change the bridge from an arch to a suspension bridge and the deadline shall not move. Up until completion date the marketing team will hold internal discussions whether or not the bridge needs to open for ships, if they decide it does then you must ensure that this conforms to marketing requirements without missing go-live. And you need to sign off that you will be personally responsible if there are any structural defects."

Same here, and same with everyone I know. Since when is "barbie" not the Aussie slang for bbq?? On that note - if its not "barbie" then what is it?

On the past few systems I have worked on I have had the "fun" job of adding new features to existing legacy code. Adding features to the existing tightly coupled code was a nightmare, finding what did exactly what took ages, some functionality was partially performed in several different locations - each relying on the previous part - and the slightest spec change would need the whole thing to be re-done yet again. The exact same spec changes (eg a new element in a message) were trivial to do in the applications I had written from scratch as each change only needed to be done in a single location and was easy to test. I may have seen some extreme cases but I have certainly become a "loosely coupled" evangelist since.

Provide a solid spec and I would be happy to do a fixed cost project - however I will hold you to the spec just as much as you will hold me to the cost. Provide me a vague wishlist and I will not do a job for you fixed cost. Keep in mind any fixed cost quote will come with the risk priced in at some point. Some people are unhappy with that, wanting a fixed cost to be based upon best case estimates - I simply won't do business with them. Just because someone contracts does not mean they will do any job under any conditions presented to them.

One of the first things I learnt - always always ALWAYS ask for any stupid request / comment / statement in an email. "We won't hold you to it" rates very highly on the list of things I want in writing before I will commit to something. If they will not provide you with an email saying as much, make sure that you email them (preferably cc'ing someone) confirming their request and any problems you might see in it so they can't plead ignorance at that future date. That way when you do get called into that meeting you have something to back yourself up with. It has saved me on multiple occassions.

Sounds similar to the method I used to use
I would make an estimate, add a 50% buffer and double it and send it to the sales rep
The sales rep came from a technical background so knew how IT projects went, so he would take my estimate, double it and add a buffer to that.
This method actually produced estimates quite close to what turned into reality.

I think the problem with estimates are that:
a) developers are never as fast as they think they are,
b) the customer always has something hidden in there that actually means something far more complex than what it appears,
c) there are always unforseen things that go wrong eg a bug in some framework you use that you have to then spend time hacking around and
d) the human factor - some people leave the project, some people would be more useful to the project if they had nothing to do with it, etc.

The trouble is one of the biggest impact items - ie. the customers or vendors - will almost never be the same project to project. Other peoples experiences may differ but I always find that the people involved usually are the biggest factor determining if a project meets deadlines or not and you have no idea what they will be like until the project begins. Even the same person may perform differently project to project, on the first they may be a dedicated resource, on the next the project is one of a dozen they are working on simultaneously so can only devote a fraction of the time and effort of the original. I have had projects that in reality should have taken a few hours take a couple of weeks while other highly complex projects lasting several months go off without a hitch and come in early, all due to the different people.

No, dropping a promise is not reneging on obligations. Sun promised to work on accessibility, however they were in absolutely no way obliged to work on accessibility. There is a big difference between the two.

After reading TFA, as far as my medically ignorant mind makes out, the study was withdrawn due to ethical issues obtaining the samples for the study, not due to issues with the conclusions drawn. I can see how this would lead Wakefield to be deregistered due to ethical considerations however how does this disprove his conclusions? The logic seems to go "your study shows there may be a link between autism and vaccines, you obtained samples unethically, therefore this proves once and for all and hereby ends the discussion that there is conclusively no link between autism and vaccines". I always pay extra close attention when a scientific discussion starts descending into claims of absolutes, a statement like "the possibility is laughably remote that there is a link between x and y" makes sense, "there is no link between x and y and nobody is to suggest there is" smacks of dark ages medicine rather than science.

I would love someone more medically inclined to provide more background as I sense a lot of info was missing from the story / article.

Just because someone loves working with technology does not mean they are good at it. Just because someone works just to pay their bills (and hopefully a bit extra) doesn't mean they are bad at what they do. This is true in some instances, however I have also come across some people who love technology who I would hate working with and quite a number of others who wouldn't spend any extra time in front of a computer than they had to but who are fantastic at their job.

Sounds like my workplace (also in Australia). Half of them go long distance cycling every weekend and ride to work.

In a previous position I remember going to the USA to head office and the difference between their engineers and ours was amazing. Theirs would code away in a dark room isolated from the world. In our Aus office everyone had to turn up in business atire and were all well socially adjusted. My theory is that in Australia quite often we are predominately satellite sales offices for the vendors from the USA. This means there is a very sales, rather than dev, focus in the office. Us geeks are still good at what we do however we are never isolated from sales / marketing / business which keeps us relatively "normal".

I wouldn't even go that far. In development as an example, the paper on the wall will get you into a junior dev position while without that paper you will have to spend a couple of years doing stuff like support or other such tasks and have to prove that you have some development knowledge. Once in the workforce after 5 years it means virtually nothing. I would choose a good applicant with 5 years experience over a new graduate with a masters any day. Not because there is something wrong with the graduate, it's just that the experienced candidate knows how to deal with customers, competing deadlines, scope creep and how to handle situations where things go balls up at the worst possible time. One of my favourite interview questions is to ask "how would you handle a situation where you are working on 2 projects and an urgent task comes up which will prevent you from completing at least one, if not both, of these tasks by the due time?" The experienced candidates will usually give some derivative of "escalate to manager, contact customers asap to negotiate deadlines" and the such. The new graduates will invariably come back with either "I will work back to make sure I meet all deadlines" or "I manage my time effectively so will never be in this position". They technically know their stuff, possibly on a pure technical scale even better than the experienced candidate, it is just that they don't know how to handle all the things that go on that are not of a technical nature.

Edit: "me" == "men"