The programmer's checklist for making technical decisions that maximize revenue and minimize costs
WHAT'S THIS?
This is an interactive tool to help software engineers in identifying and estimating the financial consequences of their technical decisions.
It's also an educational material detailing how the creation and delivery of a software product generates revenue and costs, in detail, from the ground up.
Please keep in mind this is also a work-in-progress. What you currently see is more like a prototype than a finished product.
Engineers are hired to create business value, not to program things: ... Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.
I spent my last 2 years with identifying the exact ways how we can do just that. (Insipred by other reasons.) I wanted to share the gist of it with everyone for free. This "Code To Money Roadmap" contains the essence of my book Full Context Software Development to help every software engineer with:
understanding exactly how our work influences revenue and costs
evaluating our technical decision in the light of their financial consequences
I believe a programmer-focused, practical and complete overview of this topic has never been done before.
HOW DOES IT WORK?
Usage: The main purpose of this tool is to help you with making tech-decisions. The first step is to identify how things work in your given situation. The chekclists help with doing that without missing anything. Fill out what's relevant for the thing you are evaluating. Second is to identify the impact of the change. The evaluation tool gives structured guidance in how to do that at each stage. Identify the influence of the change over the elements in the checklist with that.
Disclaimer: If you are like me, a lot of these things will feel boring, especially the first 5 stages, you are free to skip any parts. Even when you are using it seriously, most of the stuff won't be relevant, so don't bother with completing everything.
We will follow how money turns into code and then how code turns into money through the extended software development lifecycle. There are two components of the process that need some introduction.
1. The structure of the application: It's very basic stuff. The main components are the following:
You will find 4 different types of explanations at each stage. They describe what is the function of the current step and what are the connection points between it, the financial results and the developers' responsibilities.
The checklist: The practical factors from the given stage that have influence over financial performance and also the technical considerations. Define them to see the full impact of the ideas you are evaluating.
The evaluation tool: Its 2 parts should be used separately. Identify the involved TIPs and the currencies. It's a good idea to include the explanation of how/why they are relevant.
The business impact graph: The somewhat simplified, visual representation of how the currencies turn into financial results. It's live updated with the points you assign.
The total score: As you go around and gather currencies you will be able to see a summary of the total score here. Toggle it by hovering/tapping on the small bar at the bottom of the screen then on the up/down arrow.
2. The basics of the full context framework: On the highest level it's only concerned with 5 things. In the book I call them the Financial API, here I use the name: the "5 currencies". These are the factors we are trying to "collect" as we walk the code-to-money road that we can "exchange" for inceased revenue and reduced costs. This is an all encompassing set, every financial consequence of our actions can be derived from them.
Business Opportunity: Anything that has influence over the capability of developing a product or feature that enables the company to do business.
Customer Experience: Anything that will improve the experience of the users at any stage of the customer lifecycle.
Productivity: The efficiency of working which can translate to reduced costs and through faster delivery to improved customer experience and higher revenue.
Utilization: The utilization of all available resources including manpower but also the owned infrastructure, budged and intellectual property.
Direct Costs: Directly affected costs like service fees or purchase of tools, licenses, etc...
TIPs: Or technical impact points. The exact technical factors that will influence the 5 currencies
SQA
Software Quality Attributes: Properties exclusive to software that will affect how much the users are satisfied with the product.
TQA
Tech(nology) Quality Attributes: Properties exclusive to the programming tools we use that will affect how much the users are satisfied with the product.
CQA
Code Quality Attributes: Properties of the codebase we write that will affect how much the users are satisfied with the product.
PQA
Process Quality Attributes: The factors that determine how efficient and effective is our work and consequently the speed and quality of software delivery.
CAPs
Capabilities: The development skills, know-how, software tools and infrastructure necessary to create and operate the product.
Impact Points: An exponential scale of 1, 10, 100, 1000 that signifies the relative impact of some technical property over the elements of the Financial API. Here is the baseline for each value:
1
The most minuscule effect possible, localized to an atomic unit of the domain like a single UI element, a one off anonymous function or a single tasks of a single person. Examples: Changing the color of a button, a minor change in the runtime of a step in an automated process.
10
This is the kind of impact we start to notice in real life. It affects multiple occurrences of an atomic unit, like a reusable UI component, a single class in an OOP codebase or the regular work of an individual. Examples: An improvement to the UX of every Sign Up button in an application, refactoring a method in a frequently used class for better maintainability and understandability, or improving the happiness and motivation of a team member.
100
An impact of this size is something multiple people will recognize and appreciate. We usually strive to create this kind of improvements in our work. It might mean improvements in application wide concerns (speed, security) in one or a few parts of a larger system. In different domains it can affect a substantial group of the complete user base or the performance of a single or a few teams in a large organization. Examples: Subsystem scale refactoring, team level adoption of new technologies or best practices, improving accessibility or offering the service in a new country.
1000
This type of impact operates on the highest level of the domain. The whole codebase, the whole user base or the entire organization. Creating this kind of change is a major undertaking and can deliver business results completely changing the course of a company (or a quarterly result). Examples: A complete UI overhaul or other UX improvement affecting every customer. A major restructuring of an organizational level process for improved efficiency. Moving a whole system from a legacy platform to the cloud.
If you want to learn more details check out the book or some of my tech reviews where I use this approach in practice.
An unfilled user or organizational need or a significant improvement over an existing solution
A profitable and sustainable way to monetize the solution to that problem
A viable method to build, market, maintain and iterate on the solution
Validation of the above points
SUMMARY:
This is the foundation of any product, feature or other business improvements. In the end, it will turn into a set of functional and non-functional requirements and at least a vague plan about every other stage that follows.
DOMAIN SPECIFIC: The customers' problems, needs and goals
DOMAIN SPECIFIC: How to solve their problems, the way to serve their needs and the means to help them reach their goals, in real-life terms
DOMAIN SPECIFIC: The market conditions & trends the product is/would be competing on
GENERIC AND SPECIFIC: How to promote and sell the software product to the target audience
GENERIC AND SPECIFIC: The technical knowledge needed to create a software solution
The business domain and the current market trends will decide much of which SQAs are needed in order to create a successful product.
A nuclear power plant control system needs real-time processing, verifiable correctness and extreme fault-tolerance but for example startup or update times can be as long as necessary.
A high-traffic webshop however needs close to instant loading time and a fast deployment process but nowhere near the verifiable correctness of such a critical system.
These already filter out which tools and what kind of system architectures are feasible for a given product type.
Revenue
Who are your users? What do they want? How can you help them?
Costs
What are roughly the costs of the needed software development capabilities? What's the expected ROI on the project?
The following currencies are convertible at the next 2 steps:
You can improve the financial results by minimizing the money needed to produce the software without compromising on functionality, quality, speed of delivery or in general the profit.
That includes using the right programming tools, system architecture and infrastructure so you can achieve customer satisfaction in the most efficient and cost effective manner.
Everything up till implementation is about identifying what are the required quality attributes to satisfy the customers and finding the tools that deliver them with the lowest cost.
This also involves setting up the work processes in a way that enables shipping the software with minimal wage and operational costs.
