I've had an idea brewing in my head for quite some time, and while I still don't quite have the words to express it completely, it more or less boils down to this:
There isn't necessarily a correlation between being a good programmer and shipping a successful product.
Now of course we can argue over the definition of "good programmer" and "successful product".
I started as a hobby programmer in my childhood and teens, then went to college, and since then have written code for various companies. For several of the earlier years (including college), I had this wide-eyed fantasy of the brilliant, beautiful code that I would work on once I became a "Real Programmer" (whatever that means).
My hopes and ambitions shattered once I got into the workplace and discovered some of the slop that I had to maintain. Then for a few years I was on a crusade to banish all ugly code from whatever project I happened to be working on at the time.
Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use. I don't really know much about the internals of minecraft, but I do know that nearly half of the teenagers in my neighbourhood spend hours and hours playing minecraft.
I have to admit that I'm still an idealist at heart, and of course the best situation would be to have a project that is both externally successful and well-designed (making it simple to fix bugs and add new features and such), but I'm constantly having to remind myself to stop trying to get everything perfect and just write code.
> Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use.
It depends on the use case and business model of your software.
If you want to ship a single version of something then don't worry about code quality. If you're market testing and will get resources for a rewrite if the product takes off then again speed to market is more important than code shape.
But if you want to enhance the software or tune its performance then you need good code structure.
Agreed - nobody is arguing that throwing together sloppy code is always a good thing. Mostly I'm just saying that some amount of sloppy code isn't necessary a bad thing. Like you say, the amount of sloppy code that you can get away with depends on what you are doing.
There are vast discussions about this both online and in books, referring to "sloppy code" as "technical debt". Just like monetary debt, sometimes it is worth taking on a significant debt, while there are other times that it is best to avoid debt. It's a judgement call either way, and I've found that I tend to err on the side of being too scared of technical debt.
Software engineers have an unfortunate tendency to accumulate technical debt and then run away from paying it. I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. The dichotomy between quality and speed of development is often an illusion anyway.
I find it fascinating that elsewhere on this thread somebody expressed the opinion that "overengineering ... kills more projects than anything else" and here you express the opinion that a much worse problem is engineers bailing out after running up technical debt. To be honest, I really can't say which is worse, I've had to cope with both of them from other people. All I can say is that my tendency is to overengineer.
Like I said, I think it's a false dichotomy. Most over-engineered projects I've seen also had ridiculously sloppy code. Over-engineering usually concerns design. Sloppy coding usually concerns implementation. The code at a different stage of development, so it's possible to have both or neither.
I've seen this way, way more often and with far worse overall cost than any kind of perfectionism.
I'm not intending to be some sort of advocate of purportedly bad code, but I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed: You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world, while perfectionists are still busy arguing over trivia.
This is the survivorship bias at play. Organizations accumulate "technical debt" because the only code that gives that any assets has such realistic downsides.
And while you account for the cost, you say absolutely nothing about the benefit/"earnings", which is a typical analysis of people who work on other people's code.
I have created a lot of terrible code in my career, almost always doing greenfield development.
This was code that was spun out under incredible conditions, where we had no idea what our product was going to be, the parameters of the data or the conditions that it would be used in, etc. We had changing dev environments and assumptions, libraries getting tossed and new ones added, etc.
And those projects built companies. And it was always novel hearing someone ranting about technical debt years later, when they were hired in a position and on a team and in a company that only continued to exist because of that solution. Debt indeed.
I've worked with good code and bad code. Where there was good code, programmer turnover was low and the original programmers were still around.
Where there was bad code, turnover was high and the original coders were long gone, the impression I often got was they'd coded themselves into a corner and it was too much for them.
I honestly think places with bad code just have to keep burning out more and more programmers until someone good enough to dig them out of the hole comes along.
The most successful company had the worst code written by incredibly incompetent programmers who didn't even know basic things. One of their products the programmer was so clueless he'd created a new project and DLL for every single class. Every single class. Still made millions.
There are very few coders who can write and design a large product from scratch. Hence far more bad code than good. I think that's the more likely explanation.
Your post has many implied dichotomies and correlations that simply aren't true. For example:
I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed
Not really. It simply shows that bad software is commonplace and often not important enough factor to kill an entire company. It still costs companies a fortune in maintenance, client dissatisfaction and employee turnover rates.
You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world
Uh, again, no. Bad code often begets bad UI, confusing process for the users, botched transactions and a never-ending stream of database tweaks and patches. I've seen plenty of projects whose overall value to the company was negative. Problem is, that negative was spread throughout large period of time, whereas a proper update or replacement of the system would be concentrated in a much shorter time span. This is where "debt" analogy works very well. Some code is like that credit card you maxed out, but only have enough money to do minimum payments.
I have created a lot of terrible code in my career, almost always doing greenfield development.
Whether you created horrible code is largely irrelevant. What's important is what is your overall trend. Some developers pull the code quality up over time, and them maintain it at some reasonable level after that. Others slowly turn anything they touch into radioactive waste.
I'll just leave it at this -- despite protestations to the contrary, I would wager that the majority of developers, if not the overwhelming majority of developers, claim to do no wrong when coding. They claim to plan and design and develop with best practices, creating clean, maintainable code.
And those same developers almost universally declare the majority of code they come in contact with to be toxic waste. Terrible code that brings down companies and kills careers (this whole hilarious discussion began with someone lamenting about the code that Notch burdened Mojang with. The code that is the sole reason for that company existing. What a horrible burden).
These claims do not mesh. At all. There is a reality that is profoundly different from what people say.
This reminds me of how some people argue that morality is hard, because everything is relative, while doing thing they themselves clearly do not consider "right".
Aside from a few inexperienced or delusional engineers, most people I've seen in my professional life are cognizant of the quality of code they produce. The main difference is in how they respond to the cases when that quality dips below a certain level.
To me the real question is not about shipping products vs good programmers. There is is a much more important question when it comes to writing ugly or pretty code:
Does it work and will you maintain it?
In my experience I often had to often fix dozens of critical bugs of "getting things done" programmers.
I often hear "I will fix this later", "I will refactor it later", "but it works", "we can write tests later", "I will comment/document later", "I will clean up later" from these people giving it to maintenance programmers who rewrite the stuff, cause it is too ugly to deal with.
That's a big problem. People write code and other people have to fix this "but it works" code. Great, when you have a node.js application only running cause there is try catches around things hiding all the errors, killing the logging back end.
If you are the only one to read the code than it's fine to do whatever you want with it, as long as it works. But usually code that really works is well-written, well-commented, tested, etc.
I've had an idea brewing in my head for quite some time, and while I still don't quite have the words to express it completely, it more or less boils down to this:
There isn't necessarily a correlation between being a good programmer and shipping a successful product.
Now of course we can argue over the definition of "good programmer" and "successful product".
I started as a hobby programmer in my childhood and teens, then went to college, and since then have written code for various companies. For several of the earlier years (including college), I had this wide-eyed fantasy of the brilliant, beautiful code that I would work on once I became a "Real Programmer" (whatever that means).
My hopes and ambitions shattered once I got into the workplace and discovered some of the slop that I had to maintain. Then for a few years I was on a crusade to banish all ugly code from whatever project I happened to be working on at the time.
Lately I've realized that having pristine, elegant code is NOT the goal. The goal is to ship software that people actually use. I don't really know much about the internals of minecraft, but I do know that nearly half of the teenagers in my neighbourhood spend hours and hours playing minecraft.
I have to admit that I'm still an idealist at heart, and of course the best situation would be to have a project that is both externally successful and well-designed (making it simple to fix bugs and add new features and such), but I'm constantly having to remind myself to stop trying to get everything perfect and just write code.