Sometimes it can be hard to get your employers to move forwards on a good idea. They may agree in principle that unit testing and dependency injection are good things, or that development effort would be reduced with a good ORM solution, but it just doesn’t fit in the project plan yet. Soon, we’ll do that “soon…”
My current employers are interested in moving into a more agile process, but the combination of deadlines sprinkled with a little fear of change can slow these things down. A good remedy to this can be to sneak a few things in without going after permission from the start and that can easily be seen to have a benefit without too much investment upfront. The best choices for this are going to be things that aren’t likely to cause sticking points for other devs.
Wapping StructureMap or NHibernate into the middle of a codebase is going to be a problem when another dev touches your code. Simply compiling it will fail without getting the libraries onto their machines, and even then the instant that someone else needs to change something there are going to be problems when no-one else understands the APIs, or even the concepts behind them.
Unit tests are great, but building up a decent test suite when one doesn’t exist is not a quick task. It may be hard to get the all clear for taking TDD approaches everywhere, and the short term performance drop of writing all your tests could make you look bad if management hasn’t bought into the idea and you just forge ahead alone.
The easy starting point that I found was Continuous Integration. It isn’t going to suddenly bite other developers when they stumble across it, and other than taking a few hours to set up initially it won’t have a big impact on your visible productivity. Of course, without a decent test suite to run you’re not going to feel the full benefits, but if you are part of a team and find that getting latest out of source control results in a broken build more often than you’d like (a couple of times a week for me) it is a good place to start, and has plenty of scope for enhancement with tests, coverage, static analysis etc later on.
We currently have 3 important systems under development with a certain amount of code shared between all 3, and a couple of tasks about to start to merge some of the code changes that have happened in one back into the others that I am involved in. This is an area ripe for causing build problems. A simple change in one project that isn’t accommodated in the others could easily break a system that you don’t even know you’re modifying. With this in mind I set up CruiseControl.net to build these 3 projects on my own machine. With this well underway, I mentioned it to my team leader, extolling the virtues of quickly locating breaking changes and he liked the idea so I was able to spread an email around all the devs introducing it, linking to CCTray and giving instructions on configuring it so everyone could see the build status. Had I been less confident about the sort of response that I would get to the suggestion once everything was in place, I might have been more likely to keep quiet about it and just know that I had a safety net to catch me and my fellow open-minded devs that I wanted to let in on the secret. As there are already plans for us to have continuous integration at some point in the future it seemed like a positive thing to get out there once I had moved it into at least a decent proof of concept stage.
This is now running with at least some if not all of the devs watching it and has already caught a few broken build states quickly and easily. Following this, my team leader asked me to do a presentation at an upcoming team meeting to talk a little about what this gives us, so I hope to use this to get across the reasons for wanting to run CI, the benefits that it gives us currently, and how much more it could provide when mixed with a full test suite etc. With a bit of luck, this will help to ensure that everyone is on board with the process and make it a success.
No comments:
Post a Comment