Good morning and here we are on day two of the Pacific Northwest Software Quality Conference. It was interesting to see the effect of the program yesterday and my liveblogging approach. This is something I am used to doing and I have done it for a decade now, but I am definitely feeling the after-effects today. There was a lot to take in yesterday and I went to bed early last night (LOL!).
In any event, we are now into day two, and the first keynote, which is Derk Jan de Grood talking about "Built-In Quality". Now when I hear the term "built-in" I almost always associate it with the idea of "bespoke", meaning it is literally built to fit into a place seamlessly. Think of the idea of a refrigerator and/or a microwave oven that blends perfectly with kitchen decor. Those are what I usually think of as built-in. Built-in is a great concept and can look fantastic but it comes at a pretty high cost. One that is obvious and up-front, but one that is not so obvious, and that comes later. I'm aware of this right now specifically because of the fact I had to recently replace a microwave oven in my cabinet space that was originally built-in twenty years ago. The issue? that model was no longer being made and replacing it was not so simple. We had to go to great lengths to find a unit that would mostly fit and decide we were okay with it. For the most part, we are, as we care about the functionality of the unit (we need an oven that works reliably) but we can also see in the space it resides now that, if we want to have it look like it belongs seamlessly there now, we are going to have to retrofit the cabinet to fit the purpose.
This may seem like a weird tangent but please work with me here ;). I mention this because I want to set the stage a little bit for this talk that is literally happening as I type. This is what I'm coming to as I think of "built-in" and the warning that goes off in my head now as I consider that term.
As we talk about organizations and how they are going to deliver a quality product, this brings me back to the idea of "built-in" and how I often think about it. Built-in points to custom work and well-crafted work, sure but it also points to something that may not be easily repeatable. Teams that make a quality change that has great inroads do so because of the people, the culture, and the processes that all embrace and opt to work with.
Derk also points out that the idea of built-in quality takes from this idea as well, in that it is easy to do this level of bespoke work and keep quality high when teams are small and projects are closely contained (again, using my microwave example) we are able to make fit and finish work well with a small project (repair and replace is a different issue but at the point of initial creation and deployment, we can do an amazing job in a small space). Now let's think about that level of quality for an entire house, or for an entire building complex. Now the issue becomes harder to implement. Just because we can do something well in a small space does not necessarily mean that same level of focus and detail will automatically scale to larger projects.
Now let's step away from my metaphor which realistically will only take us so far as we talk about software quality. In many cases, we might think that building in quality just means we test more and screen the software more vigorously. Again, in a small organization or a small application, that may very well be a good strategy but as the project becomes more complex, and the project has more touch points and people involved with them, testing more and more falls prey to the law of diminishing returns. We now have to deal with the fact that time is against us, we can't just automatically do more testing when time demands we move more quickly. Either testing needs to be focused in a much tighter and deliberate fashion, or the approach to building software itself needs to change.
If we look at Agile today and how Agile is meant to have us release software, as well as CI/CD and a DevOps model of software development, the idea here is to try to utilize that bespoke model of the craftsperson and focus on small targeted changes more frequently. Going back to my house metaphor (okay, I guess it still matters a bit ;) ), we can consider this to be working on small remodels regularly, such as replacing a single light switch here and there, and doing that with a full focus on clean and effective construction and wiring techniques, whereas if we had to replace al of the switches at the same time in the same amount of time, the overall quality across all of the switches would be, well, questionable at best.
To come back to Derk's presentation, he has identified seventy-five possible areas where quality can be focused on and that quality can build and increase inside of our products. One of the most obvious ways is that everyone in the software development organization has literal ownership of quality. That means that development and testing should be integrated at all levels and at all touchpoints of the product life, including before the product ships and after the product ships. Additionally, Derk suggests that we all understand and have an organizational-wide understanding of what the 'Definition of Ready" means. How our pipeline is created and how the steps interact with each other is also critical.
Overall, built-in quality is not just something you can strive and wish for. It's understanding where the quality and skill aspects of development already exist and under what circumstances they are optimally applied. To expand that level of quality, it will take time, talent, and energy, along with bringing people up to speed to be able to be effective as the implementations grow. There are a lot of potential distractions and challenges that come to play as we try to expand this to larger organizations and to more people. It's also important to realize that quality in and of itself is a cost and that cost can often be very expensive (back to my built-in example of our microwave. Odds are we could have gotten a really good unit that just sat on our counter. However, we'd have to trade valuable counter space for that and in the end, that's the whole reason why we built it into the cabinet to begin with. Thus it is important to consider what the quality we are providing actually buys us.
No comments:
Post a Comment