A lot of engineering decisions are made by default. A team reaches for a framework because it is popular, adopts a pattern because a respected company uses it, or follows a practice because it has always been done that way. Defaults are not bad; they save effort. The trouble starts when nobody can explain why one applies to the problem at hand.
Where defaults go wrong
- Tools without fundamentals. A framework hides complexity until it fails, and then only someone who understands the layer underneath can diagnose the problem.
- Practices without context. Advice from a company with thousands of engineers may not suit a team of five.
- Architecture by fashion. Distributed microservices solve organizational scaling problems. For a straightforward internal application, they add failure modes and running costs without a matching benefit.
- Vendor lock-in by accident. A convenient proprietary service can quietly become a dependency you cannot leave.
Working from first principles
First-principles thinking means reasoning from the constraints of the actual problem rather than from precedent. In practice, that comes down to a few questions:
- What is the requirement, in numbers where possible? How many users, how much data, how much downtime is tolerable?
- What fails if this component fails, and who finds out?
- Who will maintain this in five years, and do they have the skills?
- What would make this decision wrong, and how expensive would it be to reverse?
A worked example
A college wants a student records system. The fashionable answer might involve containers, an orchestration platform and several services. The constraints say something else: a small IT team, modest and predictable load, and a need for easy maintenance. A well-structured application with a relational database and tested backups meets those needs and can be supported locally. Choosing the simpler design here is the engineering decision, not a compromise.
Habits worth building
- Learn the layer below. Understand HTTP if you build web applications, and SQL if you use an ORM. That is where the hardest bugs are solved.
- Judge tools on merit. Assess a technology against your constraints rather than its popularity.
- Prefer boring technology for critical systems. Mature tools have known failure modes.
- Write down trade-offs. Every option has costs. A decision record that names them shows they were considered.
None of this means rejecting frameworks or best practice. It means being able to say why you are using them. See also software architecture fundamentals.
