Ten Tips to Make Sure your Project Fails
Suppose, an organization offers you a large amount of money if you agree on the following arrangement. You’ll apply for a management position offered by a competiting company that is presumably going to develop a new innovative and software-intensive product. And it will be your task to sabotage their project. I know, that you never ever would accept such an unethical offer. Nonetheless, I am asking you for the moment to think of the unlikely case that you would agree. The main question in this context is how can you manage this task successfully. As you might have expected, I got ten recommendations for you …
Excellent advice :-) I’d add one: Make sure your turn-around cycle, i.e. the time from introducing a change by adding or changing a line of code to the time you see its effect in the test environment, is at least 12 hours; more than one day is preferable.
If you don’t know it yet, you might like this related story: http://worsethanfailure.com/Articles/The-Source-Control-Manager.aspx
In many ways those overeager build people are the bureaucrats of software development: Instead of serving the people (developers), they make their lifes harder, to the point that smart people find ways to work around them: by leaving.