Then she gets up and leaves. The patient is still on dialysis, still bleeding in places, and their internal organs are still on show for everyone else in the room. The patient’s immediate future is secure, but eventually they are still going to bleed to death.
As a DevOps engineer, perhaps one of the best things you can do for an engineering team is to empower them to write and utilize tests. This may be as simple as setting them up with a hosted CircleCI account, or might be as involved as setting up an entire build pipeline on an internal CI system like TeamCity, AWS Codebuild or Jenkins.
Personally, I find integrating tests into a pull request flow to be the most useful, and usually a simple CircleCI configuration is good enough to ensure a constant green tick is shown against any potential code change before review occurs.
Our test suite [was] a shield to deflect nasty bugs and protect us from shipping crap. Five years later we realized it was so much more. Our CI pipeline was the codified “way we did things”, an agreement among engineers about what should always happen. More important than saving us from bugs, it could have been saving us from the minutiae of working in a team: the friction of constantly coming to agreement.
Regretting Wasted Time
I had the valuable opportunity to meet up with an engineering team I'd worked with in New York, while working for the YCombinator startup Grouper.
We spoke at length about the work we'd done 5 years earlier. Our highs; our lows. We are all very proud of what we achieved working there, despite the business's failure to find its niche.
We agreed our best decision as an engineering team was to deploy immediately and automatically whenever we merged a feature branch to master. We had a fantastic test suite, and this allowed us to do so without fear.
Our biggest regret was not adding the more trivial things to the testing pipeline.
For example, automated code linting and style auditing, or checking that a branch had been correctly rebased. The sort of tiny details that tend to bog down pull requests and code review.
We considered our test suite a safety net; a shield to deflect nasty bugs and to protect us from shipping crap to our customers. Five years later we came to realize it was so much more. Our CI pipeline was the codified “way we did things”, an agreement among engineers about what should always happen. More important than saving us from bugs, it could have been saving us from the minutiae of working in a team: the friction of constantly coming to agreement.
Communicating the Importance of Tests
Some engineering teams immediately latch on to the concept of testing. Some don’t.
As engineers, we are not known for our ability to sway opinions and influence people. One of the most important lessons I’ve had to learn in this industry is this: if you are trying to convince an engineer using words, you’re probably doing it wrong. You earn emotional good-will in a team by working hard and making your colleagues’ lives easier.
Communicating the usefulness of tests is one of the most common issues engineers face when confronting a heterogenous team of strong-willed and intelligent colleagues. It can be easy to push too hard against people who quite simply have never had its value proven to them.
I suppose you expect me to tell you to build it, and eventually they will come around. Yeah, maybe they will. Maybe they won’t. Maybe despite all your effort you’ll be left with a cowboy or two; a surgeon who is happy to cut people up, but never seems to put the time or effort towards sewing them back up afterwards.
Surgeons Who Won’t Sew
Imagine you had a brilliant surgeon. In the ER she is the one you call for when things start looking dire. She works wonders with the scalpel. She can break through a rib cage in less than a minute. Within two she has performed a lung transplant. Then she gets up and leaves. The patient is still on dialysis, still bleeding in places, and their internal organs are still on show for everyone else in the room.
The patient’s immediate future is secure, but eventually they are still going to bleed to death.
The rest of the surgeons return to the patient and begin the maticulous task of stopping the bleeding and sewing up every small incision. If this team is not carefully managed, these surgeons may grow to resent the one that left. However, given the team is in agreement, perhaps this dynamic is perfectly fine.
A Place for the Cow People
I’d argue there is a place for these cowboys and girls. It’s easy to assume they don’t belong in your “shiny new agile workflow”. Maybe they do?
Properly managed, a person of the cow variety is a huge asset. They’re often the ones staying late to finish their new idea. They’re often the ones with the most enthusiasm for a project.
Improperly managed, this sort of person can cause other team members to resent the extra work they create.
Keeping these two aspects in balance is a constant battle for any engineering manager.
So next time you’re upset with a colleague because they refuse to write tests… or perhaps something more trivial: they use spaces instead of tabs. You’re not necessarily right because Hacker News agrees with you. Like everything in this industry it’s a delicate trade-off. So join me in the grey area, I’ll be there writing more tests.
