Building Maintainable PHP Applications: Context
This article is part of the Building Maintainable PHP Applications series
Building software products and writing code depends heavily on the context that you are in.
For example, there are multiple types of product contexts that I can think of:
Brand Website development
Package Development
Small bootstrapped startup development
A well-funded startup development
A scale-up development
Enterprise development
and many more
All of these have different sets of problems and challenges that people have to deal with and almost always the situation is unique and the developers won’t benefit from similar solutions until they get to the point where they do.
Someone who builds a small bootstrapped business with 2-3 developers on the team, won’t be at the same scale code-wise as someone who’s part of a team of 20+ people building a scale-up. Same goes for enterprise with 100s of developers.
People who work in different contexts have something in common which is the code that they write will become hard to work with at some point, it may take a few years but it does become a reality if the project survives long enough.
This is where experience plays a huge role in terms of seeing different types of code related problems that will help you predict the future.
Simple in one context means complex in another one.
The main context that I will focus on in this article series is:
startups after 3 years in production
scale-ups
and enterprise distributed systems
The main reason is that these products are already established in terms of features, customers and their business is explored enough to the point where they have enough complexity to deal with on a daily basis.
The context you are in changes the way you write code or the way you have to write code in order to maintain the codebase for the long term. Simply building an enterprise product with an MVP mindset won’t be helpful.
Technically, you can do that but changing code later on without rewriting the whole thing won’t be easy and it will decrease the development time for simple bugs as well as new features and it will increase the chances of introducing bugs.
When I started my career, I didn’t understand what the context of some people was and why they were saying stuff like “If you are going to build the product this way, you’ll be in trouble”. I’ve also got into trouble while using tutorial code which was not appropriate for the context and the complexity of the project that I was working on.
If you work on a single product long enough, at least 2 or 3 years, you will start noticing how the context changes and how one approach at the start was great but now that the business processes and rules changed over time, that same approach won’t be useful anymore.