Rules of thumb for small web software companies

2024-02-13

I have worked in a few start ups now and I have a few ‘rules’ (more like guidelines) that I think would help engineering teams in the long run. The following list is a generalizations of my own experiences at start up companies, perhaps they dont apply to your situation or your company but this is what I have seen and recommend:

One Programming Language

Try to limit your tech stack or the number of programming languages. For companies like google it makes sense to have multiple supported languages but in a small to mid size company it makes a bunch of things much harder. Having multiple languages forces you to cross train engineers for both languages, makes it harder to switch engineers onto new projects, twice as much dev ops work, logging work, etc.

Lean Towards Maintainability

There is a balance between getting out something quick and getting out something maintainable and the Facebook motto is ‘move fast and break things’ but I think that after you have some customers you really need to refactor and add quality to the codebase. Having wonky code is like a slow drain on productivity and so the longer you kick it down the road the more time is sucks from you. Having tech debt for a month is not too bad, a year is a drain, and multiple years is a slow death.

Assume Some Turnover

As a manager at a mid size company I think it is safe to assume that people are going to leave. Even with the best culture, high salaries, and awesome perks, engineers will leave at a reasonable rate and you need to be able to source talent, interview, rehire, onboard, and ramp engineers. Focusing on this process is more important than you think and aside from making engineer happy and trying to retain them in the first place, this might be the second most important process in the company.

Be Mindful of Complexity

There is always complexity, be aware of where it lives and how it interacts with the rest of the system.

80% / 20% Rule For Projects

I think the Pareto Principle (https://en.wikipedia.org/wiki/Pareto_principle) can be applied that 80% of the utility comes from 20% of the work and the rest of the 20% of the utility comes from the remaining 80% of the work. So I would argue focus very heavily on the 80% and never worry about the 20%. There are cases when you need to do 100%, like if you are building rockets or handling money transfers, those should never fail, but for the majority of the web apps that are built a strong 80% will do the job nicely.

Data Design

Data design should be given the most thought because data storage and structure is the hardest to change. It is much easier to change the application layer or front end framework, but refactoring Postgres tables is really challenging especially on a running application so I recommend taking care with data.

Tech Debt is often ignored by non-engineers

Finally, when working with other teams, product, sales, marketing, or upper management they often dont care or are dismissive of tech debt. So it is up to the engineers to make time to free themselves from the crushing weight of tech debt because no one else will advocate for it.