We'll respond shortly.
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:
If you’ve chosen the strongly recommended approach b, hopefully the following will make your transition smooth.
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.
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:
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.
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.
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.