Do the Easy Thing First
Published on Apr 01, 2017 by dix.
Out in the world, I see a lot of software teams falling into an insidious trap. They don’t take care of the “Easy” things first. It shouldn’t be surprising that teams often do this. The easy things aren’t necessarily fun or interesting. No one writes blog posts about “Fixing builds when they are broken” or “Eliminating flaky tests”. It’s not a post that would get a lot of upvotes on Hacker News. But if you don’t take care of the “Easy” things first, the hard problems become extremely difficult to solve. In fact, this makes for an interesting parallel to a model from the social sciences.
In 1943, psychologist Abraham Maslow described a “Hierarchy of Needs” in his paper “A Theory of Human Motivation”. He described different levels of human need that must be met before higher levels of need can be met. At the bottom are the simple physiological needs; humans are not capable of greater achievement if they are hungry, tired, or thirsty.1, 2 This is an interesting framework and one which could yield benefits if applied by software leaders.
A similar hierarchy of needs can be applied to the practices of a software team. This is not entirely a novel idea. The “Joel Test”3 is an example of an enumeration of a hierarchy. I don’t agree with every element of the list and think that some of the elements on his list are more important than others. While it is not presented as a hierarchy, it satisfies my made-up criteria. The Joel test’s 12 questions are:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
Questions 8 and 9 are very basic level needs. If a developer isn’t able to do the most basic parts of her work: the thinking and typing, she won’t be able to do anything more complex. While questions 2 and 3 are higher level needs. I’m not sure that question 11 really fits into this framework, but the questions are still relevant. I won’t propose a specific hierarchy myself. It’s a complex question to answer which will vary across teams and settings. Additionally, there would be a different hierarchy for a team and for individual contributors. I will however say that testing, specifically reliable tests, and reliable deployment should always be at the most basic levels.
It’s certainly fun to try to map the various techniques, skills and needs of software teams to Maslow’s hierarchy, but this is more than just an interesting mental exercise. I believe leaders of software teams should use this model in setting priorities and guiding their teammates. For example, don’t get bogged down in conversations about architecture if your builds aren’t reliable. Further, don’t adopt an architecture that will make it much harder to meet a lower level’s needs. Or positively, consider adopting technologies or architectures that allow teams to more easily meet the lower level needs.
Additionally, leaders of software teams can use this hierarchy to inform the guidance they give to their team members. If a member of your team comes to you and asks how they can improve, begin by taking stock of the lower levels of the hierarchy. If they do not have a mastery or understanding of the lowest levels, ask them to start there. Specifically, don’t tell them to read books about Service-Oriented architecture if they don’t understand how their code is deployed to production. A coworker of mine wrote a blog post about “Good Software Developers”4, and while he does not discuss the idea of a hierarchy, I think the developer he describes is one who has mastered the lower levels of a software hierarchy.
In addition to directing the development of members of a team, a leader should also use this hierarchy to guide their team’s priorities, i.e. don’t adopt a complex architecture, if you are not able to test and deploy your code consistently. A leader of a software team should focus on the basics, once the team is executing the basics well, they have the foundation to solve more difficult problems.
Footnotes:
Maslow’s model, while very compelling at first look, does not have much empirical data to support it. So while it makes an interesting foundation to base our discussion upon, take it with a grain of salt.