Imagine a fateful Monday morning where you find yourself on a new project and your first impressions are: Why is the entire codebase essentially 1 file? Why aren’t the pairing stations setup to run the test suite? Why are there chores in the backlog to backfill tests on features that have already been delivered/accepted?
By lunch time you’re confused and wonder what you might have done to deserve this. But the best part of working at Pivotal Labs is knowing that you always have other Pivots to laugh at your misery. After coming back from lunch you take a deep breath, find your inner zen and debate your options:
- a. Turn into a rage monkey (Not recommended)
- b. Be an adult and step out of your fairy tale land where all code is TDD-ed and software development is rainbows and unicorns
If you’ve chosen the strongly recommended approach b, hopefully the following will make your transition smooth.
1. Why did this happen?
Its easy to come into a new codebase and pinpoint all of the things that need to be improved. But figuring out why a project that started fairly recently is in such shape is much more challenging.
Pairing to the rescue! Rotate everyday and try to look at as much of the codebase as possible with different team members. Share feedback about the code with your pair to validate it and get context about the reasons behind why it was written that way.
2. Spread the word
Instead of getting carried away trying to solve all of the world’s problems on your own, evangelize your proposals to your PM and anchor. Categorize issues as:
- –
Technical improvements
- – typically these revolve around the health of the codebase. Your anchor can help you champion big refactors, establish a team’s TDD culture or strike a balance between code quality and speed of delivering stories.
- –
Process improvements
- – do you think your team is too focussed on velocity as an absolute metric rather than a trend? Your PM can step in and help initiate changes in story writing, release planning and agile coaching.
3. Ask for help
Never forget that you work amongst Pivots. And when they are not laughing at your misery they are very very very helpful. You might just be fortunate enough to find out that the Pivot-verse has already solved all your problems. Be sure to tap on your fellow Pivots’ shoulders and benefit from all the rabbit holes they’ve already explored.
4. Refactor, refactor, refactor
If you’re still reading this you’ve identified the problems in code, got your team onboard the refactoring wagon, spoken to the Pivot-verse about best practices and you are now to get your hands on some code. This is the day you’ve been waiting for.
But, hold on a second. You’re not quite there yet.
- You might know all the areas in code you want to affect, but the quickest way to infiltrate the codebase is by having every pair making changes. Bring up problem areas with the team, or put in a chore in the backlog so the next pair that’s working in that code is aware.
- Don’t get tempted by sweeping refactors to improve code quality. Identify small changes that result in big gains. Restrict yourself by drawing boundaries in code of things you are going to change as part of your story.
- Always make sure your pair is onboard with what you’re doing. Refactoring is a time when your pair and you need each other the most. You may be blind to how your changes might affect other parts of the code (especially if you don’t have a good enough test harness to catch you.) You could get too attached to a certain way of doing things. This is where your pair should keep you in check. Getting your pair onboard also helps you rotate if the story spans multiple days.
- Design your tests before designing your code. When you are trying to decide how to best model your code or how to tease it apart into modular pieces, think about what kind of tests you would write if you were developing a feature that would affect that code. It is much easier to think about the single responsibility principle in test assertions, than when designing abstract models.
- As soon as your tests are green consider committing. You might be working on a branch, especially if you’ve taken on a story that spans multiple days but never stray too far from master.
- Oh also, you’re going to get frustrated. It is inevitable. But it won’t be anything a game of ping pong can’t fix. Take breaks, take on small chunks of work and pace yourself.
There are various reasons why a team of skilled developers can produce untested and poorly designed code. It could be that being new to Agile they feel a pressure to deliver stories to keep the velocity high, or being new to the language they don’t know the best practices yet. Perhaps while they are absolutely thrilled about TDD and are in favor of it, they are just new to it and haven’t yet developed the discipline to always write a failing test first. Maybe they are not used to working with distributed teams and don’t know how to benefit from team members in different locations.
Fortunately, while it might not happen overnight, all of these issues are addressable. So don’t be disheartened if you find yourself thrown into a difficult situation, be patient and sensitive but also persistent in effecting change.
