Explaining to business people why building software is still hard
![]()
Anton Zaides, who writes the Manager.dev newsletter for engineering managers, spent a two-day hackathon building a referral system in Lovable with two engineer friends and three recruiters, so that the recruiters could maintain it afterwards. The first day got them through "90% of the project"; on the second, things "Completely broke", and slowing down ("Understand, plan, implement.") left them, at least, with a working, demo-able flow. To explain to business people why software stays hard, Zaides uses a house analogy that came out of nearly buying an old house: a leaking roof can be fixed with a bucket or at its cause, and the support for a second floor is far cheaper to build in with the first than to add later.
Was this useful?