Zen And The Art Of Software Development

There are times when we need to slow down to learn how to go faster. There are times when we need to slowly learn something so we can maintain our current pace. There are times when we have to put in the extra hours and extra effort to learn something so that we don’t impact the current schedule. Which of these situations (and probably more) is right for you and your team, is up to you and your team to decide. However, if we default into “don’t learn because we don’t have time”, then we are immediately subjecting ourselves to becoming outdated and ineffective.

The philosophical content of this post is a tangent to this question from a coworker / mentor (who doesn’t blog! shame on you, Quincy!)

“As our techniques and technologies change, when do we have/make time to practice?”

Sharpen The Axe

The old adage of taking time to sharpen your axe comes to mind, here. If you try to cut down a tree with a blunt chunk of steel, you’ll not get very far. You will not be productive for long. If you take the time to stop, learn how to sharpen the saw, and then get back to work, you will remain productive for the majority % of time. This is a lesson that our teams continue to fail at learning. We keep driving people to work harder to get this one last release done and then we’ll improve… and we start the cycle over again. Someone has to take the time to stop and sharpen the axes of the team.

This often means that I am slowly introducing new and better ideas into a team, a little bit at a time. I take a few steps in the right direction and guide people down a better path. Eventually the path we’re on will expose additional problems in how we are working. Many people see the exposure of problems as think that they are new problems or problems that didn’t exist with the old way of doing things. They don’t see how the problem was always there, it’s just being exposed now. This is where the true core of the team will be exposed – are they willing to work through the problems and fix them, so they can move on to better ways, or do they revert back to the old ways because they don’t want to or can’t see how to fix the problems.

I take large amount of responsibility for continuous improvement, personally. I try to have the answers to the hard questions before the team is asking them. I hope you do this, as well.

A Pace Of Change

I worked on a team of 5 developers. We had been working on the same project together for the past 2 years, so we knew each others’ strengths and weaknesses. One day, we were told that a developer from another team would be joining us for a few months, because his project was waiting for funding. After the first few weeks of this person being a part of our team, he asked us how we keep up with the constant rate of change… he noted that in the few weeks he had been part of the team, we had changed a few of our fundamental architecture concepts, some of the BDD syntax of implementing unit tests, several standards on how and where to do input validation, and a few other items… all within the time he had been on the team. The most junior of developers on the team (this is his first job out of college) looked at him, shrugged, and said “i don’t know…that’s just how we work.”

The point is that It’s far less about the pace of change, from an outside perspective; and far more about the pace of change for the individual team. Alan is right when he says that Toyota is keeping up with their own ideas, and that’s the point that should be emphasized. When my team was operating for those 2 years, we had a natural pace of change that emerged within the team, after many months of continuous effort to socialize and standardize the processes that we followed. We spent a lot of time as a team discussing our standards and what they meant and why we used them, during our retrospectives and standups. The constant communication of what the standards are and why are they are important, lead the entire team to naturally look for better ways
of working and suggesting them to the team whenever they saw something to improve.

Don’t compare yourself or your team against any other team’s pace of change. Rather, work to standardize the way your team is working by constantly communicating the standards and discussing why they are in place and what benefit they provide. Let your team have input into the standards and offer options for improving them, and eventually you’ll find yourself and your team changing at such a rapid pace, that onlookers will be overwhelmed by the pace of change.

In Theory And Practice

I like to think of software development in the same light as a “Medical Practice” – the Doctor is legitimately a doctor… but they call it a “practice”.

define:practice (from Google)

• knowledge of how something is usually done;
• carry out or practice; as of jobs and professions;
• a customary way of operation or behavior;
• translating an idea into action;
• commit: engage in or perform;

In that same sense, what we do on a daily basis is a practice. Now, I know you’re talking about learning and practicing, but I think there are a lot of parallels that we can still draw from the medical “practice” idea. A doctor “practices” every time they see a patient and perform any procedures – whether it’s diagnosis, solutions, or preventative measure. Software development is no different, in this respect.

The continuous improvement of our development efforts should be considered a “practice” from this same definition set. We only need to continuously practice change, to become good at it.

Zen And The Art of Software Development

Kenji Hiranabe recently made some statements that follow along this line of thinking. It’s certainly a philosophical tangent to this subject matter, but it illustrates the point via another culture:

“Principles and practice are the same. Dogen Zenji says that if you think that Zen (sitting meditation) is the means and Satori (spiritual emergence) is the goal, you will lose your way. They are the same. Doing and thinking are intertwined and they together unfold the secrets of the art of living.”

     – Kenji Hiranabe, via the KanbanDev mailing list

In the same manner as Zen / Satori, software theory and practice are the same, and medical theory and practice are the same. Our practice on how to write software comes from our experience and the theory that if we reproduce the processes that have been successful, they will continue to be successful.

This passage sums it up nicely:

“If your reaction has been that theory is too complicated – that you’re an action-driven manager and are not a theory-driven person – think again.” … “While you may not have known it, you have been using theory for the whole of your managerial life. WHenever you have taken an action or made a plan, it was predicated upon a theory in your mind that your actions would lead to the envisioned outcome.”

     – Clayton M. Christensen and Michel E. Raynor, “The Innovator’s Solution”, p 287-288