As a dev turned CEO, it’s complicated. Very few products / use cases need to be more than good enough out the gate. Most software good enough is exactly what is needed. It’s not a one size fits all. As CEO and CTO I need to decide what’s ok to be good enough and what isn’t.

even communicating that to developers and making sure they internalize this requirement can be a big helper.

what I think happens is that companies try to hire the best talent they can find for their money and tell fairy tales how they are modern and foward-looking company with the vision that is going to change the world - and of course devs will internalize that and will try to apply craftsmanship to their daily work, and then you will have problem of shipping on time and on budget.

if managers told exactly and upfront that the products must be hacked together and asap and the quality is NOT the goal, that the goal is to ship shiny new thing quickly to impress VC suits in next N months, and get their funding check and continue this loop until the company finds its exit in form of IPO/acquisition/etc - everything would be honest, upfront, efficient, and conflict free.

A large part of the problem is about differing time horizons, and the fact that low quality is always slower on the long term. So, it's not ok to just say "we don't need quality, we need speed", because quality will imply on reduced speed sooner or later.

On the best places, a lot of the communication problems come from the fact that managers tend to willfully ignore the fact that low quality is a losing proposition at the long term, and developers tend to willfully ignore the fact that short term only gains have value.

On the worst places, communication problems tend to come from the fact that management wants to artificially prop the numbers before they get a way to jump ship, defrauding everybody else, so they simply can not be honest.

That is exactly what those companies do in domains whose business is not to ship software, all development is driven by external contractors, in many cases hired on per budget basis, e.g. hire contractor XYZ to deliver 5 Jira tickets, by the next budget round another contractor will do another set of Jira tickets.

What changed my mind was moving from product development into enterprise consulting, specially in industries whose main business is completely unrelated to software.

All the bonsai-like rules about software jewellery have zero value in those industries.

What those company owners and management departments care about is their main business line, as long as those boxes keep shipping or people keep buying their stuff, they couldn't care one second how the sausage is made.

It is easy to blame all the major consulting sweet shops for the quality of delivered work, while in most cases what gets delivered is what customers (e.g. management board) are willing to pay for.

Just ranting out loud, not targeting anyone.

That ability to make an informed decision is itself notably rare though. Most businesses have to rely on trust & abstract consideration, for they don't have people running the show who can visualize & see many of the forces they are working to weigh against each other.

More generally, I feel like tech needs some breakthroughs in the "create more value than you capture" (Tim Orielly 2008) sense, where it is tech itself that is the product, rather than a product built of tech, that is trying to be created. Exposing & opening the tech, making the tech accessible. This is a far off point, not one I'd want to reduce the discussion to, but I think in general we've had a lack of technical leadership that's deflated our general sense of how core, critical, & powerful this general drift is.

I very much agree, that it's all very complicated.

Isn’t it much easier to build on top of a good code base?

Yes no doubt but good and bad code is not binary. There are different levels of good and bad code. The tricky part is determine for this feature what is good enough and not so good it took me 5x for when 1x of goodness would have given me the same return on investment. As my new role of someone who pays the bills this is a lot more important where as a dev I was viewing things from an academic lens.

We don’t always do good enough... some times we need extremely well done due to the sensitive nature of the code.. it all depends.

Reading comments like this gives me hope.

There seems to be a polarized view of "jewels are worthless, just ship" or "we need more jewels". Both perspectives are dangerous.

Software-jewels have a place, but you have to be selective about what code needs to be that level of quality. And like so many decisions in software development, it's about the trade-offs.

If we're writing experimental code with a low shelf-life or internal tooling, we are better off writing code we expect to throw away completely. Writing high quality code here will take time away from making code quality high in areas where it's important.

On the other hand, if there are some subsystems critical to our business--we want them robust, extensible, and fast--they are good candidates for "jewel" quality. But you have to allow the time needed for a potential rewrite and more thoughtful architecture.

Thanks for your point of view!

> Rarely are technics given first seat at companies

Except Google, Microsoft and Apple.

Apparently you haven’t worked at those companies recently. Sounds like you may have been a very early employee.

Zilog is a famous example of what happens when no one reins in the engineers.

Famous engineer driven failures are rare. And I havent heard of zilog. Were they as famous as.. the British Aircraft Corporation..?!