Process
Moving targets shred stationary plans.
Quote category three in the Desktop Don Reference (DDR) is about Process. A structured approach to software development can help you adapt to the ever changing landscape of problems. Extreme Programming (XP) is the software development methodology that has had the greatest impact on me during my career so far. The values, principles, and practices described in Extreme Programming Explained by Kent Beck helped shape the way I think about developing software in the early 2000s and through today.
Process
How can we build the simplest software that could possibly work and change it as necessary over time? Software developers are human and we need to build confidence, overcome adversity and adapt to change.
The following are the three quotes from the Process category with an explanation for each.
Make it work, make it right, make it fast.
If you haven’t read Test Driven Development by Example or Extreme Programming Explained by Kent Beck, I highly recommend both. I attribute this quote to Kent Beck and his recommended approach of writing failing tests first, getting them to pass, and then refactoring.
What does it mean to me?
We read code more than we write it. Passing tests tell us how the code works from the outside, and helps us build confidence about the code that we wrote on the inside. When we work on systems that will be around a long time (> 1 year), we should invest in things that help us build confidence that software we create works, and that the software will continue working for 5, 10, 15, 20 years, even after many other folks have changed the code. We build working software based on what we know today, and our tests persist as executable documentation and a mechanism to help future developers confidently adapt to change that will inevitably happen.
Testing and refactoring will be part of the culture of every team that is in the software development for the long haul. I say this as someone who has been involved in Java code bases that are over twenty years old, and that continue to survive and thrive because they were continually tested and refactored.
If it hurts when you touch it, then don’t touch it.
I usually tell folks that this is my favorite quote. I learned it from my mom. Remember when you got your first scrape on your elbow or knee and you told your mom it hurts when you touch it? Remember what she told you? I would guess it would be something along the lines of this quote.
What does it mean to me?
So what does this quote have to do with development process? Developers are amazingly persistent and resilient. It used to astound me how many developers would look at production support duty as something they would only have to do maybe once a month, and when they were on support, they would do the minimum amount possible to serve their time and then get back to regular coding. They would not use the time they are stuck on support to spend time fixing the repetitive problems that everyone on support faces. They go into support mode with their eyes closed, and keep touching their scraped elbow non stop for a week, until their elbow is completely numb and is almost ready to fall off. Then their time served is done and they go back to coding. They go in without a plan to make things better. This is a generalization from my past experience, and I hope there are teams that are out there that encourage the practice of making production support better when they are working on production support. Teams should take time in group discussions like retrospectives to discuss and plan time to fix issues that are causing pain for the team.
Don’t keep touching it. It hurts! Fix it. Figure out what makes aspects of your systems painful and time consuming for you and others. Then take some time to improve the situation. This time taken will help you and everyone on the team save time in the long run.
Plan is nothing, planning is everything.
I worked on a team with a former tank commander a long time ago that told me this quote. He said it convincingly with a thick accent and he would bang his fist on the desk for good effect as he said it. I did some research years later when I published the Desktop Don Reference to properly attribute the saying. I traced the saying back to Dwight D. Eisenhower.
What does it mean to me?
Spend time coming up with plans. But be prepared to throw those plans out the window and come up with new plans once you engage with the coding process and learn new things. The more time you spend crafting the perfectly documented and wallpapered plan, the less time you have to react to all of the forces you encounter in the software development process that will require changing you that same plan. At the end of the day, the most important thing is the software. Plan to keep planning as necessary to deliver the best software given budget, resource, and time constraints. Your users will be able to use your paper plans once to roast marshmallows, but in the end they will hopefully care more that they have software that they can use to solve their problems. Timebox your planning activities, and plan to continue planning and adapting throughout the lifespan of the project.
That’s all for Process
I hope you enjoyed the read, and will stay tuned for category number four: Time. If you haven’t already, you can read about category number one and two: Simplicity and Quality.
Thanks for reading!
I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.
