> If you are reasonably good at making it work, you can then make it right and maybe even fast.

Whuahaaaha ... If only that was so easy. Once you get it working, it will in most cases be torn from your hands and you will not get to touch it again any time soon. So what one does to find even a little bit of joy is to try to get some sense into that code right away, because you don't usually get a second chance.

If I knew, that at a later point in time I will only have to ask and sure enough I will get the opportunity to make things well-made, then I would be much more willing to not spend any additional time into making things well in the first run.

Making things well requires knowledge and craftsmanship, while making things merely as shoddy as possible but according to spec will requite a bunch of interns making a pile of unmaintainable crap. Code only written with the next goal in mind, not looking out for the casualties along the way.

I may not have communicated this well enough. I wasn't referring to a multi-step process where I hand over the solution in between. I was referring to getting good at making in work, right and fast in one step (at least as far as the customer is concerned).

Many try do it all at once and then end up with… nothing.

> first try to make it work to spec

In my professional experience, the only spec you get is a wishlist, never quantified, always vague. Half the work is figuring out what the customer wants.

The only metric that anyone cares about is speed. You need to go fast, but to where? There is no consensus.

If quick and dirty gets you 10 shots, while slow and beautiful gets you 1, I’d choose quick & dirty any day.

An order of magnitude is a bit much. I'd say quick and dirty gets you 3 shots, while slow and beautiful gets you 1. And if you succeed, it means the result is dirty/ugly code that must be maintained forever.

Doing it many times tend to be much cleaner than trying to get it right the first time. So fast -> clean, slow -> ugly code, as long as you use the speed to redo and clean things up.

Except the redo and cleanup part never happens.

The PoC becomes a pilot becomes production becomes an exit becomes someone else’s problem. That’s the SLDC that has gotten us to a place with endless amounts of terrible software everywhere you look.

Though, I’m optimistic that at some point, the software industry will be so saturated, all the products have all the features, and the only place left to differentiate or disrupt will be quality.

That's not how you build big important, expensive things, though. It all depends on the context.

Do you know that the big expensive thing is what your customers actually need? Do you actually know what your customers need?

That’s basically the only important context. If you can’t deliver that, it doesn’t matter how well thought through, extensible, or scalable it is.

Do the customers know what they actually need?

Well if you don’t have a pretty good idea of the problem you’re solving for the customer, you’re much better off trying as many things as you can, quickly and cheaply, to figure out.

It seems that the biggest, most important, and most expensive things are built like that.

Like bridges and skyscrapers?

10 shots facing the wrong direction still gives 10 guaranteed misses. At least make sure which cardinal direction the target is in.

> Half the work is figuring out what the customer wants.

And a substantial portion of the rest is telling them why they might be better off asking for something a little different.

If a large portion of software development is the attempt to discover what is a minimally viable product, then software development is not pure software development. It would be startup business development. That makes real programming to be something like obscure operating system development.

So it's a conflict of names, a matter of proper identification.

I don't see how that's a problem. It's not for everyone, yes, but I like it a lot. Talking directly to the customer allows me to create exactly what the customer needs, without any convoluted process.

If that's not for you, you need at least a requirement engineer between you and the customer. That's also okay.

From my experience, getting things done quick is almost never relevant. Getting things done “cheap” is.

Specs are fickle, vague things. Well written code can accommodate the whims of users and execs alike.

I also tend to find that folks who write quick and dirty code “to spec” leave it riddled with bugs and unhandled corner cases.

I live by three steps when writing software:

1. Get it working.

2. Get it working well.

3. Get it working fast.

Your last sentence reminded me of that.

This is the way to do it. First you want as complete coverage as possible with a unit test showing that the implementation is sound. Then you can try things and refactor for performance, checking as you go that you didn’t break anything.

In my experience, most of the corporate world seems to care more about their aesthetic notions of the Platonic ideal of what code should look like than whether or not it works or whether or not it is efficient. Certainly that's my experience from interviews.

Maybe the people who care about business value should be the engineering managers not the people who equate their personal aesthetic preferences with the only right way to write code?

I’ve had the opportunity to work with lots of mechanical engineering corps to date, and I can confidently tell you: Even if they had some platonic ideal, they would never be able to follow through. The mediocrity of their software development practices is… profound. On all levels of the hierarchy. Sure they care about the ideal of sustainable software development, but they just can’t do it.

On the other hand, my employer advertises clean code as a service, and this attracts the kind of developers you describe.

Because code is read more often than written? And clean code is easier to read?

> clean code is easier to read

What's "clean code"?

Capital-C Clean Code? Hell no. This is code that looks clean only on the surface, but in practice it only works on toy projects. Anything big enough is impenetrable for debugging and a performance catastrophe.

Lowercase "clean code" from people who heard the above but never even read the book? What's that anyway? Nine out of ten times, this is just developers putting aesthetic preferences in front of correctness, simplicity and performance.

Wrong. Performance and correctness/cleanness go together. Perhaps you have never tried generating correct code that is ways faster than what you can write by hand.

Once again: what even is “cleanliness”? Are you writing it in lowercase on purpose, or are you unaware of methodologies that share the term? Or are you talking about Uncle Bob’s but refusing to capitalize?

“Clean” is a horrible qualifier for code. It is either too subjective/broad, or too loaded.

OK, I realized it was about something else. I don't follow Uncle Bob, and was referring to some people justifying "unclean"/incorrect shortcuts to gain performance.

I totally agree with you in that regard, "readable" and "performant" often go hand in hand. My gripe is with the "Clean" adjective, that often indicates code that actually isn't readable and is also low performant.

Code is run more than it is read especially if you count users. And so-called "clean" code is a performance disaster[0]. It's also, if that link is an accurate representation of what "clean" code is, a readability disaster. The more readable code, in my opinion anyway, is the version that is also an order of magnitude faster.

[0]: https://www.computerenhance.com/p/clean-code-horrible-perfor...

There ought to be a good spec (i.e. requirements). But it's hard to motivate people to excel without giving them opportunity to grow their talent.

This cartoon remains the best visual representation of an industry that seems incapable of doing requirements, testing, documentation, and security.

https://i.kym-cdn.com/photos/images/original/000/475/749/fd8...

Counterpoint: The MVP is usually what ends up in production. If your code is a heap of garbage but chocolate-coated on the outside, you're gonna impress management and they'll want to push it live asap. Then the issues start exploding.

yes, a shitty foundation leads to shitty feature implementation. I've seen this everywhere from startups to Fortune 500 companies. Nobody cares about code quality, except maybe the one self-annointed gatekeeper who thinks he's making a difference and shitting on everyone's PRs delaying features. Get rid of that guy he serves no purpose

People don't care about quality in general unless it affects the bottom line. Not just code quality, but product too. Bugs? Who cares unless it costs us money. Security holes? only a problem if they're exploited... And it costs us money.

That guy keeps everything from collapsing.

Yeah, if the indentation style, variable name capitalization rules, structure of commits, 100% unit test coverage the guy knows is the absolute truth and top priority, a collapse of everything is imminent.

involved conservationists and curators rarely get the recognition they deserve, but sometimes obstructionists are just that

Spoken like a true MBA. Hope I never have to work with you.

Um, yeah, that's… IMHO exactly where an MVP is supposed to end up. The “VP” says that.

> you can then make it right and maybe even fast

IF there is budget for that very often. Otherwise they'll expect you to move on.

I just wanted to make it more explicit since this issue isn't specific to software developers, every career grapples with the "right way" versus the "economically prudent way" in our (US) capitalistic society. That in and of itself isn't bad, take capitalism however you want, but the point is managing expectations to the reality that exists in front of us, not the one you wish it could be.