So now that you guys know about technical financing and technical capital, it’ll be a bit easier to talk about technical interest rates and loans.
It sounds like a really complicated idea, but it’s really not. So please hang on and learn this because I promise it’ll be helpful.
While this blog post is able to be read on its own without any prior knowledge, it is a part of our Lessons in Factorio series, so if this is your first time reading one of this series’ blog posts, I recommend starting from the first one and working your way through them. The first post can be found here: Why I Learned from Factorio: Lean Networking
Notice: We ran out of networking memes this week, so you get pictures of our office kitten. Everyone loves kittens!
Technical Payments – Paying Capital vs Interest
To start, let’s go over what a technical payment looks like.
A technical payment is any work required to pay down the technical debt. Some of these payments go directly to the technical capital, while others simply pay off the technical interest.
Let’s look at lack of documentation as an example:
- Technical Principal – Simply making the documentation is a direct payment to the technical Principal.
- Technical Interest – When I put off documentation for too long, I’ll forget how the system works, so it’ll take me longer to make the documentation than if I just did it immediately afterwards. That extra time spent is one manifestation of technical interest.
Generating Technical Interest
Some forms of technical debt accumulate more interest than others. If something were very likely to cause an outage, for example, it might be described as a high interest technical loan.
On the other hand, if it’s unlikely to cause problems until several years down the road, and even then it’ll just be a minor headache, that can be considered a low or no interest technical loan.
Technical Payment Schedule
The last factor to consider is the payment schedule. Some forms of technical debt demand payments more frequently than others.
There are times where you can go a while without paying to the capital at all and you’re able to simply let the interest accumulate. There are other times where your environment extracts an interest payment from your team. Keep in mind the environment doesn’t collect payments on a regular schedule, either.
Using the same example as above, something that is likely to cause a lot of outages has a high interest and high payment frequency for technical debt.
Something that is unlikely to cause issues is a technical loan that you can pay off at your own leisure.
Now that you’re aware of how interest rates, payment schedules and capital vs interest, you can now take out a loan responsibly. Just like Financial capital, earlier on, the best advice is to avoid a loan altogether. As you mature and become better with your money, you can take loans responsibly.
Of course, if you can, just like finances, it’s best to pay things off in full if you can afford it. With things such as a house or car, it’s not always possible to buy it upfront in cash. When you have a smaller IT team with less technical capital, you have to take out a technical loan if you’re ever going to complete a large capital project in any reasonable amount of time.
Just knowing the impact of how technical debt can effect you can really make the difference. When people say to avoid technical debt at all costs, that’s mostly applicable to those who were previously taking out technical loans without realizing it.
Raising Technical Capital
During crunch time, or just for the sake of delivering value as soon as possible, you can intentionally take out a tech loan to create a lot of technical capital very quickly.
Hopefully I’m not losing you with my technical financing analogy. You can intentionally take on tech debt to finish a project sooner, allowing you to see the benefits of a project earlier. This isn’t spoken about explicitly very often, but the Minimum Viable Product (MVP) is an example of this. When you ship the MVP, you’re intentionally taking on technical debt, so that you can enjoy the benefits of a project being done, without needing to complete all of the work required.
If that doesn’t make sense, you can read about my Shipping the MVP in Factorio article here.
A lot of these concepts intuitively make sense to any engineer that I’ve discussed this with. Hopefully it’s the same for you and it feels like I’m just telling you things you already know, but didn’t really have the vocabulary to discuss.
Now that I’ve brought these things to your attention, you probably have some ideas of how to do some technical financing yourself. If not, this is an IT and Factorio blog, and I think I owe you guys some examples.
Example Data Center Build
When building out the data center and moving everything over, we made an effort to document any technical debt we’ve intentionally taken on so that the interest rate and overall capital payment to pay it off was lower. Examples of this are:
Using NATs to avoid having to change any IPs on the application side
This was really messy and not a preferred solution. We understood that it made the environment more complicated than it needed to be. It would also be difficult to untangle when it came time to undo it.
We weren’t very proud of this decision, but we were in a time crunch and we needed to save all the time we could. Using the NATs saved us the trouble of having to work with the application team to find any IPs or hostnames in their scripts and configurations. It would have taken them a long time to do it, and it would have been outside of my team’s control to make it move faster if we went with that route. We moved forward with the NATs as a result.
To help lower the technical interest rate, we documented it as we were doing it. Almost a technical IOU, lol.
To do this we used our project management tool (Jira) to make a task with notes on exactly what we needed to do so that it wouldn’t be difficult to pick up that task at a later time. This included:
- What the NAT was for
- Why it was necessary
- Any steps we were aware of that were needed to resolve it.
- Applications and systems involved in the NAT.
Single internet circuit
When we built the data center, we only had one circuit at the site. We knew this would be a problem down the road, but we needed to move fast. There was pretty much a 100% chance that this would eventually cause an outage in the future, but us waiting 3+ months for the next circuit wasn’t really an option.
We gambled having to pay that technical interest in exchange for the capital we’ve gained to finish sooner and be able to focus on other tasks. We were fortunate to not face any outages after we moved critical services over until we got the second circuit up.
There was one small interest payment that we ended up paying. Having to get the organization to be ok with an ISP failover test was tough. It definitely would have been a lot easier to do if I was able to do it before the site was in production.
One way we did lower the technical interest was making the stakeholders aware of the situation and the risks we were taking beforehand. Since they were aware of the situation and the costs and benefits of our decision, if there were any issues, the conversation would be more about how we were right, not about how we didn’t have a handle on our systems.
Early on in the game, you need to have a single belt with coal on one side and ore on the other. This is necessary because you don’t have the red inserters that can grab from an extra block away so you can have dedicated belts.
The early game electrical poles only have enough range to power one side of the smelters too, so it’s necessary to place poles on both sides of the smelter. Assuming you have everything next to each other, you only have enough room for an inserter on each side.
Later on, when you decide to start running 2 belts so that coal and iron have their own dedicated lanes, all of this becomes a pain to undo. Knowing that these actions will later manifest into a form of technical debt, I usually try to just build on one side of the belt, so that it becomes easier to expand it later. This effectively lowers the amount of interest I accumulate to pay down later.
We usually do this and it’s atrocious. It’s hilarious when we refactor the base and later on we trace the coal belt to find it going up and down for seemingly no reason. This happens because coal is needed in a lot of random places, in relatively small amounts. As a result, a single belt of coal is usually enough. Instead of bringing it’s a belt over from the main bus, sometimes it’s a lot easier to just extend a coal belt from somewhere else.
It doesn’t really cause any problems though, so the technical interest is very minimal. We pretty much consider to be an interest free, pay-when-you-feel-like-it technical loan.
Using the concepts of technical interest and technical loans, I was able to make my life easier in both the network engineering world as well as in Factorio. If you are able to take the time to learn and practice these concepts, I’m positive you can use them to your benefit as well in a lot of your endeavors.
Thank you for checking this out. I hope you learned something new or enjoyed reading this. If you had any comments, questions, or just wanted to share your thoughts on this article, you can contact me at firstname.lastname@example.org
e-Mayhem helps companies successfully deliver business projects. We also help companies avoid losses associated with IT disruptions and security threats. You can learn more about our services at e-mayhem.com or by emailing email@example.com