Today’s post is short essay concerning the value of development led quality. There are no code examples or short tips for things in this post. I hope you enjoy.
Imagine for a moment a teacher instructing his or her students to phone it in on a single assignment. Now imagine that same instructor giving that same direction for every assignment and project in the class. The student’s joy of getting off easy once or twice may eventually meld into cynicism about the class’ instructor and disdain for the course in general. For those of us who have attended a University this sort of class may be known as the easy way to get some credit to raise grades, not to learn something. Asking for a particular level of quality sets the tone for both the instruction and the class.
This is, of course, literally academic. In the experiences I have had in professional settings the ease with which someone passed through courses is sometimes seem as a badge of honor. If not that then at the least the difficulty or lack thereof in an individual’s education is significantly less important than the work entailed by his or her current position. As it should be. It is problematic then that it is not hard to draw parallels between the mediocre, half-hearted, effort of a gimme course and what gets asked of developers. Too often the ideas behind agile development get twisted into program directives that lose sight of the fact that MVP stands for minimum viable product.
Asking a product team to intentionally reduce quality in order to meet a deadline is a great way to ruin morale and take the wind out of the team. It also hints at that different stakeholders read different meaning in what viability means for a particular product. From the perspective of sales and product management, meeting promises made and solving the customer’s business problem is primarily and, perhaps, entirely what is needed to create a viable product. It is true that missing a promised feature or capability required by the marketplace can lead to the failure of a product. What we make negotiable too often, however, and do not consider as part of a product’s viability is its quality.
The discussion of decreasing quality is never so boldly stated as, “we will reduce quality to hit a target date.” Instead, we discuss automating tests or not. Automating deployments or not. Writing solution level functional tests or not. Taking the extra time to refactor a implementation for better reusability or not. Unfortunately, in my experience the quality of a product tends to die the death of thousand cuts instead of being cut short by an open conversation about the costs of reducing quality versus a development deadline. Agile tools like Trello, Jira, and Mingle are great for managing work and sparking the needed conversations between product stakeholders and developers that are required to efficiently deliver products. Quality related items because of the time they take often end up as tasks in the project tracking tool.
All too often, once an item is in the tool, be it Jira or equivalent, it becomes a negotiable item for what determines the minimum viable product. Quality is a negotiable item; writing automated tests is something that a team can choose to not do in favor of spending time elsewhere. The problem is that the trade-offs for quality related items can be less well recognized and appreciated than those for features. This is not to belittle the conversation about feature prioritization and project scope. Within complex products features can be interlinked and lacking one can cause downstream work (or reputations!) to suffer. Still, in terms of conversations about cutting or keeping scope, a feature delivers some piece of functionality to a customer. That piece of functionality is a relatively known quantity that can be weighed against the cost of implementing it. Broadly speaking, quality concerns tend to be cross cutting. Automated deployments impact how fast I can deliver any feature. Automated functional tests impact how much I can trust the product to behave how I expect it to behave. For a product delivered to paying customers, the cost of a quality trade-off is higher than the cost of not delivering any single feature.
Quality trade-offs can also set the tone for a product. I have worked with a number of developers now and none of them have ever wanted to intentionally do a “bad job” or make a half-hearted effort. Agreeing to quality reductions is a great way to get a team to deliver a worse overall product and decrease morale to boot. Team morale is a hard thing to measure, notwithstanding all of the paid consultancies who claim to help with it. It is a fairly sure thing though that asking a motivated team to deliver (significantly) less than what they deem as quality is a good way to make them wonder why they are there in the first place. Just as mediocre expectations can be unintentionally set for classes, it is possible to set mediocre expectations for products.
I am someone who works on the development side of things. As such my point of view tends to be skewed towards arguing that software design and quality are things that cannot be cut in the face of an impending deadline. This is not always the correct position and as mentioned earlier, even the most basic of software product quality items are negotiable and cuttable. That said, however, software developers tend to be optimistic and can underestimate the adverse impact of lowered quality on both the viability of the product (and possibly their own morale). Product managers may not always be fully aware of the trade-offs made by cutting the delivered quality of a product. The point is that the potentially large downside to product viability and team morale is missed when making quality cuts in favor of up front time to delivery gains. Penny-wise, pound-foolish.
At the very beginning of this I mentioned the importance of development lead quality. A project’s scope can be changed–this is the point of agile processes–but I believe that items which ensure a product’s quality should be given deference. The people who know the technical importance of quality items is the team building the product and it is this same team which should be left to build the product to their (highest) standard of quality. Unfortunately, an inexperienced team that has not suffered through the trials of poorly launched and operated products may be just as ignorant of good quality procedures as a layman from the street. We can all get better over time though by recognizing the lasting impact of quality on a product, even the inexperienced in failure and gross underestimation of how late into the night a bad deployment can run.