Explaining to business people why building software is still hard - Manager.devNewsletterAboutAdvertiseExplaining to business people why building software is still hardAnton ZaidesJuly 14, 202618.8k viewsShareengineering processproduct decisionsteam culture It’s 1 pm on the final day of the Hackathon, 5 hours left. For the last 2 hours, we made ZERO progress. I’m cursing the day Lovable was born. As soon as I fix one problem, another one appears, and our app is barely usable. The start was very promising. I joined 2 engineering friends and 3 recruiters to build ‘HoneyCrew’, a smart referral system (the goal was to send a weekly summary to every employee with potential candidates from their network for our open roles. Here’s an open source version). We decided to go with Lovable so the recruiting team can maintain it themselves later. On the first day, we just FLEW, completing 90% of the project. Scraping, scoring, Slack integration, admin - things looked almost ready. On the 2nd (and final) day, we worked on some minor improvements, and things just… Completely broke. Endless bugs everywhere, slowness, everyone super stressed. The recruiters on our team couldn’t understand what went wrong. We were on the path for an amazing product, and now we were in danger of not having anything ready for the demo. How come? An allergy to ‘infra work’ I used to work with a senior leader who loved to say that he has an allergy to the words ‘refactor’ and ‘infra work’. He couldn’t understand why we couldn't build it right from the beginning, and why we were always so slow. After LLMs appeared, it became even worse. He constantly asked: “Can’t you just give this task to ChatGPT? What’s the problem?” To his credit, he at least asked this to our faces. I know many non-technical leaders who think engineers always exaggerate and work too slowly. It’s a flavor of the same old software engineering war I talked about last week. A coworker (and a good friend) once framed it like this: “You write code, which is just words in a language I don’t understand, right? With fixed meaning. And you know what you want to say, as you have the specs you need to follow. How come it always gets more complicated?” Huh. I’ve been struggling to explain this, until I almost bought a house: Imagine if your software was a house Last October, we saw a house for sale near my parents-in-law. It looked like a great deal - good location, nice neighbors, a garden like we wanted, and very affordable. It was small and 30 years old, but the low price left us extra to spend on it. So we asked a contractor: “How much would it cost to renovate it and expand by 2 additional rooms?” I couldn’t stop laughing at his response:“I wouldn’t recommend it. It’s too old. It’d be much simpler and cheaper to destroy it and build from scratch”. He could have been a great software engineer… We passed on it, but since then I’ve been using the house analogy quite a lot when talking about software. The house-building process has been known for thousands of years, and still every new one has different problems. And everyone lives in one, so it feels relatable. For example: Why can’t you just fix the issue fast? Why does it always get bigger? Your roof leaks. You can either put a bucket on the floor, or find the root cause. If it’s your own home, what would you do? Yeah, a bucket might be ok for a couple of days, but you need to constantly empty it, and you risk the real issue becoming worse. Why can’t you just solve this specific use case, without all that “infra”? Let’s say you build a new house for your family. You have enough budget for only the first floor, but you have a big family, and you know you’ll want a second one in a couple of years. Adding the infrastructure to support a 2nd floor is MUCH cheaper right now than it will be when you actually want that 2nd floor. The house you never finish So it’s 1 pm on the final hackathon day, and everything feels broken. We didn’t really have any other choice. We stopped our vibe coding frenzy and carefully went over one area at a time until we had a simple demo-able flow working. Understand, plan, implement. Much slower than our day-1 pace, but we at least ended up with a working demo-able flow. This process is how good software is built, but it gets so easily forgotten, just rushing forward. And unlike a house, you never really finish building it, so you constantly need to update the facilities while people already live inside. My favorite reads of the weekStop being the code review bottleneck. A very interesting and practical take on handling code review fatigue differently (hint: not doing them faster, and not delegating everything to agents). What being "inspiring" actually means. You are not Viggo Mortensen rallying men to fight Sauron. You are an Engineering Manager in tech. Here's what it means to inspire in this context. How tech workers are feeling in 2026: a workforce splitting in two. A very interesting survey in Lenny’s newsletter. Takeaway #9 is especially relevant for us:Workers with an extremely effective manager report roughly 65% higher job enjoyment and dramatically lower burnout than those with an ineffective one. Yet only 25.5% of tech workers rate their manager as highly effective, while 36.5% rate theirs as ineffectiveKnow a manager who’d get something out of this?ShareGet the next one in your inboxOne email a week for engineering managers. No spam, unsubscribe anytime.Email addressSubscribeRecommended for youThe "Negative split" software engineering effectSoftware engineering calories: what would cal.ai say about your product?Stop forcing AI tools on your engineers © 2026 Manager.dev. All rights reserved.Terms of ServicePrivacy Policy

The inherent difficulty in building software stems from complex processes, the nature of infrastructure, and the challenges of managing scope and evolving requirements. The author illustrates this through an experience where a project, intended to be a smart referral system, failed during the execution phase, demonstrating that achieving a usable product is often complicated by unexpected issues, slow progress, and the need to manage underlying infrastructure. The frustration arises when trying to build in a way that accommodates future needs, drawing an analogy to the process of house building. Just as a contractor might advise tearing down an old house to build something new, software development faces paradoxes: why is it so difficult to fix issues quickly, and why does complexity seem to increase instead of decreasing?

The difficulty is exemplified by the concept of infrastructure. When attempting to solve a specific use case without considering the necessary supporting infrastructure, initial development can be fast, but subsequent maintenance and expansion become highly problematic. The analogy of a house highlights this dynamic: a structure built for immediate needs may seem affordable, but adding future capabilities requires extensive, much more expensive renovations. This mirrors software development where adding necessary infrastructure for potential future functionality is often more cost-effective initially than building everything perfectly from the ground up, yet the system must constantly accommodate updates as the product evolves. This process reminds the developer that software is never truly finished; it requires continuous updating of its facilities while it is in use.

Furthermore, the emergence of tools like Large Language Models has introduced new complexities. The author notes the counter-intuitive reaction from some stakeholders seeking to delegate complex tasks to AI, suggesting that the inherent difficulty of software creation persists regardless of the tools employed. The experience of the hackathon revealed a tension between the initial fast pace of coding and the necessary slow, methodical process of understanding, planning, implementing, and ensuring a demonstrable flow. This methodical approach, while slower initially, is essential for building quality software.

Beyond technical execution, the challenges relate to leadership and team dynamics. The author addresses the role of the engineering manager, suggesting that inspiring technical workers is distinct from providing direct technical instruction. Effective management is shown to be correlated with increased job enjoyment and lower burnout among technology workers. This suggests that the difficulty in building software is compounded by the need to manage the human and organizational aspects alongside the technical ones. Consequently, the challenge for anyone involved in software creation is not solely mastering the code, but navigating the intricate interplay between technical constraints, infrastructural demands, evolving requirements, and effective team leadership.