A friend of mine brought up a common struggle for many software developers, particularly independent consultants:
How do you influence your clients to demand their apps have effective unit and integration test coverage? Quality is a tough sell because the customer doesn’t directly see it.
This struggle between quality and expediency is a common thread throughout any developer’s career. It’s a big reason why I was so excited to publish Architecting Applications for the Real World on Pluralsight. Once we learn best practices, it’s natural to have a desire to apply them everywhere. Yet once pressure is applied, developers tend to revert to the mode that they feel allows them to move fastest. And this commonly means temporarily ignoring clean coding practices and reducing or altogether eliminating efforts in automated testing. Yes, many feel TDD helps them move faster in the long run, yet a recent study by Microsoft found TDD added around 15-35% to the initial development timeline. Thus, like many architectural best practices, TDD is an investment up front for potential payoff later (in both improved design and enhanced agility down the road).
So how do we assure that there’s adequate time to build sufficient quality into the application? I see two approaches to consider:
- Developer dictates quality. Code at a level of quality that makes you feel comfortable, fulfilled, and professional. Don’t even broach the subject with the client. There’s no requirement that we expose decisions on such technical details to the customer, right?
- Customer dictates quality. Engage the customer in conversations about the current constraints and their impact on code quality. Attempt to sell them on the need for these best practices, the impacts of technical debt, and the cost/benefit ratio. Be flexible and ultimately let the customer make the call on the level of quality they desire.
While neither approach is universally applicable, I tend to choose #1. Why? They’re paying us to be professionals. And as professionals, we should analyze their situation and flex the quality of the implementation based on an assessment of their current and future needs. If I feel that means their timeline is unrealistic, then I discuss the need to flex the feature set or the timeline. I only hack something in to hit the date when I think that option is truly recommended for the client in their current situation.
A Human Service Layer
Think about your job as a service layer. Yes, they’re all the rage these days because they provide a coarse grained, friendly, and reusable API. As developers, we provide a human service layer to our clients. Yes, we’re aware of the fine grained API and plethora of options that we’re working with behind the scenes. But that doesn’t mean we should expose all these choices to the client. They’d likely be both overwhelmed and annoyed. They’re paying us for our judgment.
If you consider other fields, there’s indeed a precedent for hiding information from clients. An architect won’t mention all the potential materials that could be utilized for a structure. She’ll consider the situation and recommend a short list that makes the most sense in that context. A doctor won’t enumerate every potential drug or surgical option to a patient. He’ll instead recommend a specific course of action based on his expertise. We know this to be true because patients often seek second opinions when they don’t like what they’re hearing from the doctor. We assume the doctor is hiding some options he feels aren’t advisable.
We are software professionals, so we know that quality is not an all or nothing decision. We should consider the client’s needs and select an approach that balances quality and expedience. And yes, this means the answer likely won’t be 100% or 0% test coverage. But make your decision based on context, and if the timeline doesn’t afford you the time to deliver at the quality you believe is merited for this project, then it’s not suddenly time to start silently reducing quality to hit a deadline. Instead, it’s time to talk about flexing features and deadlines. Reducing quality below your professional recommendation in order to hit a deadline is malpractice. An architect won’t risk public safety, the company’s future, or her reputation for the sake of a deadline. Neither should we.
How do you balance quality, cost, and timelines? Do you discuss options for quality such as automated testing with your clients? Chime in via the comments below or on Hacker News or Reddit.