The problem here is that the devils are in the details.
Should you use small variable and function names because they are easier to type? Throw away all error-checking because without customers errors don't matter? Or as this article says, perhaps toss out FKs because they might be difficult to refactor?
Trying to make the argument that it's one way or the other is really taking a very complex decision and boiling it down to comic-book level. You need to do enough of The Right Thing in order to make it to your first value inflection point, not just whatever it takes to score a couple of dozen freebie users (although every user is awesome!) Without some idea of where you are in your startup process and what your next value point is, you can't make those kinds of decisions. They're weighted choices.
Look at it this way: assume that you hacked something together doing almost the "wrong" thing every time and ended up 2 months later with a couple of hundred freebie users. Perhaps a dozen or so are even paying for your code, say ten bucks a year. But guess what? Your income won't support the amount of maintenance you have to do on your sloppy code, and customer growth is inadequate to pay for anybody to help you out. Somehow the bills have to be paid, and instead of sales and growth you're spending a large portion of your time as "database garbage man"
So you're stuck with crappy code and not enough resources to maintain the customer base you currently have. It's called "getting upside down" in a project. Not a happy spot to be in. (And it can happen without the lean code problem)
The best scenario is where you make the conscious decision to do a few quality items even at the expense of customer growth for a few days or a week or two and then consciously make the decision not to do a bunch of other things because the hit is too much.
As Greenspun said once, if we want software engineers to be treated with respect, we need to force employers to respect a certain minimum standard of quality.
Regarding your example...by releasing something badly designed/programmed into the wild and taking money from customers, you are committing fraud. It needs to be seen this way otherwise we will never be forced to take the time to create quality software.
You're being too literal. What I'm saying is that, at the moment, there is no harmful consequence for buggy programs. Buggy programs that people buy means $$ from the initial sale of the product and your company continues to live and you get paid in $$ to maintain and fix the buggy program.
As long as the software can run, we're rewarded for creating it, no matter its quality.
In our own minds, we have to treat that as fraud and need to feel awful about it.
What I'm saying is that people judge the value of the program on just that -- it's value to them. The quality of construction can certainly affect perceived value but a perfectly-constructed program which provides no value is useless. No, it's worse than useless, because it's an example of craftsmanship-over-function.
All the quality in the world isn't going to make a pointless program worth anything. But a crappily-written program that provides lots of value is a great thing no matter how horribly it was hacked together.
Should you use small variable and function names because they are easier to type? Throw away all error-checking because without customers errors don't matter? Or as this article says, perhaps toss out FKs because they might be difficult to refactor?
Trying to make the argument that it's one way or the other is really taking a very complex decision and boiling it down to comic-book level. You need to do enough of The Right Thing in order to make it to your first value inflection point, not just whatever it takes to score a couple of dozen freebie users (although every user is awesome!) Without some idea of where you are in your startup process and what your next value point is, you can't make those kinds of decisions. They're weighted choices.
Look at it this way: assume that you hacked something together doing almost the "wrong" thing every time and ended up 2 months later with a couple of hundred freebie users. Perhaps a dozen or so are even paying for your code, say ten bucks a year. But guess what? Your income won't support the amount of maintenance you have to do on your sloppy code, and customer growth is inadequate to pay for anybody to help you out. Somehow the bills have to be paid, and instead of sales and growth you're spending a large portion of your time as "database garbage man"
So you're stuck with crappy code and not enough resources to maintain the customer base you currently have. It's called "getting upside down" in a project. Not a happy spot to be in. (And it can happen without the lean code problem)
The best scenario is where you make the conscious decision to do a few quality items even at the expense of customer growth for a few days or a week or two and then consciously make the decision not to do a bunch of other things because the hit is too much.
It's complicated.