Years ago, I worked for a company that had a strictly governed bug fixing process. The bugs to be fixed per release were specifically regimented, right down to the amount of hours available to fix each issue. Developers were expected to meet or beat their estimates, and failing to do so meant overtime (since the deadline was immutable). With effectively every working moment spoken for, there was never any free time for innovation, invention or creativity (at least on the schedule). Developers were effectively bug fixing or feature building machines, with no input into the process or product features.
Unfortunately, this seems to be an all too common trend in the development industry. Employers, who love the ability to measure things, disdain the fact that engineering is first and foremost a creative art, that cannot be effectively measured. They attempt to install artificial measures of productivity like tests written, lines of code added, bugs solved, and number of bugs reopened by the quality assurance team. Sadly, these measures all fail to effectively measure the effectiveness of development teams, because the developers themselves see immediately through the schemes, and learn quickly to game the system.
Imagine that you’ve just been offered a brand new job. That’s fantastic! Now, make sure you do the math and find out what it will cost you.
“Cost me?” you ask. Yes. Accepting a new job is exciting and often beneficial, but there are costs associated with it that you must consider before you sign the offer and tell off your present employer. Some of these costs are obvious, but others are less obvious. These costs are rarely fully explored, because we have a tendency to see the grass as greener someplace else, and if the offer we receive is substantially better than our current one, we are more inclined to accept it. But not counting the costs would be a huge mistake.