This particular story provides an important refinement to this point. Success isn't always possible. Delivering "no matter what" is part of what engenders trust, but an even more important component is being ahead of the ball.

If your manager comes to you saying "you're not matching expectations", whatever explanation you might have will be read as an excuse. If you proactively tell your manager "hey, this framework seems hellish, we might face some problems", you're leading the discussion in how to recover from a bad situation — You redefine "success" early enough in the game that you can actually deliver it. Knowing how to have this conversation (and the self-reflection necessary to understand you need to have it) is one of the most important parts of a "true" 10x engineer.

The problem if you think about it is that you will tell him just that every time you see him. In other words, how do you show that you know how to make a good framework other than by beating deadlines? Beat deadlines, again and again, and then you will be granted the right the make a framework yourself. One that. among other things, actually beat deadlines.

Crucially, each lever only goes so far — you (usually) can't adjust expectations to the point where you're expected to do zero work, and you can't deliver on impossibly demanding expectations solely by working extra hard.

While you're absolutely right that the "keep shipping" lever is very important, the article provides an example of where you need to pull the other lever early.

I've had MANY frank conversations with both product and engineering leadership about the current state of the world. The VP of engineering is onboard and understands the pain of what we're going through. Product is a bit harder to convince, but just as important -- probably more important. They understand that my team is having to spend 20%+ of our time just bringing the code into this decade, because I set that expectation early and reinforce it often.

I argued AGAINST a from-scratch rewrite because I knew it would never be ok to stop shipping. But I have been able to convince them that slowing down now will let us move faster later.

And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. You may look good, but the team / dept / company is worse off, and someone else has to clean up.

I agree design by committee can produce awful results - and I said nothing about a single person doing a design as being an issue.

My last project I released still had about 20 TODOs in the code. I launched it, it got great reviews, everyone loved it, then I got a new project and they deprioritized the "cleanup" phase. I suspect the edge-cases are just getting handled manually - no one cares and I'm still a hero.

Please justify that.

I did some software, a not too complex chunk of work for a midlands (UK) retailer in 1999. It dealt with a couple of million pounds of retail orders that year. Not so big but not trivial either. It was still in use in 2015, and quite possibly is today (although the boss told me they re-used it for a rather different purpose by their sales reps).

It was very reliable because I fought to keep it simple, and tested it brutally (eg. the core part took 5 days to write but got 3 weeks testing, founding only 2 errors, but it was 2 errors fewer).

If it was crap it would have been junked so I'll claim that the end quality contributes to its life.

High reliability tends to stick around. I think lex/yacc started in the 70s and is still around today in the form of its spiritual successors flex/bison. Ancient but still grinding along.

' In a 2008 interview, Johnson reflected that "the contribution Yacc made to the spread of Unix and C is what I'm proudest of" ' (https://en.wikipedia.org/wiki/Yacc)

If you ship crap its lifetime is intrinsically much shortened. That's my thesis anyway.

The people/team handling it manually probably care

The alternative to shipping something that works good enough, on time often isn’t to ship something perfect on time but to not ship on time or even worse, -at all.

That would be even worse for the people/team supposed to use the product.

The real world is much sloppier than any book will ever tell you.

> is about the development cost vs maintenance cost

Absolutely true.

> how the latter beats the former

If you're believing that equivocally ((I don't think you personally are btw) then I don't think you're reading the advice the book is giving you correctly.

A shitty technical solution that gets to market quicker often (not always) can make the company more money in the long run. There is no "one right answer" here, it's all about judgement. 100+ tech DD's and counting...I've seen the whole spectrum. I've seen a $40M revenue (38% EBITDA) tech company built using a FileMaker-like tech stack (all WYSIWYG). And yes, I'm serious.

Code that doesn't do the job is worthless, no matter how testable and well-designed it is.

Of course you can debate whether this is a management (scheduling, resource, PM) problem or a developer (competence, architecture, tool choice) problem - most likely some of both.

But whoever is responsible, it's still a non-solution.

Not everything needs 90% test coverage and more comments than code to be good. And not everything with 90% test coverage and more comments than code is any good at all.

BUT - when someone else new comes along to look at it, the 90% code coverage, and comments helps them immensely - they can get up to speed to fix whatever bug has appeared a lot quicker.

Sometimes the burden of maintenance is the price you have to pay go get an operational/production system early on and enables you to let other requirements emerge earlier.

You might focus on the "burden of maintenance", and also assume that you're saving time by taking the long route to production, but letting requirements emerge early on in the project is also a significant time saver as it enables the project to avoid committing the mistake of investing time developing a goldplated solution that will have to be thrown out.

You need to accept the fact that the "burden of maintenance" is always there and it will always be there, whether you invest years rolling your goldplated solution or just dash to production with a quick and dirty solution. You don't get rid of that burden by aiming for an academically pristine implementation that takes ages to deliver. Requirements do change, and do so continuously. Heck, designing stuff for a scale that will never be required is also a major problem. So, why would anyone be concerned with having to spend 120% of the time developing a solution if that path enables you to get up and running in 20% of the time?

If you read on:

> > One day, I said "this needs to go", and everybody listened, architects and directors alike.

The OP hacked a shitty solution to make people listen to him. Once people started listening to him, he found it easier to persuade them to let him improve things.

Now, if they hadn't gotten the credibility (due to the short term fix for thing they wrote broke sooner than expected), or they gained a lot more credibility and moved in the company, or out of it, the broken thing would still be there, and someone would have inherited it, and had to refactor / relearn / replace it.

One of the points about 10x devs that people are pushing back on is this - do the thing to a minimum spec, drop it on the floor, and get kudos for it, while the rest of the devs run around picking up the pieces.

I personally know one engineer that after a decade of being the 10x rockstar shit navigator finally got the opportunity to create a codebase from scratch. They'd been dreaming of doing such a thing for years and had the design all planned out. It was to be the shiny new product for the company.

One day the people upstairs finally gave their blessing. The ninja worked alone, making all the decisions, with full support of upper management. The result was a great big steaming pile of shit that nearly sunk the company. After a short period of mental health problems the ninja was promoted to shogun and the company hired a new shit navigator.

In football (soccer) it's easy to observe that good players can be good in totally different ways and/or situations. And it's also easy to observe players who were once thought of as good or bad can totally change either way when they change teams. It's a shame engineering performance can't be as easily observed.

The other main point is that while I'm doing this thing that gained cred and leeway, at the time I'm just trying to do the right thing in the eyes of people who have to deal with it first hand over the long term including maintainers of the software. At no point dud I think if I do this and look good I'll have the points to fix my mess later or any sort of gaming strategy at all.

As a manager, I'm more inclined to trust someone who's delivered results even in challenging codebases. It's human.

  "trust someone who's delivered results even in challenging codebases" 

He couldn't get things released quickly because he couldn't even get the program compilied without serious effort involved.

I understand your point, which basically boils down to the axiom of managing expectations. But sacrificing professionalism is not something that should be accepted as normal, let alone celebrated as clever. It’s the oldest trick in the book.

If you are taking responsibility to maintain it for 15 years, feel free to go on. Otherwise, please step down and let professionals do their work.