Hacker News Reader

“Bad code that ships is better than good code that doesn't”

Maybe better for your bottom line (no criticism, we all have to eat), but not better for the world. Look around at our software universe: bad code that shipped, everywhere.

Bad code that ships gets us Windows.

But good code that doesn't ship gets us nothing. Awful as it is (and especially as it was), Windows was good enough and cheap enough for a whole lot of people to be able to afford computers that they could use.

This assumes that bad code is, at worst, worth nothing which isn't the case. Bad code that crashes a mission critical system is absolutely worse than nothing. Or to take your Windows example, I could argue that the problem with Windows was the opportunity cost. If Windows didn't take over the world maybe we would have more choices when it comes to desktop OSs

No. Bad code that crashes a mission critical system may in fact be worse less than nothing, but my argument doesn't assume that. It assumes that Windows, though bad code, was still worth more than nothing. What's more, it takes the massive success of Windows as market-based evidence that Windows was worth quite a bit more than nothing - or at least, computers running Windows were worth something.

Opportunity cost isn't usually considered in terms of a market, it's considered for an organization. If Microsoft hadn't done Windows, could they have done something more successful with the resources? That's pretty hard to imagine. Certainly you can say that Windows was bad for (the rest of) the desktop OS market. But the fact is, no mind control rays were involved. Microsoft created an OS that unlocked enough functionality for the average user, for little enough cost, that Microsoft took over the world. (Yeah, I know, lock-in and monopoly shenanigans. It's true. But none of it would have mattered if the OS were not good enough to mostly work for most people.)

I can't believe I'm being an apologist for Windows. Gack.

Yeah, fair enough. I guess at least from MSFTs perspective bad code was better than nothing.

> Bad code that ships gets us Windows.

as much as an enthusiast linux user I am, I'm pretty sure that the world would be a worse place without DOS & Windows

How so? I mean, obviously it's impossible to make a decent educated guess since basically the entirety of most peoples' interactions with computers stems from the near-monopoly Microsoft had on personal computing in the 90s. But I'm still curious to know what you predict would be different if MS didn't strike their deal with IBM.

MS Window's presence in the market made PCs true commodities and drove down the price for home and office computers in a way none of their contemporary competitors would have achieved.

Most of their competitors were tied to hardware, and received a lot of their revenue and profit from the combination of hardware and software sales. MS only needed to sell the software, and let HP, Dell, Gateway, and others compete on hardware prices. This probably put more computers out there (within that time span) than would have been achieved without them.

It's less about the deal, and more about MS following a pretty strict philosophy that if your software, the software you bought runs on OS version X, the only reason it may not run on version X+1 is a dumb bug in the software.

Also they kept at "computers accessible to everyone", and as much as they fought competition, I have to admit they did it.

> How so? I mean, obviously it's impossible to make a decent educated guess since basically the entirety of most peoples' interactions with computers stems from the near-monopoly Microsoft had on personal computing in the 90s. But I'm still curious to know what you predict would be different if MS didn't strike their deal with IBM.

I've occasionally seen speculation that in the absence of the de-facto DOS monoculture that deal created, CP/M may have been the most likely desktop platform winner, at least initially.

“Bad code that ships is better than good code that doesn't”

When you work on code long enough two things will eventually happen:

  Shippable Bad code will eventually be unshippable.

  Unshippable Good code will eventually be shippable.

Your quotation simplifies a concept by hiding the extra dimension of time. Bad or good, shippable code depends on a point in time.... It could be shippable now, or shippable in the future...

Pretty terrible example.

Bad code gets us the most used, most popular desktop (and maybe server, definitely server for certain industries) operating system in the world? Mac is great, I have one, but Apple made it's cash stores on the back of the iPhone, not MacOS.

IMO MacOS is not an example of good code, or good engineering.

The engineering decisions made are often terrible, including recycling the legacy of NeXT for what I assume were ego-based reasons...

Nothing in the history of Windows compares to that scale of bad.

I wasn't clear, I didn't mean to imply that MacOS is technically better than Windows, just that Windows is by far the most popular OS and was trying to cut off any rebuttal boiling down to "but I use a Mac."

> Bad code that ships is better than good code that doesn't

But for how long? At some point, the technical debt that comes along with rushing out bad code will come back to bite you. You might be able to get a workable prototype for cheap but if it's a project that you want to sell and support long term, you may just be setting yourself up for failure down the road.

I think you misunderstand what "correctness" is really about. To me at least it's about creating a small set of powerful abstractions that can be applied generally to any problem. In order for those abstractions not to "leak" they need be really rigorously defined. The alternative I think is to have a lot of ad-hoc abstractions for each application that break as soon as requirements change. I really, really disagree with the idea that bad code that ships is always better than code that doesn't. That is how we get software that is riddled with security issues. Even if the specific application isn't that important, it very well might be a major catastrophe if it has a severe security vulnerabilities that allows an attacker to get a root shell on a server in your internal network.

> I really, really disagree with the idea that bad code that ships is always better than code that doesn't. That is how we get software that is riddled with security issues. Even if the specific application isn't that important, it very well might be a major catastrophe if it has a severe security vulnerabilities that allows an attacker to get a root shell on a server in your internal network.

Your argument fails to be an argument at all.

Can you justify that first sentence? I do not see any convincing reason why you disagree... or even any reasons here tbh.

I assume by first sentence you mean the statement that "That is how we get software that is riddled with security issues"

The argument is that you assume that the minimum value of code is zero, so that any code that ships has to be better than code that doesn't ship because at worst it is worthless, which is the same value as code that doesn't ship.

My point is that bad code can be worth less than zero if it actively causes harm. So for example, code that has a critical security vulnerability which leaks personal information is worse than nothing. You would be better off not shipping anything at all than shipping something that causes actual harm.

You are completely jumping to the conclusion that when the author says "10x better" he means some dimension that you do not care about.

Programmers care about productivity too. And when somebody puts a number as in "10x better", that is usually the metric they are talking about. (Although this one seems so fuzzy that the statement is meaningless.)

I don't know many programmers who are jumping to use Haskell for their personal projects. What you use at work is usually determined by the surrounding infrastructure but at home you can use whatever you want for productivity and yet most people continue to use their favorite non-functional language. If it's really 10x better and can overcome network effects then shouldn't we see a lot of Haskell personal projects?

Did you read the article? This exact argument is made and an entire book was written to address it.

> I don't know many programmers who are jumping to use Haskell for their personal projects.

If you don't use Haskell or are suspicious of it, would you expect to know other programmers who use it?

We have data that can more strongly make the opposite claim that people do use haskell for personal projects:

> The functional language Haskell is the tag most visited outside of the workday;

https://stackoverflow.blog/2017/04/19/programming-languages-...

I think for a chat app Haskell may not be useful(but note that whatsapp was built on top of Erlang, a somewhat functional language)

I think Haskell and other functional languages can really improve software in domains with complex business logic and rules which is most of the software that deals with the real world and is useful to the world.

Correctness does actually matter a lot in software, nobody would trust a calculator that doesn't give the right results. Ofcourse people can tolerate edge cases but it's far better to remove them upfront.

As a professional Haskell programmer for a bit now, I see no problem with a chat app in Haskell.

In fact, something close is wire[0] whose server source code is here[1].

They are a secure alternative to slack and mattermost for the curious.

0: https://wire.com/en/explore/competitive-advantage/ (this gave the best explanation in the comparison section of what it actually is imo)

1: https://github.com/wireapp/wire-server

This notion that functional programming is about correctness kept me away from static types and FP for the better part of my career.

I mean - who cares about correctness when I'm trying to ship yet another cookie-cutter web application that I don't even know is going to see more than a thousand users in its life.

What I cared about was speed. A few bugs in production is a better trade-off than all the mathematical mumbo-jumbo and slow, meticulous programming that Typed FP seemed to demand.

But to my surprise, after getting started with ReScript/Reason/OCaml, I recognized that correctness is just a side-effect (!) of this mode of programming. (Note that unlike Haskell, OCaml is an imperative programming language with as much or as little mutation as we need. We can almost line-by-line translate a regular mutation-heavy piece of Python or JavaScript code to OCaml, if we wanted to.)

Typed FP, contrary to what I'd came to expect, is all about speed. Quoting from something I wrote a while ago:

"Refactoring a typed FP program is safe, but menial. When we say safe - it means no anxiety. There is going to be tons of mechanical work for every major type refactor - going thru all the compiler errors and fixing them one by one. That can't be avoided. We've been in multi-day refactoring sessions where we had to dredge thru page after page of compiler errors before we could even run the application. But - it is safe - we know that once it compiles, there won't be any mistakes.

That gives us the freedom to build fast and loose - and take stock periodically before we have to abstract things out and tidy up the place. We should compulsively rely on that safety. Typed FP forces us to go slow in places where a dynamic environment would've allowed us to blaze through. For all that trouble, we get unmitigated refactoring dexterity and we must exploit it to benefit from the paradigm."

There are many places where a dynamic, imperative approach is faster than a typed FP approach. But there are as many or more places where it is the other way round. I'm now fastest with this way of programming than anything else, and I wish that more literature around Typed FP communicated this rather than go about the indirect route of correctness, and expect people to pick up that correctness-by-construction results in increased velocity. That's a difficult jump to make unless one has written non-trivial amount of code in that style.

This book by Sandy - I've read the introduction and skimmed thru the Tile construction equations - is to me poetry. I'm having trouble fitting in the idealistic notion of the Escher tile to my imperfect real-world domain, but otherwise, what a book!

> I mean - who cares about correctness when I'm trying to ship yet another cookie-cutter web application that I don't even know is going to see more than a thousand users in its life.

I feel this perspective, but I don't understand it. To me, correctness means that the program is actually doing what it's supposed to. If we don't care about correctness, isn't the particular program we're writing pretty arbitrary?

Correctness doesn't seem like some ivory tower ideal to me. I want to write software that meet a need for my users. Writing correct software means uncompromisingly meeting that need.

Correctness and robustness happen to all software, when exposed to end-users for a long enough time.

Internally the software would be a ball of mud, a fragile patchwork of incoherent code that nobody wants to touch. A lot of these programs become immutable logs - if you want to change a feature, you add more code because you're afraid to touch anything that already exist.

Yet they are robust - all the bugs in the commonly traficked code paths have already been sussed out, and from outside the software looks like an impenetrable, rugged piece of craftsmanship. This has happened to me in the early years of my career (proud of the robustness, not proud of the code), and I've witnessed it so many times outside. So yeah - robustness and correctness is either a matter of correct-by-construction, or correct-over-time.

> Yet they are robust - all the bugs in the commonly traficked code paths have already been sussed out

There are two ways this can be true: if the code paths users traffic are debugged, and if users only traffic code paths that are not buggy. In the end, all and only the code paths that are used are useful. Isn't that a truism?

Like I said, I feel this perspective (and thank you for responding!). But I'm kind of sick of working on codebases that are absolutely littered with dead code paths that are hopelessly interwoven with live code paths, to the point that when you know you're breaking something, you hope you're only breaking something that isn't used. To me, it's a really depressing, fatalistic worldview.

> A lot of these programs become immutable logs - if you want to change a feature, you add more code because you're afraid to touch anything that already exist.

Amen to that. Can we as an industry find ways to do this better in the first place, instead of resigning ourselves to "immutable log" as an inevitability?

I'm naive, but I think the adoption of Typed FP, and the resulting cultural education and change, is one route to solving this problem. But it is a social and economic problem more than anything else. Or I guess - since the spectrum of competence in other fields of human endeavor is distributed widely (a bell curve?), we'll have to expect it to happen to software as well. Not a very optimistic thought, but at least we can be content with what we have :)

> Yet they are robust - all the bugs in the commonly traficked code paths have already been sussed out, and from outside the software looks like an impenetrable, rugged piece of craftsmanship.

I disagree. I think they only feel robust. I think more importantly this mode of development is defensible and always gives one something concrete in the case of being asked "so what's the product of this 3 days of work?".

Over the past couple of years I've become proficient with haskell and can throw out an arbitrary program with it about as easily as I could with Python, which I have 10 years of experience with. I've built and worked on large real-world projects for both, and I've noticed something quite interesting at the threshold of when it becomes too complex to comprehend how all the logic interacts. With python I feel a mild panic, because I know that all I have are tests and human QA covering a rapidly shrinking fraction of possible use-cases. Adding features beyond this point can sometimes feel like groping in the dark, perhaps with a debugger serving as a candlelight.

On the other hand with haskell, I know that most functions I write are completely deterministic, and will never have runtime exceptions regardless of how complex the compositions are. I can engineer my application to contain perilous code in a well-defined minority of functions and use rigorous testing to make sure they're right. There are many other excellent safety features, but these in particular give me a huge peace of mind.

In summary python excels when you need to do a simple high-level tasks like send an email or run a small REST API, but the development rate falls sharply when the logic and state is deeply composed. In contrast Haskell with its static-types, immutability, terseness and emphasis on safety (in both the language and library ecosystem), lets you maintain development velocity far beyond.

> Bad code that ships is better than good code that doesn't.

Sometimes, but not always. The bad code that ships however always feels better and gives the feeling that progress is being made.

That works fine until a wall is hit and things have to be rewritten or worse hacks have to be added. That ends up taking more time than the original solution, but guess what... no one is going to bring that up.

That means the correct solution never has a chance to get the points it earned to be weighted more highly next time a decision of correctness vs speed is made.

There are pre-built frameworks for handling the common "ship the bad code, never say it's so bad it's a net loss, and just iterate on the crap on top of crap you have" so that all levels of the organization feel more comfortable.

> With all that said, I do wish that we had better software, and that correctness mattered more.

It can't matter until technical debt is analyzed on a meaningful time scale and actual observations happen, rather than what amounts to making things seem like they're going smoothly.

> Bad code that ships is better than good code that doesn't.

Logical fallacy: false dichotomy.

What about good code that ships? Best of both worlds.

Note: Before I possibly get railed for not knowing functional programming or anything like that, I actually really like functional programming, for a limited set of applications (mostly compilers, and other algorithm heavy stuff).

> What about good code that ships? Best of both worlds.

Right, but what is good code?

The author of this page claims that code out of the "Algebra-Driven Design" paradigm is good code. But where's the proof?

It's not enough to pull out the math textbook and give us fancy words like monoids, lattices, whatever (this is coming from someone who loved algebra classes far more than analysis classes in my math degree).

I'd really like to see real world code that uses this. And by real world code, I mean code that isn't some contrived example, code that actually runs somewhere, and provides real-world value, e.g, a semi-popular website, e.g HN, Lobsters, Reddit, or something that runs on a robot, or something. I don't know. The common theme of all of these Haskell/Idris/SomeOtherMathyLanguage posts is that almost none of them bring any real world software to the table, that has been tried and tested by the real world, e.g, consumers, customers, whatever, except for a perhaps GHC, a handful of well maintained Haskell libraries, the Idris compilers, that Haskell spam filter at Facebook.

We keep saying that functional programming is much better than any other paradigm. But the share of functional programming languages is tiny in comparison with the imperative/OO family languages, and there's a reason for that. Most functional languages are hard to use, have very little library support, and functional abstractions don't _really_ matter in the long run when it comes to bugs. Sure, C/C++/Java code is never bug free, but it's not tremendously difficult to write real-world applications using these languages, simply because of how well their memory models/object models/features map to the way most programmers think.

I just find it absurd that on these functional programming posts, everyone just keeps saying that the only good code is functional code. It's simply not the case.

Facebook rewrote the Messenger in ReasonML. Before they got hundreds of bugreports a year. Afterwards? Less then ten.

I worked on a 6 month rewrite of the core of a system. Critical bugs were drastically reduced. We rewrote in the same language.

I would much rather use ReasonML than js but the Facebook result unfortunately doesn't prove much.

Monoids: Map-Reduce and Hadoop

Monads: future chains, streams/sequences

Immutable data structures: the transaction log for distributed databases

> C/C++/Java code is never bug free, but it's not tremendously difficult to write real-world applications using these languages, simply because of how well their memory models/object models/features map to the way most programmers think.

My argument that it has nothing to do with object oriented mapping to the way most programmers think, and is almost totally a function of familiarity.

Very good point. A lot of the bad code I have seen doesn't ship _because_ it is bad. It can't even get through the testing phase because it is full of crashes type thing. Whereas good code usually has a good design that results in _less_ code and development speeds up as you go on. So the end of the project feels like putting cherries on top of a cake instead of trying to balance cherries on stilts.

There's more to coding than churning out business logic. Even if not used in production, learning a different paradigm can have an enlightening perspective on ones ability to solve a problem.

Can you help me understand this logic - what business can make money off of software that doesn’t work?

Well, eventually it has to work. But if we write a buggy Python program in most industries, and it breaks, the customers complain a bit and you fix it.

I suspect what the parent means is there are some industries where you can't afford for it to break at all. I.e., you don't need to guarantee correctness.

Bad code still works. It may not work well in some regard:

- Hard to maintain

- Slow

- Hard to extend (slightly different than maintain, but related)

- Crash-prone (but infrequent enough)

- Corrupts data (but infrequent enough)

- Just wrong enough to be annoying but not wrong enough to be useless

I had colleagues on a project (I really wanted to help them fix it, but was never brought on board) that was truly bad code. There was copy/pasta everywhere. The same function written a half dozen or more times with slight differences (or none, no idea why it was copied in the first place), so bug fixes would partially address an issue but not when all copies weren't fixed. It was massive (hundreds of thousands of lines by this point, maybe over a million now) with mostly new team (original coders were contractors, and original team for us all moved on). The size and quality made it hard to extend in a sane way because there were so many unknowns. It had random concurrency issues which would only crop up reliably when fielded.

The fundamental design was flawed. They had to connect N different protocols (each different but communicating the same kind of information) to each other. Instead of coming up with an intermediate format they did 1-to-1 connections, which meant an explosion in complexity. Instead of N translation units to an internal format and N translation units out, it was N * (N - 1) translation units, every protocol needed a way to translate to every other. The sane way would mean adding a new protocol required 2 new translation units, the insane way required 2 * N (the new protocol to all existing protocols, all existing protocols to the new one).

It shipped, it made millions (in revenue) every year, but it was not good code.

You specifically said correctness. You brought up speed and maintainability. I specifically want to know how _incorrect_ code, which is code that doesn’t perform its intended function, can make a business money or have any value at all.

The project I described is arguably incorrect, it did not fully satisfy the customer needs for many reasons. It was unstable, it had errors in its outputs, but it was correct enough that they still bought it. It brings in millions a year in revenue, even though there is competition (though not much) in that niche market.

There is a wide span between totally 100% correct and totally 100% incorrect code. Most software sits between the two.