Every development team can benefit from a mantra to bring them together - a simple set of precepts to drive them towards their goals, and a compass to help them find their way in times of stress and confusion. Ours is this: Slow Down. Keep It Simple. Do It Right.
Following these guidelines has enabled our team to make smarter choices, meet deadlines at a sustainable pace, and has given us the means to make progress in times where the best approach was hard to agree on.
Ironically, the first place I took these ideas on board was when I joined a five person dev team in a startup called Analog Analytics. When you think "startup", you normally think hurtling toward a deadline at a hectic pace. And from the outside we did move extremely quickly, often deploying several times a day, despite the stringent uptime requirements of running an e-commerce SaaS platform.
However on the inside, we were moving slowly, but surely. While our customers saw surprisingly quick turnaround on support requests, every one of those changes was carefully reviewed and tested by our account management team before being rolled out to production.
We must have done something right, because two years later, we got acquired by Barclaycard.
So what makes these eight simple words so useful? What concrete insights can you and your development team take from them, to ship better code at the same, or perhaps an even higher velocity? And perhaps most importantly of all, how can you sell these words to your manager, and convince them that slow is the new fast?
The cumulative output of all work you do in a hurry is likely to be the worst work you will ever create. In fact, the code you write while racing to meet a deadline versus the code you write when you're fresh and focussed would probably look like they were written by two completely different people.
And it's not only the code, but the process that often suffers here too. Who hasn't seen a bug introduced by a developer who made just a "small" refactoring change, and decided it was too simple to need peer review or UAT, only to merge it into your mainline branch and ultimately break the production app?
If the need for speed is causing quality to take a back seat, here are some ideas to encourage slowing down, to get things done faster:
Choose "boring" solutions. There's a time and place to evaluate bleeding edge, cool new technology, but your day job is the wrong venue for that, IMHO. Committing to technologies you're unfamiliar with is a great way to get sucked into working evenings and weekends when deadlines blow out, because of all the things you need to learn to turn something cool and new into a production ready feature. The more you learn about new technology outside of the production pipeline, the more those solutions will become familiar to you, and thus become part of the "boring" ideas that can help you deliver better software to your customers.
Limit stories to one day or less. If you tell your manager that something will take four weeks to implement when they expected it to be half that, they'll likely not be happy. Especially if you've simply broken up your estimate into four stories, estimated at one week each. The lack of granularity makes it easy for your boss to fill in the blanks with thoughts that you just might be slacking off. OTOH, if you break that estimate out into 15-20 stories that are 1 day or less, your boss may still not be smiling, but at least she'll have more information to understand your reasoning. The more refined you can make your stories, the more you can have a down-to-earth discussion with the higher-ups.
Do post-mortems for major production incidents. Post-mortems shine a light on the exact root cause (well, root causes - there are usually several) of an incident. Gathering objective data about why things go wrong gives you ammo to demonstrate how moving too quickly is causing problems for your customers. And once you're able to draw a straight line from changes made too hastily, to the pain that's causing your customers, management will start to listen.
Keep It Simple
We've all heard the advice to do the "simplest thing that can possibly work." But in practice, the road to simplicity is the road less travelled. And often, even when the "simple" solution is chosen, it's the wrong kind of simple - as in "simple for the developer to do a quick fix now, but terribly complex to maintain later."
So, what's the right kind of simple to aim for?
When possible, use only things you already know well. As mentioned previously, learning new technologies is obviously helpful, but learning new technologies on the job is a recipe for working lots of overtime.
Limit classes to 100 lines, methods to 10 lines. This may seem unreasonable, and granted you won't be able to achieve this 100% of the time, but it is possible most of the time. For example, type
bundle open activerecordin your project and look at how often Rails itself sticks to this guideline. This may require adding new tools to your design arsenal; check out 7 Patterns to Refactor Fat ActiveRecord Models for some ideas.
Regularly ask, "Do we need this?" As a lead developer, this is a question I ask at least once or twice a week, every week. For example, recently a decision came from above that we "needed" Elasticsearch, a technology I know little about. Then I asked, "Why do we need Elasticsearch?" As we dug deeper, we realized we could solve the problem with a few tweaks to postgresql.conf, and management was receptive to the idea. This likely saved us weeks of development time, and kept our deadlines intact. It's your job to push back early, and often. It's not about being a thorn in your boss's side, it's about cultivating a relentless focus on only work that truly needs to be done.
Do It Right
A couple weeks ago, I was reviewing a pull request from a co-worker, and asked them if they could break up a large, complicated method into smaller pieces. Their first reaction was to suggest just committing the code now, and coming back to it later when we had more time. This is a situation you'll likely be faced with a few times a week, either when commenting on someone else's code, or when writing your own code.
In situations like these, remember this: The cheapest time to refactor code is right now. If you don't have time to do it correctly now, what makes you think you'll suddenly have time to do it later? Sure, you might not have the current deadline to meet, but you'll no doubt have another one. And bad code does not age gracefully. Every hack that is allowed into your mainline now, is an opportunity for someone else to do something even nastier on top of it later.
The way to write good code is not to "have" time to do it, but to make time to do it. Doing it right takes discipline and a willingness to communicate an adjusted delivery schedule with your manager. In most cases, the distance between doing it right and leaving it wrong can be measured in minutes or a couple of hours. If that's the case, push for the higher road. When doing so might add days to the delivery time, at least capture that work in a story so you can prioritize it later.
Slow Down. Keep It Simple. Do It Right. I'm not suggesting these principles are easy to implement in every single development team in every single company. But even if you can only make room for a couple of these ideas over time, they will make your work more enjoyable, your deadlines more realistic, and your software more reliable.