6 ms·

One of the depressing things about code is that it is astoundingly easy to build something that does amazing things in controlled circumstances but is otherwise

One of the depressing things about code is that it is astoundingly easy to build something that does amazing things in controlled circumstances but is otherwise practically garbage. Promotions, venture capital, and all other manner of rewards can result from said garbage. The “real work” is in figuring out how to move forward from something like that, and lots of stress comes from trying to do so without breaking anything. There is little reward in maintenance. “Good enough” is really the type of attitude that leads to this unfair balance of effort. Unfortunately, we live in a world where criticism is levied very heavily on where you are now, and not on how you got there. What, version 2.0 of the product sucks now? Screw it, “1 star”, boycott this; fire the team responsible! Never mind the fact that version 1.0 was a rickety mess, all of those guys left, and anyone would be lucky to get the thing working at all, much less in a way that does not introduce any new bugs. One of the big benefits of open-source is having a chance to understand what’s going on. Would as many people invest in a product, despite promising behavior in version 1.0, if they could see a critical review of how that version was actually implemented? Ideally, we can see not only how a product appears to work, but how well-engineered it is according to experts.

logicallee 10y ago
> The “real work” is in figuring out how to move forward from something like that, and lots of stress comes from trying to do so without breaking anything. I'm a lot more impressed with the evolution of the human species than how doctors have been able to maintain those running systems. You want to design a human from the ground up using proper infrastructure that doesn't have ailments or diseases go ahead. you'll be lucky if you end up with a fruit fly.
- smt88 10y ago
  The human body is the result of 1,000,000,000,000,000,000,000+ organisms dying before or after reproducing. That's evolution. It has absolutely nothing to do with the "maintenance" that doctors perform on the human body, especially when doctors are loathed to lose even a single organism. I'm not even sure why I responded to your comment, since it was so random and unrelated to the rest of the thread.
  - cocktailpeanuts 10y ago
    If you think it's so unrelated, then maybe you didn't understand what he was trying to say? Doctors are necessary and important and deserve to be paid well, since they deal with life. But that can be done by anyone really. I'm not saying any idiot can become a doctor, it's that most doctors do what any other doctor can do. I'm not interested in those things either. I would rather work on something that can change how people live their lives--which one could arguably say is close to evolution.
  - logicallee 10y ago
    It means you didn't understand my comment. >The human body is the result of 1,000,000,000,000,000,000,000+ organisms dying before or after reproducing. I guess I have to spell it out. "Bad, unmaintainable code" is the result of 1,000,000,000,000,000,000,000+ random requests being shoehorned in without proper design of the whole thing, but just on the basis of whether it still works or meets some last-minute requirement. I hope this makes my analogy clearer. (I realize the number is an exaggeration, I am referring to the process involved in "evolving" code, rather than "properly designing" it.)
chjohasbrouck 10y ago
There are definitely organizations where code that works but doesn’t appropriately account for those uncontrolled scenarios will earn you nothing more than a bad reputation. I’ve seen this happen, and I’ve seen their name slowly drift to the bottom of the list when it comes time for a raise or promotion. I’m generally surprised at how little interest VCs have in this, though. I think a sizable percentage of their misses could’ve been avoided altogether if they had just audited their prototype, or whatever they’re claiming qualifies as their MVP. People generally don't understand how many different scenarios software needs to account for, and how quickly those inputs can exponentiate into a very big and complex task. Creating the appearance of functional software takes a very small fraction of the time and expertise that it takes to actually make something production-ready, but I don’t think a lot of non-developers understand just how big that gap is.
- kazinator 10y ago
  Software VC's don't have to care about code being crap that only demonstrates well in a particular set of circumstances for exactly the same reason that mining VC's don't have to care that the same fraction of gold is found in every cubic meter of the company's mining site as in the handful of lucky drill samples. Those VC's can pump and dump: promote the stock stock, then dump it before it dives. The people that have to care are the company officers who want to grow a successful business. If those people are cynical, then the venture is probably doomed.
abakker 10y ago
This isn't just in code these days. I'd call it the Ikea phenomenon. Things that look functional and act functional in a constrained set of circumstances, and are deemed as good enough. The cost is often proportionally low, too. (ever tried to move a fully loaded Ikea dresser?) But, as you've pointed out, the real work is in maintenance, durability, and quality, not veneers.
- Hupriene 10y ago
  Arbitrarily relocatable furniture tends to be made of steel and weigh 300 lbs. I think the extended metaphor works for software as well.
  - duerrp 10y ago
    That's a great metaphor...
cocktailpeanuts 10y ago
What you say is indeed important, but I wouldn't say the work before that is not "real work". It's just different types of work. Ask any successful startup founder what their initial codebase was like and they would say--if they're honest--it was shitty. There's a reason for this. The "real work" you mention comes into play only after the product has reached product market fit and needs scaling. Before that phase, it's all about struggling to make things work, and people don't have time to refactor everytime they need to make a small tweak and experiment. So naturally by the time the "real work" guys come in they will think "WTF the code is so shitty, whoever wrote this is an idiot". But they should know that they're there only because of that shitty code. If they were in that same situation (and rational) they would have done the same thing--write a consequentially shitty code.
- Retric 10y ago
  Early work is closer to a lottery than anything else. If you only look at winners you will end up with a distorted view, but right product, right time, right market is more about luck than skill. MVP is all about validation because there is no way to judge good vs great before you build it. So, the only way to improve odds is to just roll more dice.
  - im_down_w_otp 10y ago
    You can still write great code (meaning: clean non-leaky abstractions, proper separation of concerns, functional testing, clearly organized, and unintuitive bits documented) without having market validation, and I'd suggest that doing so will actually make it a lot easier for you to shift the pieces of the project, remove them, rewrite them, extend them, etc. as you start to hone in on the marketplace fit, and doubly so as you need to start growing your development team and need to on-board them effectively so everyone can be productive without just rapidly accruing compound interest on the technical debt that's already there. It doesn't take that much longer to write great code when it's just part of the first-principles of your engineering process. You just do it as you go, but best-practices need to be scaffolded and modelled for everyone beforehand to give them a solid starting point for what "minimally viable" actually looks like. A single well-placed sentence that describes something necessary, but non-idiomatic or non-obvious, that takes 10sec to write can save you hours or days of tracing and debugging at that crucial moment right before you're onboarding a pilot customer or pitching investors. Very often the bar of "minimally" is set way, way too low and the trope of that just being "startup life" is usually just laying problems at the feet of engineering that don't belong there by justifying, sometimes horrifying, technical debt which are really process and management failures, and later eventually scapegoating engineering for it.
paulcole 10y ago
"version 1.0 was a rickety mess, all of those guys left, and anyone would be lucky to get the thing working at all, much less in a way that does not introduce any new bugs." No user cares about any of this. Fix it. Don't try to rationalize shipping garbage.

logicallee 10y ago

> The “real work” is in figuring out how to move forward from something like that, and lots of stress comes from trying to do so without breaking anything. I'm a lot more impressed with the evolution of the human species than how doctors have been able to maintain those running systems. You want to design a human from the ground up using proper infrastructure that doesn't have ailments or diseases go ahead. you'll be lucky if you end up with a fruit fly.

smt88 10y ago
The human body is the result of 1,000,000,000,000,000,000,000+ organisms dying before or after reproducing. That's evolution. It has absolutely nothing to do with the "maintenance" that doctors perform on the human body, especially when doctors are loathed to lose even a single organism. I'm not even sure why I responded to your comment, since it was so random and unrelated to the rest of the thread.
- cocktailpeanuts 10y ago
  If you think it's so unrelated, then maybe you didn't understand what he was trying to say? Doctors are necessary and important and deserve to be paid well, since they deal with life. But that can be done by anyone really. I'm not saying any idiot can become a doctor, it's that most doctors do what any other doctor can do. I'm not interested in those things either. I would rather work on something that can change how people live their lives--which one could arguably say is close to evolution.
- logicallee 10y ago
  It means you didn't understand my comment. >The human body is the result of 1,000,000,000,000,000,000,000+ organisms dying before or after reproducing. I guess I have to spell it out. "Bad, unmaintainable code" is the result of 1,000,000,000,000,000,000,000+ random requests being shoehorned in without proper design of the whole thing, but just on the basis of whether it still works or meets some last-minute requirement. I hope this makes my analogy clearer. (I realize the number is an exaggeration, I am referring to the process involved in "evolving" code, rather than "properly designing" it.)

chjohasbrouck 10y ago

There are definitely organizations where code that works but doesn’t appropriately account for those uncontrolled scenarios will earn you nothing more than a bad reputation. I’ve seen this happen, and I’ve seen their name slowly drift to the bottom of the list when it comes time for a raise or promotion. I’m generally surprised at how little interest VCs have in this, though. I think a sizable percentage of their misses could’ve been avoided altogether if they had just audited their prototype, or whatever they’re claiming qualifies as their MVP. People generally don't understand how many different scenarios software needs to account for, and how quickly those inputs can exponentiate into a very big and complex task. Creating the appearance of functional software takes a very small fraction of the time and expertise that it takes to actually make something production-ready, but I don’t think a lot of non-developers understand just how big that gap is.

kazinator 10y ago
Software VC's don't have to care about code being crap that only demonstrates well in a particular set of circumstances for exactly the same reason that mining VC's don't have to care that the same fraction of gold is found in every cubic meter of the company's mining site as in the handful of lucky drill samples. Those VC's can pump and dump: promote the stock stock, then dump it before it dives. The people that have to care are the company officers who want to grow a successful business. If those people are cynical, then the venture is probably doomed.

abakker 10y ago

This isn't just in code these days. I'd call it the Ikea phenomenon. Things that look functional and act functional in a constrained set of circumstances, and are deemed as good enough. The cost is often proportionally low, too. (ever tried to move a fully loaded Ikea dresser?) But, as you've pointed out, the real work is in maintenance, durability, and quality, not veneers.

Hupriene 10y ago
Arbitrarily relocatable furniture tends to be made of steel and weigh 300 lbs. I think the extended metaphor works for software as well.
- duerrp 10y ago
  That's a great metaphor...

cocktailpeanuts 10y ago

What you say is indeed important, but I wouldn't say the work before that is not "real work". It's just different types of work. Ask any successful startup founder what their initial codebase was like and they would say--if they're honest--it was shitty. There's a reason for this. The "real work" you mention comes into play only after the product has reached product market fit and needs scaling. Before that phase, it's all about struggling to make things work, and people don't have time to refactor everytime they need to make a small tweak and experiment. So naturally by the time the "real work" guys come in they will think "WTF the code is so shitty, whoever wrote this is an idiot". But they should know that they're there only because of that shitty code. If they were in that same situation (and rational) they would have done the same thing--write a consequentially shitty code.

Retric 10y ago
Early work is closer to a lottery than anything else. If you only look at winners you will end up with a distorted view, but right product, right time, right market is more about luck than skill. MVP is all about validation because there is no way to judge good vs great before you build it. So, the only way to improve odds is to just roll more dice.
- im_down_w_otp 10y ago
  You can still write great code (meaning: clean non-leaky abstractions, proper separation of concerns, functional testing, clearly organized, and unintuitive bits documented) without having market validation, and I'd suggest that doing so will actually make it a lot easier for you to shift the pieces of the project, remove them, rewrite them, extend them, etc. as you start to hone in on the marketplace fit, and doubly so as you need to start growing your development team and need to on-board them effectively so everyone can be productive without just rapidly accruing compound interest on the technical debt that's already there. It doesn't take that much longer to write great code when it's just part of the first-principles of your engineering process. You just do it as you go, but best-practices need to be scaffolded and modelled for everyone beforehand to give them a solid starting point for what "minimally viable" actually looks like. A single well-placed sentence that describes something necessary, but non-idiomatic or non-obvious, that takes 10sec to write can save you hours or days of tracing and debugging at that crucial moment right before you're onboarding a pilot customer or pitching investors. Very often the bar of "minimally" is set way, way too low and the trope of that just being "startup life" is usually just laying problems at the feet of engineering that don't belong there by justifying, sometimes horrifying, technical debt which are really process and management failures, and later eventually scapegoating engineering for it.

paulcole 10y ago

"version 1.0 was a rickety mess, all of those guys left, and anyone would be lucky to get the thing working at all, much less in a way that does not introduce any new bugs." No user cares about any of this. Fix it. Don't try to rationalize shipping garbage.