A Changing System is A Good System

A Changing System is A Good System

When it comes to programming infrastructures, I’ve witnessed those of the mentality that “you build it once the right way” and, therefore, will be able to scale and grow accordingly. However, I have a good few years of experience in startups, and chasing the perfect system for your small user base is often more expensive and can impede a product’s production before its release.

Needs Will Change

It’s nearly impossible to create an all-inclusive idea for a project; there will always be things that throw wrenches in the coding process. Whether it be hardware constraints, pivoting goals, or the technology’s limitations. An in-depth knowledge of one’s field could limit the surprises, but I’ve seen a complete idea be presented to a focus group, only for them to send us back to the drawing board because something we still needed to consider was missing. It’s essential when planning development to try and consider all of these things from the beginning, but time will always present new needs.

Build Scale-able Systems But Don’t Overshoot

Web services from Amazon, Microsoft, Google, etc., are great tools for startups due to no need for on-site hardware and minimal server engineering; in addition, serverless options allow for easy and rapid growth.

That being said, many medium to large-scale companies are switching to either hosted servers or in-house servers because of the money they could save if each API call didn’t come with a price tag. However, for most, that is not you. Startups have very volatile traffic, either a ton or none at all, so while on paper it is more expensive, serverless is an excellent option for new companies. That’s not to say that startups should choose serverless and ride it out forever as Bezos intended, but instead, start with serverless and then migrate to servers (in-house or in the cloud) once a more predictable and steady traffic flow is present.

Chasing Perfect Blinds Us From Good

When starting a project, the world is your oyster. Anything is possible, and starting from square one, you can plan it right and avoid any clunky old code present in older companies. You will do it right the whole way through and nothing will ever bottleneck … right? Some people code with a good enough attitude. Yet, it’s that good enough attitude that moves projects forward—as opposed to the starry-eyed perfectionist who refuse to move on until their process is perfect. I’m not saying sweeping potentially scuffed code under the rug should be standard practice, but I am saying that perfectly adequate code is sometimes deemed unacceptable because it does not follow the flawless coding standards enforced by the incredulous goals of the perfectionist.

In Conclusion

Cautious coding can be good for system stability, but it’s important in the fast-paced market startups live in to write good code without getting hung up on details. A dev team needs to be able to plan the needs of the product but also intentionally create wiggle room in the schedule for new needs and unplanned limitations. It’s also essential to build systems that are scale-able and future thinking, but not 25 years into the future when the company will want to free itself from the shackles of cloud computing. Sometimes, when building a system, a little bit of shortsightedness goes a long way.