For some historical context, I recall reading some years ago about how business software was developed in the early days in the mainframe computing era (from the 1950s).
It was apparently not unusual during those decades to build a bespoke piece of software completely from scratch, designed specifically for a given mainframe computer. Often such mainframes were single-purpose machines that just ran that one piece of software, without even having an operating system.
It seems that it was common to put in, from the start, all of the functionality that would be required for the life of the software: Therefore, a great deal of up-front analysis was needed (waterfall). After the initial deployment, it was not common to make changes to the software - and it was not at all easy to do so. At that time, the capabilities of the hardware were so limited that squeezing the required logic into the system in the first place was a feat in and of itself. It was not necessarily realistic to add more functionality to that code afterwards, and even making small changes was challenging.
If a company wanted to move the software to a newer mainframe, the design of the new mainframe was generally incompatible with the previous one, so the software was re-written from scratch at that point. The IBM 360 series appears to have been a big innovation in this sense - the architecture of newer models was compatible with previous ones, so porting code became possible.
With the standardization of instruction sets, operating systems, libraries, and programming languages, along with more memory and CPU, we now expect extreme plasticity from software - totally different from those early days. So we're in the agile era @phlash909
describes. The focus is on making a codebase useful as quickly as possible, releasing it into the wild, and then continually evolving it over time to meet the needs of its users as they arise. Automating the building, testing, and deployment of software is essential, and the practices around software development (things like object-oriented or functional programming, test-driven development, small loosely-coupled services) help to make software more amenable to change.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For some historical context, I recall reading some years ago about how business software was developed in the early days in the mainframe computing era (from the 1950s).
It was apparently not unusual during those decades to build a bespoke piece of software completely from scratch, designed specifically for a given mainframe computer. Often such mainframes were single-purpose machines that just ran that one piece of software, without even having an operating system.
It seems that it was common to put in, from the start, all of the functionality that would be required for the life of the software: Therefore, a great deal of up-front analysis was needed (waterfall). After the initial deployment, it was not common to make changes to the software - and it was not at all easy to do so. At that time, the capabilities of the hardware were so limited that squeezing the required logic into the system in the first place was a feat in and of itself. It was not necessarily realistic to add more functionality to that code afterwards, and even making small changes was challenging.
If a company wanted to move the software to a newer mainframe, the design of the new mainframe was generally incompatible with the previous one, so the software was re-written from scratch at that point. The IBM 360 series appears to have been a big innovation in this sense - the architecture of newer models was compatible with previous ones, so porting code became possible.
With the standardization of instruction sets, operating systems, libraries, and programming languages, along with more memory and CPU, we now expect extreme plasticity from software - totally different from those early days. So we're in the agile era @phlash909 describes. The focus is on making a codebase useful as quickly as possible, releasing it into the wild, and then continually evolving it over time to meet the needs of its users as they arise. Automating the building, testing, and deployment of software is essential, and the practices around software development (things like object-oriented or functional programming, test-driven development, small loosely-coupled services) help to make software more amenable to change.