The Enduring Efficiency of Traditional Tech Stacks
In the rapidly evolving world of technology, it's easy to get caught up in the latest trends and forget the importance of a reliable and efficient tech stack. A recent development bias, often referred to as 'NewDev,' has been raising concerns about the efficiency and sustainability of modern tech solutions. This article explores the pitfalls of this development bias and presents compelling cases for the enduring efficiency of traditional tech stacks, with a focus on PHP and PostgreSQL.
The Paradox of Modern Development
The modern development landscape is marked by an ever-changing array of technologies, frameworks, and methodologies. However, as a seasoned developer with 15 years of experience in constructing business systems, I've learned that software designed for businesses must outlast technological fads. The question then arises: why build a business system with a 15-year-old tech stack like PHP and PostgreSQL?
The Dangerous Sesgos of NewDev
The 'NewDev' mindset is characterized by three dangerous sesgos: the Sesgo de Novedad, the Sesgo de Complejidad, and the Sesgo del CV.
The Sesgo de Novedad
The Sesgo de Novedad is the belief that if something is new, it must be better. This has led to teams rewriting stable systems simply because a new version of a framework has been released. In one instance, a team migrated an ERP from AngularJS to Angular 15, spending 6 months and $200,000 to have nothing but newer dependencies.
The Sesgo de Complejidad
The Sesgo de Complejidad stems from the idea that more layers equal more professionalism. Overly complex systems with multiple layers, such as API Gateway, Auth Service, Business Logic, Database, and numerous microservices, are not uncommon. However, each layer adds latency, potential points of failure, and cognitive complexity.
The Sesgo del CV
The Sesgo del CV is the tendency to use technologies that potential employers favor. Reviewing CVs recently, I found that 80% of them mentioned React, Node.js, and Docker. Conversely, 'maintainability' and 'long-term stability' were rarely mentioned. While it's understandable that developers want to stay competitive, the development process should not be a race to collect trendy technologies.
Cases Where Simplicity Prevails
There are numerous examples where simplicity has proven to be more beneficial than complexity. Here are three such cases.
Case 1: The ERP that Survived the Team
A system built in 2015 with PHP + PostgreSQL is still functioning with four different teams, thanks to zero external dependencies. This system has no package.json or composer.lock to update or break.
Case 2: The Failed Migration
A team migrated their application from Vue 2 to Vue 3, only to encounter bugs in production 3 months later. The cost: $500,000 in development hours and lost clients due to instability.
Case 3: The Over-Engineered Disaster
A startup implemented Kubernetes, service mesh, and circuit breakers for 50 concurrent users. The system was so complex that only two developers could understand it, and both eventually left the company.
The Antidote: Principles for Tool Selection
To avoid the pitfalls of the NewDev mindset, it's essential to adopt a few guiding principles when choosing tools for your projects.
Stability Decenal
Software designed for businesses should last at least 10 years. This means using mature, stable technologies, minimizing dependencies, documenting architecture, and prioritizing simplicity.
Simplicity Radical
Fewer layers equal fewer points of failure. Our rule is simple: "If it doesn't add value to the business, it doesn't enter the system."
Sovereign Technology
Control your technological destiny. Our stack: PHP 8.4 + PostgreSQL; SQL direct for maximum performance and minimum overhead; and vanilla JS by module for zero npm dependencies.
The Unpopular Choice
One year ago, we made an unpopular choice: to reject React, TypeScript, and GraphQL for a new fiscal system. The result? A system that responds in under 100ms consistently, costs 60% less in maintenance, and can be understood by any developer in just two days. Despite the lack of popularity, the system works flawlessly.
Conclusion
It's not a question of tech stack vs. tech stack; it's business vs. ego. The next time you choose a technology, ask yourself: Does this serve the business or my curriculum? Can it last 10 years? What happens if the primary maintenance is no longer available? The development of software is not a technological passageway. It's building foundations for businesses to thrive, even when those foundations may seem "boring."