editione1.0.1
Updated August 7, 2023Think about your typical customer for a minute. When a customer buys your product or service, they’re looking to solve a specific need, whether that’s to save time or money, perform a difficult task, automate something, or even provide entertainment value. What they care about the most is that their needs are met by your product—that’s what makes your product valuable to them.
What they almost never care about is how your product is built. They don’t care what language you used or what data structures, algorithms, or application architecture you chose for your codebase. They may not even care about all the features that are available in your product. What they do care about is that your product solves their pain points, which is why it’s important to focus on the customer when writing software. Sometimes using a new framework or using fancy data structures is fun, but that doesn’t always add value for your customers. Solving a customer’s problems always adds value.
exampleHere are some good questions that will help you focus on your customers:
How am I adding value for the customer right now?
Which customers, if any, are requesting this feature?
Which customers are affected by this bug that I’m fixing?
Is this feature a must-have requirement before customer ABC signs the contract?
If you ask yourself these questions regularly as you work on new features and projects, you’ll build a better understanding of how your work adds value for the customer. You’ll get a better idea of which tasks are important and which are lower priority. Sure, there may be some tech debt in a part of the codebase that’s been bugging you for a while, but if fixing it doesn’t add any value for the customer then maybe you should focus on something else that does. If you’re adding value for the customer, you’re adding value for your company, and in the end, that’s all that matters.
It’s satisfying to see your code in the hands of customers and providing them value, especially when they pay for your product. It’s even more fulfilling to write code that has a high impact, especially when it comes to helping your business grow. If you’re lucky, the code you write may become necessary to the success of the business, at which point it becomes business critical.
Business-critical code is typically complex because it’s required to handle multiple use cases for many different customers. The complexity grows over time as new use cases are discovered and new customers are supported. However, business-critical code doesn’t necessarily equate to state-of-the-art code. Surprisingly, the most profitable code is sometimes rather outdated and boring. The most important part is that the code works, is reliable, gets the job done, and is in the hands of the customer.
All business-critical code becomes legacy code over time. It’s just a fact. When you have a codebase that’s necessary to the success of the business, making changes to the code can be risky if not planned carefully. Small improvements add up over time, but you probably won’t be refactoring half the codebase to a new architecture. As they say, “If it ain’t broke, don’t fix it.”