Ok, I think this question is at the wrong place and I’ll head over to https://softwareengineering.stackexchange.com/ to read/ask about it. Thanks all for your answers up to this point. 🙂
apologies 😉 I’m sorry if this question is a little bit subjective, but I can not come up with a better title. I’ll correct it if you know something better.
In my organization there is a lot of buzz about this whole automated testing and continuous integration thing, but one argument I constantly hear is this:
How should I develop good, clean, easy to maintain code and write unit tests, if the
deadline is already set and it is only half of my estimate?
I’m a developer myself, so I can understand this. But I always try to respond that not only the developers need a paradigm shift, but the management too.
If you are a developer and your estimates are cut half, no matter what you estimate, you are not going anywhere, no matter how complex or trivial your problems are. You need the backup of the management guys, the One Guy who is giving the money.
Conclusion?
Can you give me some help, may it be a good URL to read about this development/management conflict, a book or maybe a personal insight? Did you survive a large process shift like this in a Waterfall company that is now doing Lean development? Or do you know this argument and have a clever answer to it?
And please, help me rename or move this question. 🙂
Update
Thanks for all the answers already! 🙂 I think I have to make clear that my point wasn’t the “do it twice as fast” statement from management. It’s about the negative point of view that comes with this statement from a developer.
Is there anything I can do to help people to understand that this is not the default in software development? That the PM is not actively preventing writing good code and that maybe both sides need a bit more education about the pros/contras of clean code bases, good coverage and lots of automated tests?
One good example is Technical Debt. It’s manager friendly. Imagine your credit card. If you accrue debt for a few weeks that can be helpful. You don’t need to carry around cash for daily purchases and you pay it off at the end of the month.
This is like a crunch before a release. You take on some debt and then pay it back soon. If you keep charging things and never paying off that debt it starts to compound. That new feature you want it more difficult because the foundation you’re building on is unsound. The debt you’ve accumulated is keeping you from acting quickly. If you’re over your limit even typical small purchases won’t go through.
You might also want to take a look at Facts and Fallacies of Software Engineering . It talks about estimates and the troubles they can cause when they’re not reviewed as the project evolves.