It was interesting listening to David Laribee, Jeremy D. Miller, and Chad Myers on the recent podcast on Continuous Improvement and as a Development Manager I thought I'd respond to a comment about the Management Crisis.
Not sure which of the panel used this expression but they were referring to their perception that a lot of managers are not interested in maintainability or quality and are prepared to have to re-write software every three years if required. My gut feeling to this comment was,
The crisis is not with management but with those trying to convince them there is a better way
Now before you get the flame-throwers out let me explain.
Both Managers and ALT.NET'ers share a common goal (surprise!)- to (continually) improve the way we deliver software. That's right! The problem is that each has their own ideas about what constitutes good delivery.
|Manager Thinks ||Developer Thinks |
|The quicker I can get this software to the client the better ||I'm prepared to invest effort now to save time in the long run through good testing and design practices |
|If it works and the client is happy the project is a success ||The solution needs to be extensible and designed to easily respond to change |
|Coding is easy - if Developer X gets run over then I'll slot Developer Y in and there will be no impact. ||A solution that is poorly designed with no consistency between components/projects will be a nightmare to maintain. New developers will take a lot longer to get up to speed. |
|I expect the system to be rebuilt in a few years anyway - why invest in a killer solution when the technology and best practices of today will be irrelevant tomorrow. Anyway, we'll end up getting more work when we redesign anyway. ||A good solution should be designed so that it can evolve to include new and improved features. We want to design for change and don't want to start from scratch each time. |
You can see the trend, Managers are motivated by the here and now while a great deal of the practices and patterns of the ALT.NET movement are designed, in part, for the future - build it well now and you'll have a more maintainable, supportable product going forward.
And that is the fundamental challenge to convincing your managers that there may be a better way.
You can measure the cost of writing additional code (unit tests, mocking objects, layers of abstraction...) but you can not easily measure the predicted benefits (improved maintainability, consistency, supportability, robustness...)
And that's why managers will say "no".
So what do you do? I think the secret is to use stealth!
Most managers (but not me!) have no idea what goes in to creating software and the complexities and challenges you face day to day. It's all a black box to them - and what's more they think it's all pretty easy. There's a reason people call us code monkeys. Further, if you ask most managers - "can I spend extra time writing and maintaining a suite of unit tests because in the long run it will save us time..." - they will say no. There is a deadline looming and you don't have any extra time buddy. So my advice (and don't tell my boss) - don't tell your manager or project manager. Just do it. If you're so convinced it is going to make things better - and by better I mean, you'll still make your deadlines but you'll have a better solution at the end of it - then go for it. After a few months of gradually introducing better development practices into the team there should be some tangible improvements in the project successes. If not, then you need to revisit whether the practices you are employing are really making a difference.
So that's my advice - don't make a song and dance about changing the way we write software. Managers didn't know how you were writing software before and they're not going to know if you do it differently now. What's important is that you, your manager and the client are all happy with the results.