DaveDevelopment::Dave Marshall

This series is based on my experiences as a Lead Developer. The first part covered being a mentor, this part is going to focus on the tools and methods I introduced to the team in the last eight months.

Software tools and methods

A previous post on modern tools pretty much sums up the tools I’ve introduced to our team, the ones listed here are the ones that have been successful. To be honest, this sounds like a big list of buzz terms, tools and methods, but I can testify that these methods have helped improve our development environment.

Automated build, configuration and migration

We wanted a way to get the application up and running fairly swiftly in development environments and also a way of deploying code to testing, staging and production environments. I developed phing scripts to retrieve code from the subversion repository, configure it and then create/update the database. I feel this was successful, the scripts do what we need and as you’ll see lead on to better things.

Continuous Integration

Once we had automated builds in place, it made sense to get some continuous integration going. Initially it was with vanilla CruiseControl, but later switched to phpundercontrol. I consider this a success from the developers point of few, particularly because mistakes made with database schema updates or procedures are quickly highlighted. On the other side, the managers haven’t really embraced having a ‘cutting edge’ version of the application running and have pretty much ignored it. This may because of the dataset the database has, but that could easily be changed.

Unit Testing

This is definitely one of the most effective tools I’ve introduced and our collection of tests is growing. Originally I wrote a few unit tests for my own code using phpunit, but then started to encourage the other developers to have a go. One way in which I achieved this was to introduce the developers to writing tests for very easy classes/methods. We have alot of transfer object classes with various getters/setters, so to get them started I generated skeleton test classes for the value object classes and asked them to fill the gaps, even getting the trainees in on the act. Now everybody understands what the unit tests are for and how to go about writing them and we even uncovered a couple of mistakes in the transfer objects. Hopefully this will encourage the developers to not only write tests, but try to write code that can be tested in this way, along the low coupling, high cohesion track. Again, I see this as being a success with the developers, but will probably find managers questioning it’s usefulness.

Scrums/Stand up meetings

Part of my job requires that I anticipate problems in meeting deadlines on the development plan, to deal with this I introduced daily stand up meetings. Initially people, myself included, found it hard to focus on the three basic questions…

• What did I do yesterday?
• What stopped me achieving all I wanted to?
• What will I be doing today?

… but in the end we started to get going and I think everybody found them moderately useful. This went a little wayward when our little meeting room got taken over for a period of time, but then we started running the scrums in a chat room. Not only did this make it easier for everybody, we didn’t all have to do it at the same time, but it stopped us getting carried away with things and also everything was logged. I can look back through the logs to see what we said at the scrum three Fridays ago etc.

Peer Code Reviews

This was quite a no brainer, it helps spot mistakes or code that’s not quite up to standards. I basically wrote a ruby hook for the subversion repository that emails a random developer asking to run a code review on every fifth commit. I also involved the trainees, so they get to review code the full time developers are writing for the main system, giving them a little insight into the applications codebase. These have been successful and the team confirmed this in a recent meeting.

Scheduling and Estimates

I’ve tried to encourage the developers to generate and provide better estimates for their workload to the managers with mixed success. Despite trying to explain the benefits of using a simple estimating technique, only two developers have taken to it well. I’m happy for the others to generate their own tools and methods for providing estimates, as long as they work.

Tags: lead developer, methods, tools