I have happened upon the importance of habits recently. I have always heard “good habits are important”, but I never really embraced that in a thoughtful way.
That changed when I had a health crisis. I realized that I needed to make a change to get healthy. I needed to create new habits with respect to nutrition, exercise, and holistic health (including mental health, sleep, you name it!).
I would often set myself lofty goals, and then if it didn’t look like I would reach them, everything would fizzle out. On the contrary if I can do something incremental on a daily basis it sticks, given enough repetitions to kick in.
Software Habits
A lot of the changes that we have seen in software development revolve around habits too.
Agile
I tend to dislike proprietary terminology or One True Way. There has been a backlash towards Agile ™ as many have seen it slip into dogma. As soon as you find that you have forgotten why you are doing something you are in trouble. The agile manifesto itself is a simple document that talks about values: favoring X over Y.
Some took this and created religion around them. There are fascinating spiritual questions, and long term values and learnings around how to live a good life. Certain folk managed to persuade people that their recipe is Truth whilst the thousands of other recipes are so wrong that you can end up in hell for believing them. Fortunately we don’t think that Scrum is an infallible document passed to man from God, so let’s keep trying new things and focusing on what works, what doesn’t, and why.
Athiests can also tend to poo poo particular practices. Some are bizarre and even barbaric, but others make sense. Alain de Botton lays out this case well in his book, Religion for Atheists.
Let’s not make the same mistake and ignore the good things that have come from various methodologies out there. Let’s not try to setup our own habits because we are scared to “be as bad as them”. Checklists don’t stiffle, they can save you from making mistakes, forgetting good knowledge, and give your brain the time and space to noodle on the important problems at hand. Dogma occurs when you forget why you are doing something and refuse to change with new knowledge and learnings. Practices that do change upon reflection, including looking at first principles, are a great thing.
Continous X
There are many tasks in development that we have managed to chunk up and allow us to do them more frequently. I am old enough to remember the bad days where people were scared to do a certain task because they couldn’t trust how it would go. At every release you would see people with crossed fingers, first for the release to get out well, and second to make sure that if a rollback was needed it actually worked. Today we release all the time and some are actually pulling off continuous deployments and ideally delivery.
We have seen the same thing elsewhere:
- Writing and running tests
- Creating and merging branches
- Setting up infrastructure.
There is a huge pay off when you can trust your process. You can deliver higher quality product with less risk and a much improved pace over time to boot.
There are severe penalties for not catching things early. I remember the work at Palm where they found that: if you catch a bug on the same day it was introduced you can fix it in around an hour. If you catch that bug later it can take 24 times as long, and take a day. It is obvious why: your brain was right there so you don’t need to context shift, and the changes are few.
The core of an good process in my mind is simple:
- What are the core values of the team
- What practices map to those values
- What habits will result in an improvement
- Reflect and iterate.
A process that shows agility seeds the core values with the ability to change quickly because of the simple observation that those things that can’t evolve tend to die. This doesn’t mean that the process is fast. It may take effort to build agility into your software, but the bet is that it pays off and gives you the best chance of not getting stuck in the future.
The key to non-dogma is the retrospective. As long as you can revisit and try new things you can get to where you need. Just as with A/B testing, sometimes you can’t iterate to a better solution quick enough. Iteration is great if your dart was pretty close to the mark but sometimes you should throw another dart.
What are your and your teams habits? When was the last time you took a deep look at the why as well as the how?