"Would an engineer design a small, single lane bridge for a rural Northumberland village so that it could support the weight of a thousand double decker buses? No. So why do we, as software engineers try to do exactly this? That day will never come."
It comes every time a boss or client says "oh, and now we need it to do XYZ. And you can't rewrite or start over. We need it tomorrow. Build on what you have - reusable software is our goal." and so on.
No one is going to go to a bridge engineer after a two lane bridge is up and running, and that took 2 years to build, and say "ok, add 4 more lanes by next week. Oh, and you have no budget". No one in their right mind would ever dream of doing that. But with software we face it all the tim.
Basically, many of us are conditioned to have to extend on top of whatever our first iteration is, so we try to make the first iteration extendable. I'm not saying it's right or good, but I've fallen in to this trap too many times in my career and seen it happen to too many other people to think it's not a contributing factor.
I can tell you from first-hand experience, though, that if you cannot scale immediately when the time comes, your business can drastically suffer for it.
I don't disagree, but a few points spring to mind. And in my earlier post, I wasn't really thinking about 'scaling', but new functionality/features.
Occasionally "immediately" really does mean "in the next 5 minutes". Oftentimes it actually means more on the order of days or a couple weeks. "Scaling" can mean different things, and anything beyond "scaling" web requests alone will likely mean a shift in business operations that can't/won't happen overnight either.
In most situations where I've been in where people request something, but the rest of the business unit really isn't ready to handle the change. "We need the new data reports now" but when you make the change you realize the other company who pulls the data to process it is on vacation and won't be back for two weeks, and if you make the change now, then it'll break everything.
Yeah. I was only referring to scaling in the sense that the number of users increases. Often, it is easier to implement an application by ignoring scalability, and you can get it out the door quicker.
However, this can be a terrible mistake if your users are not resilient to downtime or lost data (e.g. in the case of Facebook games). Even just a few hours of downtime or slowdown can cause a significant, permanent drop in users.
It comes every time a boss or client says "oh, and now we need it to do XYZ. And you can't rewrite or start over. We need it tomorrow. Build on what you have - reusable software is our goal." and so on.
No one is going to go to a bridge engineer after a two lane bridge is up and running, and that took 2 years to build, and say "ok, add 4 more lanes by next week. Oh, and you have no budget". No one in their right mind would ever dream of doing that. But with software we face it all the tim.
Basically, many of us are conditioned to have to extend on top of whatever our first iteration is, so we try to make the first iteration extendable. I'm not saying it's right or good, but I've fallen in to this trap too many times in my career and seen it happen to too many other people to think it's not a contributing factor.