I don't do crazy maths; I don't write new algorithms; I don't implement databases or design programming languages. I don't make video games nor discover new ways of processing data with ML. I don't invent crypto protocols nor do I make shiny UI animations. Really, my code is very dumb.
Yet, I consistently create products of great value. Here is how I do it.
What matters is asking the right questions
Ultimately, I write distributed versions of memcpy: my software either gets some input information, and stores it; alternatively, it receives a request for information, reads it out of storage, and sends it out.
Note that I said "information", and not data – this is crucial. To understand what information the business needs, in contrast to the data it actually processes, I ask a lot of questions:
- what is the information (not the data)?
- what is its purpose (in a business context)?
- who creates it?
- how does it get entered into the system?
- who consumes it?
- how does it get output out of the system?
- what is its lifetime?
- how is that information best encoded into bytes?
- how are these bytes best moved around?
- what part of the business information needs are actually metadata?
A concrete example: a point-of-sale system
Imagine that a user wants to buy a product from the company I work for. This information could be encoded in many different ways: It could be a button press on a POS, it could be a barcode scanned on a mobile app, it could be a checkout button on a webpage, it could be a subscription.
In response, I usually have to process a payment and inform the user that an order was placed. This could be shown on a display, printed out on a receipt, displayed in a web browser, sent as an email. The data and delivery mechanisms are very different, the information is the same.
The business also requires a transaction log. The business needs to know who ordered what, when; it needs to know which inventory got sold by whom, to whom, for which price, at what time. This log will be used to create analytics, drive business insight, and help debug discrepancies.
Answering the questions for the point of sale system
Here is what I think when someone asks me to build such a system:
- do other people need access to this information ( fulfillment, sales, accounting)? How are these people going to access it, and what part of the information do they care about?
- how quickly do stakeholders need to get the information? For example, the customer should get instantaneous feedback, accounting only cares about it once a year.
- what are the different things that can happen in the real world (these are not error conditions as far as the software is concerned)? Can a product be out of stock? Can the credit card transaction be declined? Can the email address be invalid? Can the mobile phone connection die?
- what happens if something in my system goes wrong? Will we want to retry? Notify the customer? Log an error log? Show it in a realtime dashboard? Track it in an issue tracker? Make a note for customer support?
- do other things need to happen once the order is placed? Do we need to update the inventory? Do we need to potentially place a purchase order to replenish the stock? Maybe create a shipping label and send out a tracking number?
None of the code that will answer these questions is going to be interesting. It will be fairly standard APIs backed by a messaging bus, receiving and sending the information out to multiple recipients (log files, databases, message queues, displays, web socket). It will check for errors, validate inputs and sometimes implement a minimum of business logic.
The simpler the path that the information takes to get from A to B, the better the system becomes. Because we asked the right questions, the software is aiming straight for the bull’s eye, solving the actual business problems.
Thoughtful questions, boring software
My software is very boring – but I asked the right questions; that’s why my work has such a profound impact.
Also Published Here