[{"data":1,"prerenderedAt":39},["ShallowReactive",2],{"profile-en":3,"article-custo-real-da-complexidade-en":27},{"brandName":4,"fullName":5,"headline":6,"manifesto":7,"contactIntro":11,"avatar":12,"manifestoImage":13,"social":14},"Danilo Fernando","Danilo Fernando - Senior Software Engineer","Well-built software, reliable integrations, and architecture designed to last.",[8,9,10],"My journey is guided by the belief that code is just a tool to solve complex business problems. With solid experience in the Java and Spring ecosystems, I focus on systems that work AND are easy to maintain and evolve.","Specialised in robust APIs and critical integrations, I believe technical maturity shows up in balanced decisions that weigh innovation against real business needs.","I chase real impact: Clean Code is not aesthetics, it is an economic necessity for long-term product sustainability.","I'm always open to new professional opportunities, technical exchange, or conversations about architecture and software engineering.","\u002Fimages\u002Fprofile\u002Fdanilo.webp","\u002Fimages\u002Fprofile\u002Fdanilo_manifesto.webp",[15,19,23],{"kind":16,"label":17,"href":18},"email","Email","mailto:danilo.bossanova@hotmail.com",{"kind":20,"label":21,"href":22},"linkedin","LinkedIn","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fdanilo-fernando-dev\u002F",{"kind":24,"label":25,"href":26},"github","GitHub","https:\u002F\u002Fgithub.com\u002Fdanilobossanova",{"slug":28,"title":29,"excerpt":30,"category":31,"tags":32,"readTimeMinutes":35,"publishedAt":36,"author":4,"coverImage":37,"body":38},"custo-real-da-complexidade","The real cost of unnecessary complexity","Why over-engineering is often the fastest path to project failure.","Architecture",[33,34],"clean-architecture","technical-decisions",5,"2025-02-10","https:\u002F\u002Fpicsum.photos\u002Fseed\u002Fcomplexity\u002F1200\u002F600","## Complexity on compound interest\n\nComplexity is the biggest cause of technical bankruptcy I've seen up close.\nEvery \"just in case\" abstraction is an implicit contract with the future —\nand the future always cashes in.\n\n> \"The only thing more expensive than solving the wrong problem is solving\n> the right one with three layers of indirection nobody asked for.\"\n\n### Warning signs\n\n- Abstractions that exist for a single use case.\n- In-house frameworks for problems the ecosystem already solves.\n- \"Let's make it pluggable\" **before** two plugs exist.\n- Dynamic config for something that changes once a year.\n- Mapping layers between identical objects.\n\n### Practical heuristic\n\nBefore creating an abstraction, ask:\n\n1. Are there **two** real consumers today?\n2. Is the cost of extracting later prohibitive?\n3. Does the behaviour actually vary, or just the name?\n\nIf the answer is \"no\" to all three, **inline is the right answer**.\n\n### A concrete example\n\n```java\n\u002F\u002F Before — flexibility nobody asked for\npublic interface UserNotifier {\n    void notify(User user, NotificationPayload payload);\n}\npublic class EmailUserNotifier implements UserNotifier { \u002F* ... *\u002F }\n\n\u002F\u002F After — the system only sends email, period\npublic class EmailService {\n    public void sendWelcome(User user) { \u002F* ... *\u002F }\n}\n```\n\nWhen the second channel appears, you extract the interface in **five minutes**,\ngreen tests and a clear head about what actually changes.\n\n### Summary\n\nStart from real pain, not theoretical elegance. Clean Code is about\n**maintenance cost**, not interfaces per megabyte.",1776457051932]