Lessons Learned
Category rants
Most of us have been on at least one project large enough (or disastrous enough) to include a "lessons learned" phase: the moment where we look back and analyze what went right and wrong... and, ideally, why. Once upon a time I was on a project that should have included this phase but, at the time of my departure, was still hanging on for dear life. Prior to my departure, and primarily for therapeutic purposes, I wrote a tongue-in-cheek lessons learned document detailing just a few of my observations ranging from the purely pragmatic to the bitterly sardonic. Having since received quite a few requests to publish that document, here it is:
Skipping phases of the project life-cycle doesn't make the project cheaper. It makes it really expensive.
Working longer hours doesn't necessarily mean more work gets done.
Eating a banana can often avert an imminent migraine.
When somebody asks you for something, deciding what they actually need is something else entirely - and then forcing it upon them - is a foolproof way to piss them off.
If you ask a developer how long something will take prior to increasing the project scope, keeping the original estimate guarantees you'll go over budget. Yes, every time. No, there's no way to avoid this.
A complex URL structure doesn't reduce the likelihood of broken links, it increases it.
If you want something done right, don't do it yourself. You can't: you don't have sufficient access in that environment. Just make sure your instructions are ridiculously detailed... to the point of being insulting.
It's apparently okay for software to be fragile as long as the release date doesn't get delayed.
Spending three days automating something that only has to be done once and takes two hours to do manually is a good thing... 'cause then it's "streamlined".
Test environments shouldn't match production, because duplication of data is bad. Uncertainty about the end result keeps us sharp, on our toes. Knowing without a doubt that all the bases are covered breeds complacency. And the moment we get complacent, somebody dies.
Okay, maybe that last one was a bit melodramatic.
Most of us have been on at least one project large enough (or disastrous enough) to include a "lessons learned" phase: the moment where we look back and analyze what went right and wrong... and, ideally, why. Once upon a time I was on a project that should have included this phase but, at the time of my departure, was still hanging on for dear life. Prior to my departure, and primarily for therapeutic purposes, I wrote a tongue-in-cheek lessons learned document detailing just a few of my observations ranging from the purely pragmatic to the bitterly sardonic. Having since received quite a few requests to publish that document, here it is:
Everything I Really Need to Know in Life I Learned in project code redacted for public consumption
Skipping phases of the project life-cycle doesn't make the project cheaper. It makes it really expensive.
Working longer hours doesn't necessarily mean more work gets done.
Eating a banana can often avert an imminent migraine.
When somebody asks you for something, deciding what they actually need is something else entirely - and then forcing it upon them - is a foolproof way to piss them off.
If you ask a developer how long something will take prior to increasing the project scope, keeping the original estimate guarantees you'll go over budget. Yes, every time. No, there's no way to avoid this.
A complex URL structure doesn't reduce the likelihood of broken links, it increases it.
If you want something done right, don't do it yourself. You can't: you don't have sufficient access in that environment. Just make sure your instructions are ridiculously detailed... to the point of being insulting.
It's apparently okay for software to be fragile as long as the release date doesn't get delayed.
Spending three days automating something that only has to be done once and takes two hours to do manually is a good thing... 'cause then it's "streamlined".
Test environments shouldn't match production, because duplication of data is bad. Uncertainty about the end result keeps us sharp, on our toes. Knowing without a doubt that all the bases are covered breeds complacency. And the moment we get complacent, somebody dies.
Okay, maybe that last one was a bit melodramatic.
Comments
Posted by Dan At 09:56:19 On 06/11/2007 | - Website - |
Posted by Adam At 09:59:48 On 06/11/2007 | - Website - |