The real reason why software development costs are so high
Keep It Simple Stupid - Why Software Developers (and Managers) Need a Sanity Check
When I studied computer science, my goal was simple: use technology to solve real-world problems. Fast forward to today—working as a software engineering consultant—I often find myself not solving business problems, but fixing/fighting the damage caused by complexity.
Let’s explore some of the recurring patterns that contribute to this mess. As crazy they can seem, I had the privilege to see them myself.
- Keep It Simple Stupid - Why Software Developers (and Managers) Need a Sanity Check
- The Rise of Technical Debt
- Developer Behaviors That Hurt Productivity And Quality
- Management Mistakes That Wreck Projects
- KISS for your safety
The Rise of Technical Debt
Overengineering a CRUD App
Why build something simple when you can make it unnecessarily complex?
These days, building a basic CRUD web app often turns into this stack:
Frontend (JS framework) → GraphQL → BFF in Node.js → REST API → Java Backend → Database
- Do we really need a BFF for one backend service? BFFs are designed to orchestrate data across microservices. If your app is a monolith, this is pointless.
- Why convert GraphQL to REST? Pick one. Java supports both well. Adding layers doesn’t make it elegant—it just makes debugging a nightmare.
Result: More complexity, more bugs, more cost.
But as a result you will have the right to present to the next conference, how we build our ToDo app with less engineers than Netflix.
Using MongoDB for Relational Data
MongoDB is great for document-based storage—but not for relational data. Once you start needing joins or nested relationships, performance tanks and your codebase gets bloated with glue logic.
If your data is relational, use a relational DB. It’s that simple.
CQRS, DDD, Onion, Event Sourcing (for a CRUD?)
Yes, these architectural patterns are powerful—but only when used appropriately in particular use cases. If you're building a basic internal tool or a CRUD webapp, these patterns will cause more pain than gain.
They introduce complexity, increase onboarding time, and after two years, the new team rewrites it all... if they’re lucky enough to get the budget.
Kubernetes for Hello World?
Deploying your "Hello World" app to Kubernetes might feel cool... until you’re spending $300/month and half of your time maintaining YAML files.
For almost every application with less than millions of concurrent users, Docker Compose or even a basic VPS is more than enough (if your code is at least decent).
Homegrown Frameworks: The Anti-Productivity Tool
Internal frameworks can boost productivity—if done right.
But I’ve seen a project where they built four (4!) nested frontend internal frameworks, none documented, each with its quirks. Debugging was a treasure hunt.
Frameworks without documentation or purpose become liabilities, not assets.
Bikeshedding: Interfaces, Optionals, and Folder Structures
Some developers spend hours debating:
Optionalvsnullvarvs explicit types- Feature-based vs technical folder structure
These debates rarely impact the final product and they create tensions between the developers.
If only management knew how much time and energy is lost on these trivial disputes...
Developer Behaviors That Hurt Productivity And Quality
Overoptimization
Yes, octal literals might be faster. But your teammates will hate you when they can't understand what’s going on. Maintainability > micro-performance (and yeah there are devs that really do that).
Reinventing JSON.parse?
When someone rewrites JSON.parse because they think it’s not performant enough... it’s a sign something’s gone very wrong. In particular if (s)he is the architect of the company.
Code Length Extremes
- Shortest Code: Some devs (usually Kotlin/Scala fans) write cryptic one-liners that only they can read. Good luck maintaining that. Less code = less bugs, they say. These are the same guys that have to annotate their code avoid the cyclomatic complexity flag.
- Longest Code: Others (hello Java) seem to get paid by lines of code. They avoid Spring annotations and Lombok, proudly implementing everything by hand before to move everything in abstract classes and interfacing every single service that has only 1 implementation by design.
Balance matters. Write code for humans and nice colleagues, not machines or yourself. Size can matter, but not in this context.
60+ Fields In A Class?
It remembers me the 10'000 lines of code in a function mentioned in some talks. For our bigger joy this happened in the constructor and the class was immutable.
'Weak' Immutability
"Our code needs to be immutable for safety." ... and in every method you have a .copy() call.
We Don't Care If You Think Your Style Is The Best, Just Use What The Team Decided. This Is Not TikTok
50% of the developers think to be in the 1% best in the world, everybody will have an opinion about how the code of the others is total sh*t.
Most of the developers won't read the code of the others and won't care about the common style and pattern used.
It's awful to read 3 classes of existing code and see 15 different styles. It's like to read a book in which every page was wrote by a different author (not that anybody reads anymore).
This is like TikTok, every video is similar but different. Please read and write books and reduce your TikTok time.
Don't Be Creative Naming Things
In the Database we have a table called 'Widget' ... what could be ... clear, it's a Task type. Why? It's just to annoy the developers that will work on the project in the future?
This is a present from a BA that decided that this was the best name for the table. One moment of craziness a long pain for the development and the maintenance.
Management Mistakes That Wreck Projects
No, You Don't Need Microservices To Show In The Web The Data From The Database
When investors and managers ask for microservices, because they want 'scalability' ... they are asking an F1 car to drive in the mountain roads.
Management should seriously stop to read shiny brochures from big tech companies.
Developers Aren’t Interchangeable Players
You can’t just move a backend dev to frontend and expect magic. Specialization exists for a reason.
Not All Developers Code at the Same Speed, Few Good Are Better Than Many Average
Management sometimes assumes that 3 devs = 3x faster. That’s not how it works.
Some devs are 3–5x more productive than others, especially in quality and autonomy. These use cost more, the management should understand that sometimes 2 good developers that works well together are much more productive than 7 random developers put together.
Talent Moves Where It’s Valued. Short-term savings, long-term expenses.
Great developers—like great athletes—seek growth and compensation. Moving your team to a cheaper country might save money on paper, but costs quality and retention.
When a talented dev from a "low-cost" region finds a better opportunity, they’ll take it. Smart companies build teams where they can attract and keep talent, not where they earn less.
Ironically, this ‘saving strategy’ often leads to lower quality, higher turnover, and eventually... higher costs.”
KISS for your safety
Developing software isn’t just about writing code. It’s about making thoughtful decisions—when to be pragmatic, when to follow best practices, and when to say no to complexity.