Customer-Driven Development
In my experience, the way we create software changes drastically when we reach the epiphany that we must create a customer that is ready to…
In my experience, the way we create software changes drastically when we reach the epiphany that we must create a customer that is ready to consume the code BEFORE we can consider creating the code.
Prior to that epiphany, me and many of my coworkers used to think that the normal, natural way to create code is to, well, just create code. Why beat around the bush? We have some specs (i.e., requirements, expectations, blueprints, you name it), and the immediate natural impulse is to turn that spec into a shipping code.
After all, that’s what we’re here for. Create the shipping code and then ship it. Rinse, repeat.
But something unusual happens when we agree to first consider creating a customer that is ready to consume our not-yet-created code. At that point, we begin to think how to implement that customer. We realize that the real, original customer is those quick thoughts we have in our head as we are about to start writing code.
If we examine those quick thoughts, we realize that they are all about EXPECTATIONS. Something like “I’m now expecting this routine, which I’m about to write, to detect the longest word in a supplied sentence and to replace it with a shorter synonym.”
OK, that makes sense. But there is a difference between taking those mental expectations and using some process of recondite alchemy to transform them into a working software code, and expressing those expectations in an executable form.
In other words, instead of keeping those expectations neatly tucked inside our heads, or scribbled on a piece of paper (or buried inside some Jira ticket), we declare them using the syntax that machines can understand and execute.
Such declared, executable expectation is what I mean by the first customer of our yet-to-be-created code. The first customer declares the expectation by setting up the stage (in this example, declaring a sentence that contains some long-ish words and also setting up the expected sentence that will be produced after the code runs). The next thing the first customer declares is a hypothetical interface or an API that can be triggered by passing the sentence in. Lastly, the first customer collects the outcome of the API processing and compares the resulting sentence it with the expected sentence. If the expectation has been fulfilled, the customer is served well; otherwise, the customer is dissatisfied, and files a complaint.
In technical parlance, the first customer is actually a test. Once we create that test, we run it and watch it fail (i.e., the first customer complains that their expectation hasn’t been met).
We then move to create some shipping code that will meet the customer’s expectation. We run that test again, it now passes, the customer is satisfied.
What’s the advantage of creating the customer first?
By investing the time to create the customer before we create the shipping code, we switch our thinking from trying to satisfy the underlying computing machinery to trying to satisfy the need of others. Others are more important than the underlying computing machinery. Computing machinery is dime-a-dozen nowadays, and the commoditization rate is accelerating. Simply put, computing machinery is dirt cheap.
Needs of others are not dirt cheap, and should never be turned into commodities. When we cultivate “write the customer code first”, we change our mindset and focus on the right thing — serving the needs of those who matter.
There is only one way to declare a need, or an expectation: we describe the situation prior to the need being satisfied, we then enact the processing (i.e., a trigger event), and then collect the evidence and compare it with our initial expectation. If the collected evidence matches our expectation, the need has been fulfilled. Otherwise, there is more work to be done.
This need-driven approach to creating software is also useful as it enables us to know when to stop. It makes no sense to do more than is expected. Or, as Agile Manifesto teaches, simplicity is the art of maximizing the amount of work not done.
Conclusion
Our job is to improve lives of our customers/end users. Usually, that means being empathic and listening to them and trying to understand what is it that will make their lives/jobs easier, more pleasant, more safe. Typically, customers/end users will express their wishes for getting some kind of an improvement (the "please" part of the process).
Once we hear and understand the customers' "please" request, we must strive to reach their final "thank you" reply. Which means, we will choose the Shortest Path to Value (SPV) with the goal to solve the problem/issue identified by the customers/end users.
The shorter the time that elapsed from the "please" moment to the "thank you" moment, the higher our rate of success. Customers/end users always appreciate prompt and courteous service, and are glad to recommend same services to their network of friends/family/coworkers.