As a former .net and database developer turned project manager I have been on both sides of the coin when it comes to frustrating development tasks that can slow down a project. While some might argue that it’s a result of poor estimations I would argue that missed estimations are to be expected and planned for, but the real deadline killer is in a missed opportunity for team collaboration. I like to refer to the first indication that something is wrong as a “speed bump”. This is the critical moment where you have an opportunity to stay on track or miss the opportunity and continue down the wrong path or “dead-end”. There are many terms that if I hear my team utter will make me get out of my chair:
- This doesn’t make sense. (Yes it does, you just don’t understand it)
- It’s random (Not unless that is how you programed it)
- It’s not my code; it’s XXXX’s code (You better have proof that it’s the other code base before you go this rout…)
- You don’t get it (Unless you are working with people that you feel are mentally inadequate to yourself you should be able to explain it to them with a little effort. Maybe you don’t get it…)
These key phrases are often sung after a developer has already hit a “speed bump” and missed the golden opportunity for collaboration, so if you hear these phrases and do nothing you are also at fault. Development teams need to keep an eye out for these indicators and act. Often this is a pattern of someone who is reluctant to ask for help, but needs it. Do yourself and your fellow developers a favor and save them from ending up in a “dead-end”.
As a developer what I like to do is set a threshold for how wrong I can be to prevent anything from getting out of control. Similar to a day trader who limits his losses to 5% on a single trade to prevent unrecoverable losses a developer needs to set a limit where they admit to being wrong and seek collaboration. In most cases either you or one of your colleagues will quickly identify the problem, after walking through it, and you can get back to work. If the scope indeed changed this is the time to regroup with the project manager and ensure the new time is included in the project plan. There is no shame in a missed estimation, but there is no excuse for allowing your pride to jeopardize your project and your team.


Feb 17, 2012
@ 7:54 am
More frequent app deployments and Continuous deployment need a line to a new concept named App designed for hot/quick deploys. Applications can be designed in a way to allow for minimal/no down-time (eg. reference data with start/end times, property file listeners to automatically reload configuration changes, redundancy to allow for live deployments).