3 ms·

Unfortunately, the process of building houses can't be compared to building software. Houses don't get bolted sideways onto scyscrapers 5 years after they're b

Unfortunately, the process of building houses can't be compared to building software. Houses don't get bolted sideways onto scyscrapers 5 years after they're built, or suddenly need to accommodate multiple order of magnitude more people than they were originally built to hold. These are regular occurrences in the software world. You are right that most people that come out of university are woefully unprepared to design software systems. However, that doesn't change the fact that what ends up being the "best" design in the end is rarely apparent (or appropriate) in the initial planning stages of a software project. Requirements change, and the architecture needs to adapt with them. These architectural changes do have a very real cost. The tough sell is trying to show management that the alternative creates technical debt that will strangle the project if it isn't addressed, and that the longer the refactoring is deferred, the more expensive it will be.

dlitz 12y ago
> The tough sell is trying to show management that the alternative creates technical debt that will strangle the project if it isn't addressed If you're worried about that, then the problem is that you have someone managing a software project who doesn't know how to manage software projects. That's not a failure of the methodology; it's a failure organizational design.
runeks 12y ago
> Unfortunately, the process of building houses can't be compared to building software. Houses don't get bolted sideways onto scyscrapers 5 years after they're built, or suddenly need to accommodate multiple order of magnitude more people than they were originally built to hold. These are regular occurrences in the software world. Most likely, not a lot of things compare to building houses in all aspects. The point is, if developers are having problems wrt. scaling, then we need to build tools that abstract away scale. Define a language that allows the runtime to auto-scale, depending on load. As far as I can see, it's "just" another engineering challenge, not essentially different from figuring out how to make a skyscraper withstand heavy winds.

dlitz 12y ago

> The tough sell is trying to show management that the alternative creates technical debt that will strangle the project if it isn't addressed If you're worried about that, then the problem is that you have someone managing a software project who doesn't know how to manage software projects. That's not a failure of the methodology; it's a failure organizational design.

runeks 12y ago

> Unfortunately, the process of building houses can't be compared to building software. Houses don't get bolted sideways onto scyscrapers 5 years after they're built, or suddenly need to accommodate multiple order of magnitude more people than they were originally built to hold. These are regular occurrences in the software world. Most likely, not a lot of things compare to building houses in all aspects. The point is, if developers are having problems wrt. scaling, then we need to build tools that abstract away scale. Define a language that allows the runtime to auto-scale, depending on load. As far as I can see, it's "just" another engineering challenge, not essentially different from figuring out how to make a skyscraper withstand heavy winds.