The house I rent right now near Ericeira, Portugal, has terrible plumbing for heating. Very few people care about heating in Portugal because winter here lasts only a few months, and the temperature gets as low as 50 degrees (that’s +10 degrees Celcius). But, inside, it gets pretty chilly too — between 60 and 70 degrees Fahrenheit (up to +20 Celsius), which is pretty much the temperature in California. Add to that the cold ocean winds, and you get some pretty uncomfortable living conditions.
So, the owner likely bought a house and, after a while, realized it gets too cold in the winter to stay comfortably. So, he installed water heating, which required laying pipes from every room to the heating system in the garage. However, the pipes were installed imperfectly. I’m not questioning the choices made, just stating the facts. I’m constantly making controversial choices at work, and I’ve built my house with a fair share of shortcuts.
Long story short, when I had the heating actively running this past winter, one of the pipes started leaking a bit. Luckily, it was during the sunny last days of winter, so after a few days, I just turned off the heating, and the leaking stopped. But it will likely be a big problem again next winter, so I called a plumber to see if he could fix it.
I learned that because of how the pipes were laid, it would require at least a month to deconstruct the wall, disconnect the leaking pipes, install new ones, and seal everything back up. I also learned a lot about questionable decisions made by the company that installed the pipes originally.
This problem is yet to be fully solved. The plumber asked me — why do you have pipes laid out like this? I, in turn, would probably take this question to the landlord, and he might ask the company that did the original pipe installation. I’m pretty sure the story we’d hear would be something like: Well, you had the house built without accounting for the pipes, and you wanted the cheapest, quickest solution, so we installed the pipes in this manner. We told you then that there was a good chance they would start leaking in 15 years and that you’d have to renovate half the house when that happened. But you chose to have potential problems in the future instead of spending more time and money upfront. And they would be right; I highly doubt a reputable plumbing company just decided to take shortcuts here, although anything is possible.
An example: Why Material UI Doesn’t Work for Us for Long-Term Projects
Why don’t we use material design in our projects? This question struck me when I first heard it because, indeed, why don’t we? Material Design is a popular and robust UI and CSS framework that works well for web and mobile apps.
The short answer is that we avoid using Material Design for long-term projects that we know will evolve over many years. This doesn’t mean Material Design is inherently bad or shouldn’t be used — far from it. If that were the case, it wouldn’t be so widely adopted. Material Design is great for rapid prototyping and launching apps quickly. It saves UI designers and frontend developers tons of time. Users are already familiar with this UI thanks to Google and love it. From a business perspective, it also makes sense — finding designers and developers familiar with Material Design is easy. However, over the long run, it becomes limiting. You can’t build something like Notion or Airtable with Material Design. The framework itself restricts innovation.
This isn’t only true of Material Design but of many frameworks — whether UI kits, CSS libraries, React frontends, or Apollo backends. Each has strengths but also limitations. As CTO, my job, along with our tech and design leads, is to deeply understand these tradeoffs and select the right tools for a given product. This doesn’t mean all frameworks are bad — far from it. We live by the DRY principle and leverage frameworks extensively. For example, we happily use React and Apollo (although Apollo has some quirks, so we occasionally use Express instead).
The challenges compound over time. It’s not just about updating designs and CSS with the framework’s evolution. Material Design’s components are also quite constrained. If you want to add custom forms, you’ll inevitably need to build bespoke components, working around the core library on both the UI and CSS sides. The more customization you add, the harder it becomes to maintain as the framework changes.
The Difference in Planning Horizon
We are building an internal CRM system, and it’s a big project. We knew it would take years to implement everything according to the roadmap when we were starting it. Projects like that are not something you read about online. Most advice is relevant for smaller software products that can and should be built in just a few months. That’s what Material UI is perfect for. But the decision process is slightly different for projects you know will survive the 5-year mark.
There’s a term called planning horizon. If you don’t know if your startup will survive this year, your planning horizon is basically your cash runway, if you’re operating on investors’ money or your own savings, or an amount of time, you can sustain having a day job and working on your project in the evenings and on weekends. One way or another, it’s a limited amount of time, and that’s how you make choices.
When your planning horizon is six months, you choose Material UI over anything else because it gives you an excellent UI framework, and you can have virtually any designer create a UI for you from components that are tried and tested. It can be a super-experienced full-time employee or an inexperienced freelancer. The result will be very similar for the most part.
MUI also comes with a decent CSS framework, which you can hand off to almost any frontend or full-stack engineer, and he will create nearly pixel-perfect interfaces based on it. You will save time and money, and hiring people to do this job or do it yourself would be dead simple.
Pair it with something like Google’s Firebase on the backend or no-code tools like Xano, where you can spin a backend in minutes, and you’ve got yourself an app in a very short time — now you can start validating your idea, doing customer development and so on.
In contrast, it’s a totally different story when you’re starting a big project where the planning horizon is a decade. For example, imagine that you’re building an app for McDonalds. Chances are that they’re not going out of business in the next ten years; most likely, our grand-grandkids will be as excited to get a happymeal as we were when we were kids. The details of the enormous software suite you will be building in the next ten years will likely be vague because no one can write requirements for this amount of work. But there’s a general understanding of the direction, a yearly budget, and armed with an iterative approach and OKRs.
However, it makes little sense to use MUI in this long-term case. An application like that would go beyond MUI’s standard components in the next 12 months. After three years, you will deal with a legacy project — four years ago, MUI 5.0.0 was in the alpha state, and MUI 3 was still widely used. In fact, MUI 1.0.0 was out of the alpha state just six years ago. Who knows, maybe in three years, Google will stop maintaining the project, and it’s unclear what will happen to it after that point.
The Feeling of Having Your Choices Questioned
It’s an interesting feeling when someone questions your choices. It can make you rethink your decisions, which is often good. But there are rarely perfect choices in tech these days — or anything in life. You decide and deal with the consequences, whether good or bad. The same goes for design and CSS frameworks — each approach has pros and cons.
In some ways, we engineers are like plumbers. Whenever I call a plumber for help, he criticizes the previous work, saying the last guy made terrible choices. But then the next plumber comes and says the same thing. This happens every time someone looks over a software project made by someone else — there are always comments about the tech stack and design decisions.
However, take this kind of criticism with a grain of salt. Most of the time, the person questioning the choices doesn’t know the full context and reasoning behind decisions made long ago. Only the original creator fully understands the past circumstances.
Originally published on Medium.com
