Applying software engineering principles to your business
Practical tips to engineer business success
I work as a software developer. I revel in the whole process of geeking out with ideas, continuously learning technology and creating innovative solutions for people. I have to admit that on some days I feel like banging my head against the wall. Most of the time though, it feels like I am getting paid to have fun.
I am also a compulsive side-hustler, for various reasons. Mainly, because I can do whatever the hell I want and I get to see my ideas play out in the real world. I’m avoiding the word “entrepreneur” intentionally because it has been milked to death.
In software development, there are a bunch of common principles that are applied throughout the industry. I have come to notice that some of these principles can be transferred to running businesses. Employing them to my side-hustles has helped me gain clarity, simplification, and efficiency.
YAGNI (You ain’t gonna need it)
When we code software, it makes sense to look ahead into the future. We do this to anticipate problems and to make sure that our current tasks are in line with the bigger picture.
If taken too far, there is a tendency to implement features in anticipation of a future need. The disadvantages of doing this are:
- we invest effort into something that is potentially not used in the future
- we add unnecessary complexity to the product, making it harder to maintain
The key here is to implement something when the actual need arises. The principle sounds simple, yet we need a certain amount of restraint to adhere to it.
The “you ain’t gonna need it” principle translates beautifully into the world of self-employment. It is easy to fall into the trap of doing something because we think we need it in the future.
If we are at the very beginning of our dog sitting business, do we absolutely need to spend 50 hours finding the best online shop to print those cute business cards with Chihuahuas logos on them?
What if we decide to pivot our business into cat sitting instead? The business cards with Chihuahua logos would become obsolete. Maybe it would be wiser to spend our time acquiring customers instead.
When we are self-employed, we are 100% responsible for our resources, mainly time, money and attention. One way to ensure efficient use of our resources is to execute tasks only when absolutely necessary.
DRY(Don’t repeat yourself)
When coding a new feature in a software product, it is tempting to copy and paste the code from another part of the product, if the same functionality already exists.
Repeating the same or similar code is a big no-no in the software world.
If the code worked before, what's the harm in copy and pasting it? The problem here is that it makes the software harder to maintain.
If we discover an issue with the code, we need to fix the same code in all those places that we pasted them to. If we forget to fix just one of those places, the software is still broken. Another major issue is that the software gets unnecessarily bloated because there is simply more code in the system.
The solution here is to write the code only once. We then reuse the code in various parts that need the functionality. When we discover an issue, it needs to be fixed only once. We might have to do some changes to the code so it is generic enough to fulfill the needs of those various parts.
Obviously, this takes more effort than simply pressing Ctrl-C and Ctrl-P on the keyboard. It might seem like a hassle. However, the investment pays off because of reduced maintenance costs in the long run.
In business, we can apply the same “don’t repeat yourself” principle to the operational tasks. For example, if we are currently writing similar emails to multiple customers, we can consider using mail templates.
A quick way to figure out where we repeat ourselves is to keep a journal of our daily activities. It is vital that we identify where we are repeating ourselves, to avoid creating solutions to a problem that we do not have.
This principle can be particularly beneficial if we have multiple businesses. We can identify and consolidate the common parts of those businesses.
For example, if we have started multiple web shops on different e-commerce platforms, it would make sense to consolidate them onto the same platform. We can figure out a common marketing funnel that can be adapted slightly to meet the needs of those individual businesses.
The advantage here is analogous to the software world, we only need to update the solution once, rather than for each individual business.
Test, test, test
Testing is a crucial part of software development. Tests are there to catch errors in the code. Some of these errors are caused by unintentional human mistakes, others are caused by wrong assumptions.
When a developer writes code, it is common practice to also write the test code. The test code checks the production code to determine if it behaves the way it should. The test code can check various aspects, for example, if the results provided by a calculation is correct, or if the code executes within the specified time duration.
“Continuous integration” is a common practice in software engineering. The goal of this practice is to ensure the changes provided by individual developers do not break the product as a whole. When a developer makes a change to the code, this change gets automatically integrated into the product. The test system then checks the product to make sure it continues to behave as specified.
Why do software developers care so much about testing? They do that to discover and fix bugs as early as possible. When a bug that is left undiscovered, other parts of the software will be built upon it. Fixing the bug might require fixing these dependent components as well. It gets even more expensive if the bug causes havoc after it has been shipped to the customer. The earlier a bug is discovered, the cheaper it is to fix.
When we are self-employed, every critical decision rests on our shoulders. Some decisions are based on our assumptions. Wrong assumptions will cause detrimental business results.
We can reduce the damage caused by wrong assumptions by testing them before investing further into the trajectory of that particular decision. Just like in software, if we make further assumptions and decisions based on the previous erroneous assumption, it would be more expensive to fix.
Ideally, we invest as little as possible in a certain direction before we test. We test as early as possible. It is also important to test an assumption before making other decisions based on it.
For example, if we want to create a business around teaching photography, we can first focus on testing the concept with one client. Working with that first client, we can iron out the kinks of the coaching process and the content of our material.
This approach would be wiser than investing time and money into acquiring 20 clients for a workshop and later finding out that our training program sucks. If we make a mistake with 1 client, it would make a less negative impact that making the same messing up with 20 clients simultaneously. If we also plan to offer an advanced workshop based on the first workshop, it would make sense to defer making any investments that direction before we have tested the first workshop.
Testing by selling is more effective than other forms of market research, such as asking for opinions or doing questionnaires. Opinions from clients who vote with their wallet carry more weight than from those who vote with their mouths.
Focus on the feature, not the components
A software product commonly consists of multiple technical components. When we add a feature to the product, the relevant components need to be modified accordingly. Because of its technical nature, sometimes, the focus is wrongly placed on components rather than the features.
Up until around the early 2000s, developers are organized into so-called component teams. Each component in the product is assigned to a dedicated component team. Members of the team are experts in that one component. When features need to be created, the specification is broken down into the relevance to the components.
The current trend is group developers into feature teams instead of component teams. These teams are assigned features to implement. They modify every necessary component to deliver the features.
Features are defined from an end-to-end perspective in terms of how it provides value to the user. A feature is usually defined as one or more “user stories”. User stories are specified from the point of view of an end-user. An example of a user story would be “As an HR employee I would like to view new job applications in my tool so that I can review them”.
Some benefits of switching from component teams to feature teams are:
- teams are more focused on delivering complete features rather than fulfilling technical specifications for individual components
- teams have cross-functional and cross-component knowledge
- less coordination, prioritization and integration efforts between teams
We can see our business as an accumulation of components. For example, if we are running a dog sitting business, we can break it down into the following components:
- marketing(in-person contact, online ads, social media, website)
- transport(getting to your client, transporting animals)
- infrastructure(dog kennels to keep animals overnight)
- bookkeeping(invoicing, recording payment, tax)
We can adopt the feature-team mindset, even if it is a one-person team. By focusing on specific features, we concentrate on working on the components needed for the feature. We do not have to master any one component, we just need to know enough to deliver the feature.
Let us assume that we are working on the user story “As a dog owner, I would like my dog taken care of for 2 hours so that I can go shopping”.
For that user story, our work needed with regard the components are:
- marketing — get in touch with local dog owners
- transport — a bicycle will suffice to go around the neighborhood. No need for an animal transport vehicle.
- infrastructure — none needed, since we do not provide overnight care
- bookkeeping — print receipt, payment by cash. No online payment needed
By focusing on just what is needed for the feature at hand, we can shorten our “go to market” time. We can provide value to local dog owners that are looking for short-duration dog care while ignoring other features for the time being.
If we were to work on the components without focusing on the features, we run the risk of working in an arbitrary order or working sequentially on components. We would not be able to provide a useful feature to the customer as fast as if we were feature-driven.
Having the discipline to be feature-driven has the added advantage of reducing wasted effort, in case we decide to pivot the business. For instance, if we would have built the dog kennels in the beginning and later decide that we want to focus on short-duration daycare, it would have been a wasted investment.
The key lesson here is to focus on the experience we want to deliver to the customer as a whole, rather than work on individual parts of our business.
Working with principles
Principles are comparables to tools on our utility belt. Before we can utilize them, we need to first understand them. Experience from practice will then help us know which ones to employ. We can only get better at applying those principles, perfection does not exist.
Now, let’s hammer out the next step in our business.