Posts Tagged ‘Training’
Teams Can Teach Themselves
As part of the transition to agile scrum at one company I worked for some key software engineering considerations: code maintainability, test coverage, extensibility and scalability came under review. Although products were being delivered, problems were being built into them.
As an engineering team we set ourselves the challenge to start practising TDD (Test Driven Development) within a year. This goal would force better code quality and the code would be future proof as it would be designed to accommodate change.
Such a goal isn’t easy to reach. If the engineers aren’t used to building software in a certain way they can’t just start doing TDD. There needs a period of education; engineers need to loose bad habits.
Sending the engineers on a course could be an option, however, aside from the fact there may be no budget for that, to truly progress the adoption of a sustained learning process is far more beneficial.
We set up a series of weekly hour long internal seminars. Both engineers and the business made concessions; the time of the seminar was 1.30 – 2.30, half over lunch time and half during business hours. We booked a room away from the bustle of daily working life, organised a projector and all the engineers week by week presented on topics we believed would improve their standards of coding. We started by examining design patterns, but soon found we needed to revisit the core principles of OOP (Object Orientated Programming), with particular focus on the Bob Martin’s PinciplesOfOod, also known as the S.O.L.I.D. principles.
Armed with a couple of really good books – Bob Martin’s book Agile Principles, Patterns, and Practices in C# is a fantastic teaching aid – and a lot of support for each other, over a period of six months we moved on to look at the TTD approach and the team’s standards started to improve. After those six months, all new work had to be built using TDD. This was partly successful during the following six months because it was not so easy to write tests against legacy code bases.
A year after the comments from the contractor, the team worked on a green field project. After only four weeks the system was complete. Code maintainability, measured using Microsoft Visual Studio’s code metrics tool, averaged 80 points (which is good!). Test coverage was around 50% for the entire solution, but more importantly 80 -100% in the solution projects containing the business logic (a good post for how to write good unit tests). The engineers were practicing TDD 70% of the time, hindered by falling behind schedule due to problems communicating architectural design expectations.
This is a great achievement. Now the team pair programmes most of the time, working with each other to strive for excellence. Subsequent topics for the seminars included looking at “interfacing the ball of mud” in order to create testable code against legacy systems not designed for testability. The team designed strategies for refactoring legacy systems into a testable architecture and began adopting DDD. The internal seminar is a permanent fixture, anything can be discussed, although it is best to select topics relevent to the business.
It took the best part of a year to see real improvements; I don’t know whether you think that is too long? I don’t. It’s difficult for a team to massively shift their practices whilst minimising the effect on their output for the business. The point is, if your business and team are willing to commit the time – the hour a week for the seminar – and your senior team design and constantly review a quarterly syllabus, the team will teach themselves and improve the quality of their work.
