choong pw

Let’s talk about frugal engineering. This is something that I have been unconsciously doing without knowing that it is a thing. Nevertheless, this mindset has helped me to be where I am today. Without realizing it, it helped me to think outside the box and look for different options to get things done. Is the outcome that matters.

The theory

Frugal engineering is a design philosophy that focuses on creating products or services that are highly functional, affordable, and resource-efficient. It involves stripping away unnecessary features and complexities while maintaining essential performance. This approach is often associated with innovation in developing countries, where limited resources and economic constraints necessitate creative solutions.

Key principles of frugal engineering include:

• Simplicity: Eliminating unnecessary features and complexities to reduce costs and improve reliability.
• Affordability: Designing products that are accessible to a wide range of consumers, especially those with limited budgets.
• Resource efficiency: Minimizing the use of materials, energy, and other resources.
• Durability: Creating products that are long-lasting and can withstand harsh conditions.
• Adaptability: Designing products that can be easily modified or repaired to meet changing needs.

The concept of this is for hardware because is costly to build. Translating this into software engineering is a free and open world to exploit. I’ll share more of my example later.

Simplicity

Focus on building something easy to understand, maintain, and modify. By focusing on simplicity, you want to reduce complexity, improve code quality, and enhance overall software reliability. Is okay to take time to explore more alternatives. If possible, avoid building things that vendor lock.

Choose something simple to start and use, preferably something well-known or popular without the need to install too many things. The less dependency the better. Like Laravel, most design patterns are nicely designed and easy to use. Reduces a lot of thinking overhead.

Affordability

Refers to the creation of software that is accessible and affordable for a wide range of users. This involves designing and developing software solutions that are cost-effective to produce, distribute, and use.

Use open-source. The benefit of using open-source has lots of benefits to it – especially if you’re in the bootstrapping stage where cost is a constraint. Also, is a good way to navigate around vendor locking. Here is a real-world example using cloud infrastructure. Have you ever encountered things that are open-source but are not supported in any of the big 3 cloud providers (AWS, Azure, GCP)?

Is really strange world, whereby only the software industry can afford to scale while still providing value for free?

Resource efficiency

Refers to the optimization of the use of resources. Not limited to system resources, our resource refers to assets that already have, process efficiency like DevEx and deployment. To me, this is usually the most challenging part, but it feels rewarding once you have something working.

In my case, say I already owned or paid for a web-hosting server. Therefore, one of my options to bootstrap something quick and cheap is to host with the same server — That’s where you’ll see why almost all my hobby projects are the extension of my this domain.

As for the developer experience (DevEx). Anyone who works with me or my code base will realize that I care a lot about DevEx. For example, the seamless development experience to utilize hot-reload for quick feedback.

Another example is the ease of doing local development without the need to rely on external dependency unless is necessary. Like bypassing analytics if you don’t have your env set. Is a design pattern I like to use to make it simple for people to start with the core application, skipping the lengthy setup (until you need it).

Durability & Adaptability

Intentionally decided to skip these two since the primary focus of frugal engineering is usually for the bootstrapers. These two are not so relevant for now. I’ll keep these for another day – when focus on enterprise level development.