Telling people to take shortcuts and write spaghetti code is a terrible idea. I'd venture to say the people nodding their heads have never had to deal with a million line code base with spaghetti code, duplication (50%), terrible architecture and no unit tests. How do you think it got that way? "We got a new client! We need X functionality right now! You want to re-architect? We don't have the time!" etc... etc... If your product is never successful its a moot point either way. If it is, you better damn well hope you have free time to both expand your product and re-architect it.
I'd much rather see a sentiment of "never sacrifice architecture for functionality but never let architecture drive your features."
I think spaghetti code is fine, so long as you know you're writing it and that it needs to be rewritten sooner rather than later. I often need to prototype an idea, so I can test it and show it to others for comments, before I know whether it's actually an idea worth pursuing.
Fortunately for me, smart people were having this same discussion 10 or 15 years ago (just as I got to the age where I stopped thinking I knew everything), and interestingly referring to Fred Brooks' work, presumably from the late sixties:
"Think first. Then hack. Now throw it out. Repeat. Fred Brooks says, `Build one to throw away.' Always rewrite your code from scratch, preferably twice. just as did it with drafts of papers in grammar school. It improves understanding, gets the creative juices flowing, and produces a far finer end-product."
The more I learn about entrepreneurship, the more I come to realize that writing the spaghetti is the way to go. Writing software quickly is much more important than writing it well. Of course, when you have a product that makes money you'll have to rewrite it, but by then you will have money to pay for developers... How do you think Facebook was created?
> Writing software quickly is much more important than writing it well.
I would say that releasing software is more important than continually delaying for amorphous "quality" concerns, but this is backwards. You want to write quality software. I've been on several teams that valued speed over quality, and in the end we always end up with a sad, fragile bit of software that's hell to maintain or add features to.
> Of course, when you have a product that makes money you'll have to rewrite it, but by then you will have money to pay for developers...
Again, having been part of teams that operated this way: later never comes. Paying customers means people relying on your software. You can't just stop working on it to rewrite from scratch, and their bugs/issues/feature requests are far more important than refactoring (which they'll never notice.)
If you ever want good software, make it good from the start.
I really hate spaghetti code, but that is because I'm a developer. The sad truth is that the reason a lot of developers like you are hired to work on this kind of team is that somebody was smart enough to release software quickly and make a business out of it...
"Writing software quickly is much more important than writing it well" You should mean: "Figuring out if people will use your product/idea is much more important than programming it"
At this point in my life I can implement a well-programmed solution much more quickly than spaghetti code. Additionally I'd rather be proud of my work considering 99% of the time I will be failing at creating a successful product. If you care that little about programming then find someone to do it for you, but if you are actually a developer then I don't understand this haphazard approach. But then I suppose people are naturally lazy.
If you are coding as a means to an end, then by all means spaghetti code, but if you are actually coding because you like to code and subsequently like to create, then for the love of God take pride in what you do! This Black or White approach just does not make any sense in today's technical world.
I'd much rather see a sentiment of "never sacrifice architecture for functionality but never let architecture drive your features."