Giving your developer’s 50% more productivity

You schedule sprints that do nothing but clean up the previous sprint. You are told that features you feel are critical to the product “simply can’t happen”. You watch feature after feature ship late and then get long bug reports.  However, you have not been idle. You’ve contracted process and technical consultants. They gave you answers and you got the green light to implement them. Things did improve, but your bottom line issue of buggy and late deliveries continue to […]

Technical Debt vs Technical Waste

Executive Summary In trying to improve productivity and reduce waste there are 3 important concepts. These often get confused, which makes it difficult to align and fix the problem. The key concepts are: Technical Debt — a way your system has not yet incorporated new information. Technical Waste — technical friction that does one of 3 things: puts existing business at risk, or causes delays and increases costs to respond to new information when it appears (aka, manage technical debt), […]

Do you have the right data for tackling technical waste?

Our background and experiences inform our instincts … and your instincts tell you that productivity is low because technical waste is in the way. How can teams possibly be effective working through the maze of quality issues they face? You have instituted process changes to help them reduce WIP. You have established the roles recommended to make communication clearer and faster. You have embraced the recommendations you’ve heard at conferences or from consultants. You and other leaders have made the […]

Naming as a Process (Article 1)

We all know naming is a pain in the ass and you can’t trust the names in your code. But it doesn’t have to be that way. Many people try to come up with a great name all at once. This is hard and rarely works well. The problem is that naming is design. Here are the things you are typically trying to do all at once while naming: Deciding the things the code should do Deciding which things go […]

Get to Obvious Nonsense (Article 2)

The two most terrible kinds of names are also the most common: Names that mislead you Important things that are just a part of something else, so they don’t even have a name. In the spirit of naming as a process, we want a quick way to fix these two problems. It needs to be trivially fast and light, so that we can do it the hundreds of thousands of times that most codebases need. We will turn Missing and […]

Get to Honest (Article 3)

We have a thing with a name. But its name is obvious nonsense.  One of my more gnarly experiences was when I worked within a system that spoke to the FAA’s system. This particular method was named preLoad(), telling me when the system calls the method (not very useful). The problem is that there is a missing name. Nothing tells me what would happen on PreLoad().  Based on Article 2, I then extracted the entire body of PreLoad() and called […]

Get to Completely Honest (Article 4)

I need to make my name fully describe everything this method does. Each level of improved naming should record more insights and make it easier for the next person to read the code. This level actually makes it unnecessary for the next person to read the code. We want them to be able to trust that the name includes absolutely everything the method does so they can read and understand calling methods without having to read the method we’re fixing. […]

Get to Does the Right Thing (Article 5)

Congratulations on having a completely honest name! It is a huge step to simply represent exactly what the code does. All of the steps until now collected information into the name. In making the name complete, we have now made it possible to reason over the responsibilities of the class/method/variable without having to read its full implementation. This sets us up to change its responsibilities, so now we’re going to use the name to guide chunking the code. Part 1: […]

Get to Intent Revealing (Article 6)

Every improvement in our name until now has focused on what our class/method/variable does. We made it honest and then we made it do exactly what we want. The name is both correct and clear. But it is awkward. We want to use this name to understand calling methods. It doesn’t yet serve that purpose. The name describes the thing. It doesn’t tell us why we care. That makes us stumble when reading the caller. We want the names to […]

Get to Domain Abstraction (Article 7)

Finally we are ready for the most important step in naming. This step is why all of evolutionary design really comes down to “name things well. Continuously.” It is time to correct the domain abstractions we are using and adjust the names. We currently have a set of names used together. Each one expresses Intent individually. Responsibilities are factored into the right places (each Does the Right Thing). But taken together, the names are a mishmash of ideas. Each expresses […]