Financial Engineering Blog

An important aspect of maintaining software is our ability to explain exactly how and why it solves a problem. Consider this way of introducing a developer to a new piece of software: “When you do Y, it’s a problem how to do X. This software attempts to help with doing X by doing Z. This works well because Z has the following advantages: a, b and c and some disadvantages: q, r, s. If those trade-offs are appropriate for your domain consider using this piece of software.” I consider this a Gold Standard for introduction to the point of a library or application. It explains why it exists, what it does and when to use it. Following such an introduction, we need to offer a deeper dive into the software with the goal of making one fully proficient in using it. I propose the following setup for documenting each project: Introduction: Gentle introduction to main concepts Getting started: Installation: setup steps to install software Testing your setup: how to test your setup works as expecte...

90% of application domain development is deciding what are nouns and verbs of the solution (do not believe this number). Nouns are the state applications will ingest and produce. Verbs are actions the app will take to achieve this. Designing a CLI forces us to answer those questions. We can decide what language the application domain actually speaks. This is an invaluable property when explaining how an application works to your colleagues. It helps to improve application maintainability by providing a simple interface to use. It also prepares us for designing an API around the application if it's ever needed. There are repeatable patterns in design of CLI applications that are not about solving problems in the application domain. We can call those aspects “infrastructure of CLI applications”. Common elements are: Layout of application source files and various coding conventions. Managing state with Resources: CRUD operations can be applied to Resources and the application specifie...

We now know what we need in place to build software products. We can now ask a question: how should we build it? If there’s one rule I can confidently vouch for is this one: do it simply. Simple is not easy though. Simple is in fact very hard. But it is very worth it to enforce it. Recall the trouble of building a product: requirements change, new features need to be added, bugs need to be fixed, existing features need to be improved. In this chaos there needs to be some sanity. One principle I come back to again and again is I want the software to be simple. I want it to be dead boring and predictable. I groan when I see complicated code. Code is not a product, it is a liability. Do what is needed. Best part is no part. Do one thing at a time. Doing it in a shorter way is usually better than a longer way. Do it in a way that you can explain easily. Do it with fewer pieces. Do it by not sharing state. Do it in stages. That list goes on and contains lots of facets based on one’s exper...

As we now know , building products in a problem domain is difficult. We also know we will be working in that problem domain for a long time. It makes sense then to build a tool that allows us to build and maintain products easily. This is what collectively has been called in software as having a “CICD” stack. Surprisingly, lots of companies are not obsessed enough with its importance. They may think of it as a nice-to-have, second-hand infrastructure. Obsessions in software are rarely a mark of good engineering. However, if I had to make a bet on one thing worth obsessing about it’s the CICD stack. This is because a software company is essentially a huge factory of product updates guided by immersion in the customer's problem domain. Products are difficult to make, so they will need lots of fixes and enhancements that we will need to be delivered to users. Making products is also an inherently iterative process, so we can’t plan and deliver all features in one go. We will need to ...

I once read that companies should define themselves as solving (or living and breathing) a problem domain rather than as offering a product. The article gave an example of Amazon as a company in the problem space of how to deliver products to customers fast and cheap. This means Amazon is not a website defined by the current iteration of the process-technology curve. It means the company’s essence is in solving a real human problem. The problem domain should have a character of being timeless, which means it’s worth the effort. This perspective gives us a lens to sympathize with the customer and to focus on solving their problems. It also highlights to not obsess over product as the end goal of the company. Of course it remains the case that customers interact with companies through their products and the only way to influence customer experience is to perfect the product. But building products is hard, time-consuming and layered with traps of judgment and direction. It’s much more pru...