Lesson 3: You can't ensure quality when you don't know the domain

Background

I’d like to share a story about failures I experienced as a software architect which taught me the lesson "you can’t ensure quality when you don’t know the domain."

Early in my software development career, I worked for a company that created software for the automobile sales market in the United States. During this time, I was a very junior developer and was working on some homegrown ASP.NET web sites developed and maintained by my employer. Largely these websites serviced employees internal to the company, but some of them were customer-facing applications.

Outcomes

I was so junior at this time that I didn’t understand what it meant to take pride in one’s work. I wasn’t a master of my craft, yet. I barely recognized that I even had a craft, as I was still getting used to not being a martial artist anymore! (More on that story another time.)

My quality during this time was abysmal. Almost every time I finished work, it had to be sent back to me due to bugs and defects. I was keenly interested in automated testing, particularly unit testing, but I didn’t have even a vague notion of what good testing looked like (many projects and years later, I still don’t think I have a clear idea of what good testing looks like, but that’s a different problem).

I was certainly a fast developer, but with my quality being poor, I wasn’t going to be climbing the corporate ladder any time soon. I had regular conversations with my manager about my performance, and while he complimented me on most aspects of my work, he made sure to hammer home that my quality was horrible.

Mistakes

It’s easy to think that my mistake was simply not spending enough time testing. However, that wasn’t the problem at all. I certainly spent time testing, and I tested as many things as I could imagine. My real problem was that I didn’t know the users or how they used the systems I was maintaining. Work was handed to me in the form of “requirements” from my manager. I never once met one of our end users of any of our systems! I was a victim of KDAFU: Keep Developers Away From Users. This is the mistaken belief that we get better results if development team members are prevented from having direct interaction with users.

Lessons Learned

I later learned that this is key: you can’t build quality in when you don’t understand the users and what they expect from the system. This is so pivotal that I’m willing to stake a claim: allowing for the extremely rare exception, I submit that 99% of projects where there is poor quality suffers from the KDAFU syndrome.

There certainly may be other issues going on as well, but this is at the heart of poor quality. It is absolutely critical that development team members understand, and regularly interact with, users so everyone is not only speaking the same language, but everyone is marching towards the same goals.

Agile Reinforcement

The key principle from the Agile Manifesto at play here is "Business people and developers must work together daily throughout the project." This seems so obvious given the scenario I just painted, but it’s very difficult to recognize the damage that acting contrary to this can create. After all, many developers are introverts and would prefer not to interact with other people at all. In addition, many developers are socially awkward and say horrible things in front of customers and users, myself included. So, the typical management approach is the KDAFU syndrome: Keep Developers Away From Users. However, the results of this syndrome are highly predictable: poor quality. Additionally, social interaction is a set of skills that each of us must develop. We are, after all, social creatures (whether we like it or not), and, as with any skill, we get better at social interactions with deliberate practice.

SAFe Reinforcement

The key principle from the Scaled Agile Framework for this scenario is "Decentralize decision-making." In truth, the KDAFU syndrome is simply a model or a paradigm in which some intermediary (usually a manager or product person) is interacting with customers and users, making decisions about what the user wants or needs, and then conveying that information to the development team in the form of requirements (which sometimes masquerade as poorly written user stories). Effectively, the decision-making about user-level and product-level decisions are centralized in these intermediaries instead of letting the development team members interact with users where everyone collaboratively decides on what to build, when, why, and how.

To be clear, I’m not suggesting that product people shouldn’t be involved. What I am saying is that all team members should be involved in conversations with the customers and users, not just the product people. The creation of intermediaries (colloquially called "middlemen") is usually an indicator that decision-making is being centralized. Even if that’s not the intention, the outcome is that decisions will ultimately be centralized in these middlemen. And, centralized decisions are rarely as good as decentralized ones.

I hope my struggles and failures can help teach you this important lesson: You can't ensure quality when you don't know the domain.