Software development processes are higher-level ideas and principles on how to develop a piece of software (or any system based primarily on computer software) for a required task. For very small projects it may be enough to just have a need, and start coding a solution for it. However, for even slightly larger projects this becomes infeasible very quickly, especially when many people are involved in the project. (When more than one person is involved, it immediately introduces management problems, so that every participant knows what to do and when, etc.)
The so-called "waterfall model" is one of the oldest such development models ever devised, going as far back as the 1950's. While there are many versions of this model, differing in details and number of steps, the distinguishing characteristic of the model is that it consists, essentially, of big sequential stages, which are usually followed in strict order (ie. the next stage isn't started until the previous one has been finished.)
A typical simplistic example of such stages could be "requirements" (figuring out and documenting what exactly the software needs to do), "design" (planning out how the software should be implemented), "implementation" (actually writing the software), "testing", and "maintenance". Part of testing is, of course, fixing all the bugs that are found (so it partially loops back to the "implementation" step, sometimes even to the "requirements" step, if it turns out that some of the original requirements are impossible, contradictory, or infeasible.)
For decades the waterfall model has been generally considered antiquated, simplistic, rigid, and above all, inefficient. Countless "better" models have been devised and proposed over the decades, most of which promise more efficient development with higher-quality outcomes (ie. less bugs, faster development, and so on.) If you ask any expert software engineer, they will invariably dismiss it as completely obsolete.
As a long-time professional small-business software developer, however, I would argue that perhaps the bad reputation of the waterfall model may be undeserved, and that it could, in fact, be the best model in many projects, especially smaller ones (somewhere in the ballpark of 20-200 thousand lines of code, a few months of development time.)
The absolutely great thing about the waterfall model is that the requirements are figured out and documented in full, or almost full, before writing the software even starts. While perhaps not written in stone and never changed again during development, it should at least lock the vast majority of the features, preferably to the tiniest of detail.
The great thing, as a programmer, about having such a complete and detailed requirements document is that once you start implementing the program, you have a very clear, complete and unambiguous picture of what needs to be done, and you can design the program from the get-go to accommodate all those requirements and features. You can plan, design and implement your module and class hierarchy, and your modules and classes, to fluently and cleanly support all the required features right from the start. When well done, this will lead to nice, clean and logical class hierarchies and class interfaces, and to a more robust and understandable program design overall.
Also very importantly, having an almost-complete document of requirements, which means that you know exactly what needs to be done, means that the implementation of the program will be relatively straightforward and fast. Usually the actual implementation does not take all that much time, when everything that has to be done is clear from the get-go.
If such an almost-complete requirements stage and document is not made, however, it easily leads to, essentially, the software development equivalent of "cowboy programming" and "spaghetti code". It will also almost inevitably lead to actual "spaghetti code" in the program implementation.
In other words, if the project starts with just a vague idea of what should be done, and the concepts for the project evolve during its implementation, with new ideas and features being conceived as the project progresses, this leads almost inevitably to absolutely horrendous code, no matter how well you try to design it from the start.
What's worse, the implementation will take a very long time. Existing code will constantly need addition, changes and refactoring. Existing code will often need to be redesigned to accommodate new requirements (which were impossible to predict at the beginning).
This can turn nightmarish really quickly. Sometimes even a simple-sounding new feature, which might sound like it could be implemented in minutes, might take several hours to implement, just because the existing code was not prepared to support that feature.
This kind of software development is far from fun. In fact, it can be absolutely horrendous. And horrendously inefficient. New requirements and new ideas keep pouring in at a semi-regular basis. Some of them take some minutes to implement, others can take several hours. Many of these ideas are just testing to see if they will work, and may be dropped later, after it's decided that the idea didn't work well after all. Essentially, the software implementation is used as a testbed for new ideas, to try to see if they will work; and if they don't, they are just discarded. This ends up in countless hours of wasted development time.
And of course as a result of all this, the program becomes a nightmare of an absolute mess. No matter how much you try to keep it clean and high-quality, there's no avoiding it, as hundreds and hundreds of new and changed features are patched into it, sometimes haphazardly because of necessity.
When one is involved in such a project, one really starts to yearn for a waterfall model requirements documentation, which would make implementing the program so much easier and faster.
Personally, I would change these new poorly designed, poorly enacted "modern" software development models for a good old waterfall model any day, if it means that I would have a clear and complete picture of what needs to be done right from the get-go, with little to no changes made during or after development. It would make it so much easier and faster, and the end result would be of much higher quality. The whole project would also probably take a lot less time.
The so-called "waterfall model" is one of the oldest such development models ever devised, going as far back as the 1950's. While there are many versions of this model, differing in details and number of steps, the distinguishing characteristic of the model is that it consists, essentially, of big sequential stages, which are usually followed in strict order (ie. the next stage isn't started until the previous one has been finished.)
A typical simplistic example of such stages could be "requirements" (figuring out and documenting what exactly the software needs to do), "design" (planning out how the software should be implemented), "implementation" (actually writing the software), "testing", and "maintenance". Part of testing is, of course, fixing all the bugs that are found (so it partially loops back to the "implementation" step, sometimes even to the "requirements" step, if it turns out that some of the original requirements are impossible, contradictory, or infeasible.)
For decades the waterfall model has been generally considered antiquated, simplistic, rigid, and above all, inefficient. Countless "better" models have been devised and proposed over the decades, most of which promise more efficient development with higher-quality outcomes (ie. less bugs, faster development, and so on.) If you ask any expert software engineer, they will invariably dismiss it as completely obsolete.
As a long-time professional small-business software developer, however, I would argue that perhaps the bad reputation of the waterfall model may be undeserved, and that it could, in fact, be the best model in many projects, especially smaller ones (somewhere in the ballpark of 20-200 thousand lines of code, a few months of development time.)
The absolutely great thing about the waterfall model is that the requirements are figured out and documented in full, or almost full, before writing the software even starts. While perhaps not written in stone and never changed again during development, it should at least lock the vast majority of the features, preferably to the tiniest of detail.
The great thing, as a programmer, about having such a complete and detailed requirements document is that once you start implementing the program, you have a very clear, complete and unambiguous picture of what needs to be done, and you can design the program from the get-go to accommodate all those requirements and features. You can plan, design and implement your module and class hierarchy, and your modules and classes, to fluently and cleanly support all the required features right from the start. When well done, this will lead to nice, clean and logical class hierarchies and class interfaces, and to a more robust and understandable program design overall.
Also very importantly, having an almost-complete document of requirements, which means that you know exactly what needs to be done, means that the implementation of the program will be relatively straightforward and fast. Usually the actual implementation does not take all that much time, when everything that has to be done is clear from the get-go.
If such an almost-complete requirements stage and document is not made, however, it easily leads to, essentially, the software development equivalent of "cowboy programming" and "spaghetti code". It will also almost inevitably lead to actual "spaghetti code" in the program implementation.
In other words, if the project starts with just a vague idea of what should be done, and the concepts for the project evolve during its implementation, with new ideas and features being conceived as the project progresses, this leads almost inevitably to absolutely horrendous code, no matter how well you try to design it from the start.
What's worse, the implementation will take a very long time. Existing code will constantly need addition, changes and refactoring. Existing code will often need to be redesigned to accommodate new requirements (which were impossible to predict at the beginning).
This can turn nightmarish really quickly. Sometimes even a simple-sounding new feature, which might sound like it could be implemented in minutes, might take several hours to implement, just because the existing code was not prepared to support that feature.
This kind of software development is far from fun. In fact, it can be absolutely horrendous. And horrendously inefficient. New requirements and new ideas keep pouring in at a semi-regular basis. Some of them take some minutes to implement, others can take several hours. Many of these ideas are just testing to see if they will work, and may be dropped later, after it's decided that the idea didn't work well after all. Essentially, the software implementation is used as a testbed for new ideas, to try to see if they will work; and if they don't, they are just discarded. This ends up in countless hours of wasted development time.
And of course as a result of all this, the program becomes a nightmare of an absolute mess. No matter how much you try to keep it clean and high-quality, there's no avoiding it, as hundreds and hundreds of new and changed features are patched into it, sometimes haphazardly because of necessity.
When one is involved in such a project, one really starts to yearn for a waterfall model requirements documentation, which would make implementing the program so much easier and faster.
Personally, I would change these new poorly designed, poorly enacted "modern" software development models for a good old waterfall model any day, if it means that I would have a clear and complete picture of what needs to be done right from the get-go, with little to no changes made during or after development. It would make it so much easier and faster, and the end result would be of much higher quality. The whole project would also probably take a lot less time.
Comments
Post a Comment