Well, great code is inefficient if the impact of bad code is minimal. If you are shipping an animated emoji you should be sloppier with your code than if you are building flight control software. Overengineering software is like over-specing building materials by 10x and spending way more money on a building than it needs.

I agree, but practically a lot of bad software practices happen when middle management don't fully communicate the tradeoffs that are made when designing and building software. I find it hard to believe that this was a problem that no one really saw coming, but just didn't get flagged at a level that was needed to investigate it.

And in that same line of argument, great code is inefficient if the bad code can always be fixed post-release.

Never mind the consequences of the first release, if we sell enough of it we might be bothered to pick up our slack 2 years from now.

Recently, I had someone join my team who was instantly popular and everyone enjoyed this person's personality. I trusted this person more then I should have and during a period when I was unable to give enough attention to their code reviews, they introduced several critical bugs and defects into the production environment.

I never figured out if it was ignorance or laziness. But, either way I learned a valuable lesson. It was also a reminder to me that not everyone has the same level of ownership or commitment that I would expect.

> not everyone has the same level of ownership or commitment that I would expect

This is a good way of putting it. A dev might be junior and won't have the knowledge or skill to build stuff with minimal defects, but they can still have the sense of ownership and commitment to a quality product that a senior/trusted dev on the team has.

If the only gatekeeper against shipping bugs is a senior engineer catching bugs in review, then that's possibly a sign that your processes need improvement, rather than the people.

Not rather; in addition to would be more appropriate.

They are new to the team and are not getting sufficient code reviews. I wouldn’t put the blame on them. There is a lot of gotchas in an unfamiliar codebase. Although they probably should have known this and insisted on a full review if they are at senior level.

Maybe, but code reviews don't catch everything. They never can. Relying on them can also be a mistake.

If you can't trust code reviews for reviewing code of someone relatively new to a codebase, what can you trust (besides tests)? Despite tests and reviews, you might still introduce bugs into production code.

I think you vastly underestimate the scale of an aircraft in whole. Your code is one thing, but the many systems it interacts with, the systems they interact with, and the possible outcomes, is almost unfathomable to a human.

And even in simple cases where the number of possible situations is calculable, you probably haven't covered all possibilities.

It definitely depends what you're doing. Designing aircraft control systems? Yep, probably strive for perfection. Building a social network site, or a photo-sharing site, or an online forum? You're probably okay sacrificing some level of reliability for iteration speed.

It’s less about the domain than the impact of the code.

Bad code can kill your company or go unnoticed, depending on where it is and what it’s doing.

I wrote a buggy POS test program that had race conditions because I didn't really understand what I was doing. And sometimes it would assign two units the same serial number. It would check once the test was done and just fail one of the two if that happened. And the tech would just rerun the test on that unit.

In the big scheme of things no one cared.

Of course, but the solution for the vast majority of companies and projects isn't "never release code that isn't perfect."

If only managers and CEOs saw it the same way.

You'll see it in any piece of software written by any developer who is self-managed. The notion that software quality would greatly improve without managers is a myth.

We seem to have very different experiences. Every manager I ever had (including one at Boeing) has pushed me to ship software that wasn't at all ready, on the basis that the UI of the prototype looked good.

I am terrified these days of showing anything that looks like something that works to a project manager or client, without covering it in warning graphics.

Even photoshop mockups of UIs, introduced as, "Here's a photoshop mockup of the UI, what do you think?" will get some people to demand that it be shipped immediately.

One thing that I've learned (from someone else) is that unfinished software should look unfinished. Even if you have to muck around with CSS, disable some buttons here and there, maybe add something out of place.

If the UI looks perfect, then everyone will deem it to be finished, even people who should know better.

Yes, I'm advocating knowingly crippling demos. Your master branch may have something prettier, but take a sledgehammer and uglify the bastard before showing to decision makers.

If you were your own manager for your own code, you'd do it to. I'm unaware of any data showing managed software development is buggier than programmers working by themselves, and my experience is it is less buggy.

Programmers by default tend to want to work on the fun stuff in a program, and neglect the unfun pedestrian stuff. This is where managers step in to improve things.

Funny you should present it this way. My view is the opposite. As a self-managed, often solo developer, I find that team developers seem sloppy and very willing to choose not to consider the full scope of possibilities because they figure it's not their problem. Many of them work "to spec" and (rightfully?) choose not to consider the bigger picture.

It's the artificial timeline, not the manager. The manager just enforces the artificial timeline.

A developer themselves can hold themselves to an artificial timeline. It takes discipline, and patience, to choose quality over speed to market.

CEOs and managers almost always prioritize time to market, over quality. That's the problem.

Most projects (not just software) never ship unless there's a deadline. For example, how many students complete their term papers weeks before they're due? If there was no due date, how many would ever complete them? I know I never would have learned much of anything in college without deadlines and exams.

Of course. I'm not advocating for no deadlines. I'm advocating for flexibility.

If your deadline arrives and you can honestly say you've worked hard but haven't met it, consider extending the deadline in the name of quality.

Again, this takes discipline. You have to be honest with yourself if you are just moving the deadline back because you were slacking. In my case many times, the deadline was not hit because the scope of the project was underestimated. We were working hard on a new technology stack, but missed the deadline. Rather than delay the product, CEO decided to launch (despite our warnings).

Needless to say, the brand suffered.

I understand its a tug of war. Managers need to put out something. Engineers are never ready. The art in it all, is finding the balance. Being flexible to listen to your engineers, and knowing them well enough to trust them.

In the various industries I have worked in DO-178B, industrial controls/IEC-61508, and storage the one consistency shared by managers is meeting schedules and milestones. Generally, a manager's insight to development/engineering is for the product to be just good enough. Developers/engineers have a tendency to over engineer the solution. Good peer reviews have the most influence on software quality as does independent testing. Managers rarely have little impact that I have witness over my 25 year career, thus far. For industries that adhere to DO-178B or IEC-61508 guidelines, it is the process that imbues greatly improved quality.

Yep, 61508 is basically a specialized form of IS0 9000 quality management.

And independent testing really makes a difference, I am trying to introduce automated testing into my company at the moment, they still spend a month with buttons and lights testing a safety system.

I have been getting blank looks when I ask how they test for single scan events like this. But I know of several industrial incidents resulting from common single scan software design failures in safety systems (usually order of execution issues, but sometimes the flitter logic of oneshots is the cuplrit).

One single scan incident in particular was from equipment in service for over 10 years, and then the stars suddenly aligned and the resulting software failure event ended up costing a big miner well over a billion dollars.

I have frequently seen standards, guidelines, and "process" prevent improvements to code. Since change is considered risky, it takes more time and effort to document improvement than the individual change is worth.

But software improves, when it does, by a series of small changes, each by itself hardly worth doing, but in sum producing a wholly better product.

It is the process that turned lizards into birds.

Businesses would not employ expensive managers if the dev teams worked better without them.

[citation needed]

idk man, my code is pretty damn clean

I think my code is cool, too, until I look at it again 5 years in the future.

There's your problem — you're releasing too early. :-)

Code cleanliness has no correlation with lack of bugs. Also, 1) your sample size is pretty small, and 2) what looks clean to you might very well be despicable to someone else.

And more importantly in this case, the appearance of your code is relatively meaningless compared to you failing to consider all cases of inputs.

Honestly, the appearance of code is irrelevant. The goal is to absolutely accurately meet the requirements - the true, actual requirements. It may not be within scope to know all the information you need to know to cover all the cases, and that's certainly a problem. But the cleanliness of your code, assuming it functions correctly, is unimportant to the operation. (It certainly will be a maintenance cost, though.)

The actual argument is that code cleanliness improves readability which in turn makes finding bugs easier and also eases the conceptualizing of what the code does. I'd say it's first line of defense against bugs.. tests could miss bugs too but that doesn't mean we shouldn't test thoroughly

I guess that was a poorly chosen word on my part then. How about 'elegant'.

"Elegant" does't mean "right" either.

But with elegant code it is often easier to tell if it's not right, and also how to get it right if it's not. Often that requires making it less elegant, because the real world rarely poses elegant problems. You want to ensure that as much as possible of the necessary inelegance is at the top level, with everything below clean.

At my current company all leadership is in agreement that it is more expensive to deal with bugs in production.

But CD...agile...

It really depends on the scenario. If you can bill those fixes to the client or if you have to eat the cost to make the fixes. Most modern development processes seem to push this model simply because they can essentially pass the costs to the client and charge other or future clients for the improvements.

We charge upfront for someone to use the product and negotiate any feature requests.

One the other side, unless you are an artist and not dependant on your software actually being used, you have to get product out at some point.

It's easy to demonize CEO and managers. We, as devs, will always find an excuse as to why the software is not ready and QA will always find new things to test to justify not putting the software out.

If you have fully defined what your software will do up front, then you are finished when have made it do what you said it would.

Safety critical software is usually designed, built and tested to the V-model.

When done properly every piece of logic/code can be traced back to a requirement through all steps and phases of development and testing.

There is no "move fast and break things" in the safety instrumented field, the engineering hours per byte/instruction delivered would absolutely flabbergast most software devs, by many orders of magnitude.

It depends on the real world effects of pushing software out. If the side effects are minor and its perfectionism, then sure, push it out ugly.

If it's a safety control mechanism for a car or airplane, then perfectionism needs to be applauded over faster time-to-market. If it's another chat application and changes can be easily rolled back, then push it out warts and all.

I think that 'can safely ship' is primary feature of any software project. What the means in practice is it puts pressure on new features and 'refactoring'

> As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts.

Do you use formal methods to prove the correctness of your code?

Because that is what Boeing engineers do (I hope).

You would indeed hope. But then again, look at the Toyota ECU issues ... and the subsequent code review as part of the court case ...

"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth

It's not the logic that's the problem as much as the fact that the systems are meant to work with clean data, and the fact that data could not just be missing, but straight up incorrect was never considered as a valid possibility. This was made worse by the fact that the poorly formulated "solution" was barely communicated to the pilots. I saw somewhere that the plane could be unrecoverable in 40 seconds. You need to have bigger safety margins than that.

40 seconds is an eternity to a pilot taking off or landing. Even Air France, taken down by a plugged pitot tube from cruise altitude, was doomed after only two minutes.

Airbus has a lot to answer for on that one: averaging inputs from the pilot's and copilot's game controllers? Game controllers? Turning off the stall warning in deep stall, so that starting to recover sounds it again? Failing to teach pilots what stalls are, what they feel like, and how to prevent and recover from them?

There is more than enough blame to go around for that one.

The Boeing software, like the Airbus's, apparently performed as specified, so there was no problem with execution of the spec. The problem was that it was a bad spec, in too many ways to count.

The most efficient way to do it is to do it once.

Which leads to the heart of the discourse: programming is many things at once. Programming a single purpose library or module who has to do one thing and this one thing as good as possible demands efficient and sustainable solutions. Theoretically if you get that kind of code just right, you don’t have to touch it again for a long time.

On the other hand you have code where the codes environment is so volatile or ephemeral, that developing the appropriate code isn’t possible, because you are aiming at a moving target. This often demands faster solutions, shims, code that was never really meant to be maintained etc. Sadly many companies have a culture where these shims become like glorified tradition and a few years down the line you have a pile of shims that nobdy sane is willing to touch.

However there are situations where fast solutions make sense, e.g. because it is a one time thing or it doesn’t really matter that much etc.

That is definitely not true for all tasks, and especially not all software engineering tasks.

Indeed, but the prereq is that you know the need absolutely and correctly initially. And you usually don't.

This was not buggy software. This was a bad specification. The software did what it was supposed to do.

Anyway, specified to do.