Shipping the MVP in Networking

Shipping the MVP in Networking

Shipping the MVP (Minimum Viable Product) is a concept from software development. This means finding the minimum requirements to get an application working and sending it.

In this run-through, I learned about making things good enough instead of perfect. I always thought the concept of shipping the MVP (Minimum Viable Product) didn’t really translate to network engineering. After all, the cost of doing things incorrectly was a lot higher in network engineering.

These are a few challenges presented in that aren’t present in software dev:

• Having to work with hardware that was costly and time consuming to purchase and install
  • Lead times on hardware acquisition
  • Most of the time, the physical install location wouldn’t be anywhere near me
• With most of the devices we’re working with, there’s no easy way to upgrade the capacity of capabilities of a device aside from a rip and replace
• Having to deal with the limitations of the existing cabling because the cost of running new cables/drops would be too hard to justify
  • Being unable to run new drops for the wireless access points to improve the WiFi
  • Slower uplinks or a limited number of them between IDFs

Generally, the cost of doing this incorrectly the first time seemed to be a lot higher than software development. At this point, I had also learned about technical debt. I figured I would do the perfect run-through. No technical debt! Everything would just be done perfectly from the start.

In this chapter of my Lessons in Factorio series, you’ll get to follow along as I get to learn how wrong I was.
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

My Thoughts Before This Factorio Run

I take pride in my work. Like most engineers, I enjoy building and creating things. It feels great to look back on the things I’ve previously built that were well designed and are still in use. Shipping the MVP seemed so contrary to that.

r/networkingmemes – This is not the core you are looking for.

Prior to this run-through, and still a bit to this day, there are certain things I’ve had to build under constraints that didn’t allow me to build it as well as I wanted to. When others look at this work and ask why it’s that way, I’m a bit embarrassed to answer and explain.

I figured that businesses and management didn’t really know what we’re doing and most of the time just got in the way of doing a good job. If they just gave me the extra time and budget necessary, I would be taking this company places.

My Hypothesis: Just do everything right the first time and everything will be amazing

Without pesky things like managers, budgets or deadlines to get in my way, I was able to ignore shipping the MVP and focus on building the utopia I desired in my Factorio-lab. I would get to reap the rewards of my well-crafted hard work of doing things the right way the first time. That meant building everything in a well thought out, scalable and secure manner.

I’ve had a couple of Factorio runs under my belt by this point, so I knew what I was doing. There would be no spaghetti base in my factory this time. I wouldn’t have to waste any time rebuilding things, because this time, everything will be done right from the start. It will be glorious, or so I thought.

The End-Result of my Factory

This had to be one of my slowest runs. The end result was clean, but I never realized how much the tools you get sometime after blue science (about halfway through the game) help construct and deconstruct more quickly.

Everything took forever to build until I got to blue science. My base ran out of room very quickly as I had to designate the extra space for scalability. Because my base was so big, it took a long time to just get around, which I was doing more than usual at this point in the game. This was because I was burning through more resources than usual with my future-proof designs.

Since I was building everything so large and by hand, any mistakes I made took even longer to correct. Most of my efforts weren’t actually going towards progressing through the game and instead were being funneled into my “perfect designs.”

Once I finally reached blue science and had construction robots it was smooth sailing, but in hindsight, it was not worth the effort invested.

Lessons Learned: Shipping the MVP

I was ready for this to be the ultimate perfect run. It was a shock to see how poorly it turned out. I did everything correctly, or so I had assumed. In either case, I learned a few things from this run.

Shipping the MVP in Networking works in Certain Situations

My factory didn’t exist to have well crafted solutions. It existed to create science packs, which ultimately progressed me towards the end of the game. This is similar to how the companies I was working for didn’t exist to have fantastic networks, they were there to make money.

There has to be a balance though. If I tried shipping the MVP in networking, I would end up needing to replace hardware in a less than a year as the organization grew. With decisions that have an exceptionally high cost to correct once implemented, additional time should be taken to make sure it’s done right the first time. Other things like configuration, monitoring, and documentation can be started with an MVP and iterated over time.

There is such a thing as too much security and too much scalability

Often times, engineers take pride in being problem solvers and focus too much on the quality of their solutions, ignoring the reason for solving the problem in the first place. Through this play-through, I’ve learned to focus on the problems and the benefits provided by the solutions I’ve created instead.

With this in mind, I just need to build the right amount to get the job done. I should be working to identifying problems and providing solutions to them. Not trying to craft some masterpiece that I can be proud of.

No one is any less of an engineer for creating a weaker design

Everyone has to work within the limitations they have. This can be time, money, knowledge, etc. Usually there’s limitations on all of them. Having to create solutions within these constraints is usually more challenging.

I’ve gained a lot more respect for myself and others’ work. I try not to judge the work of others and give them the benefit of the doubt, especially since I’m not always aware of the constraints and pressures that the solution had to be created under.

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 blog@e-mayhem.com

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 sales@e-mayhem.com