3 ms·

> Your argument is like saying you're going to build a house but don't know if anyone will want to live in it The first houses in a complex are usually sold be

by blowski 13y ago

> Your argument is like saying you're going to build a house but don't know if anyone will want to live in it The first houses in a complex are usually sold before being built, on the basis of a prototype - be it blueprints, 3D walkthrough, or a show-home. If they can't sell those houses, they don't build the rest. It's the cheapest way of establishing whether there's a market for the properties they intend to sell, and it's much cheaper than finding out there's no market having built 50 of them. > "today's code become's tomorrow's legacy code" Worry about it tomorrow. It's a nice problem to have as it means you're still in business. Most businesses started today won't be. Until you've established that your product is going to have customers, the performance is irrelevant. My favourite example is the fake 'Buy now' button. You don't need to build the payment process until you know people want to pay, and you definitely don't need to worry about how quickly it runs. If people want it, they'll pay even if it's slow. If people don't want it, why are you building it? Nobody buys a product just because it's quick (unless performance is the central feature.)

kintamanimatt 13y ago
Houses are sometimes built like that, but I've seen indie builders just build the house, rent it out, and then sell it. There are multiple ways to build and sell a house. Writing code that's maintainable, secure, and performs well isn't all that difficult, and it's certainly not some horrible burden that will eat up all your time at the expensive of customer acquisition. There's no excuse for sloppy work, and yes, customers can jump ship if they think your product is substandard and response time adds to that feel. You're also not going to be less busy in the future and having a codebase that's difficult to maintain is going to put excessive pressure on you or your team. Sloppy code is harder and more expensive to debug than well written code in all respects. You're also more likely to have major problems (performance, security, grim bugs) that could have been avoided simply by thinking a little up front. It's not all that much more expensive to write decent code. It's also not appreciably more time consuming to write a decent NodeJS app than it is to write a Rails or Django app. I strongly suspect you're conflating over-engineering with making wise decisions that don't require a huge time burden and make life easier in the long run.

by blowski 13y ago

kintamanimatt 13y ago

Houses are sometimes built like that, but I've seen indie builders just build the house, rent it out, and then sell it. There are multiple ways to build and sell a house. Writing code that's maintainable, secure, and performs well isn't all that difficult, and it's certainly not some horrible burden that will eat up all your time at the expensive of customer acquisition. There's no excuse for sloppy work, and yes, customers can jump ship if they think your product is substandard and response time adds to that feel. You're also not going to be less busy in the future and having a codebase that's difficult to maintain is going to put excessive pressure on you or your team. Sloppy code is harder and more expensive to debug than well written code in all respects. You're also more likely to have major problems (performance, security, grim bugs) that could have been avoided simply by thinking a little up front. It's not all that much more expensive to write decent code. It's also not appreciably more time consuming to write a decent NodeJS app than it is to write a Rails or Django app. I strongly suspect you're conflating over-engineering with making wise decisions that don't require a huge time burden and make life easier in the long run.