Three ways that the waterfall model would benefit my future project and career goals are: it would make sure that every phase of my software’s development was complete and satisfactory, it would also make sure that my working process and model is easy to explain to any sub-contractors that I may work with, and, if a software that I developed was noteworthy enough, I would have an easy framework to use when writing a report or explanation about a software that I created.

Firstly, when referring to my phases of development being complete and satisfactory, the waterfall model’s overall philosophy is that a developer should not progress into their next working phase unless the previous phase has been fully documented and accounted for. This means that, over time, I will often perform many verifiable self-checks on my own developments before moving to the next step in software development.

The second benefit is that the waterfall model would be easier to explain to any sub-contractors that I am working with on a project than other models. This is mainly due to the fact that the waterfall model is fairly straightforward in concept, theory, and practice. Once I lay out the six phases of the model, the sub-contractors are to move through the six phases in the exact order that they are presented in and can only progress through phases when the previous phases have been thoroughly reviewed.

The third benefit is that it is an easy framework to use when explaining the process of a software’s development in an academic or technical writing document. Since the waterfall method is a simplified and direct working model, explaining each of the six phases in detail will not be as difficult because the documentation of reviews and checking should already be on hand for reference.

Even though these three benefits of using the waterfall method are present, there are also three drawbacks that developers should consider when deciding whether or not to utilize this method. For one, when assisting a client who is having software issues, they may not be familiar with the history of the software that they are asking a developer to work with. If neither the developer nor the client can determine where the intervention should begin, the servicing developer may have to begin from scratch which will increase working time and costs on the client.

Another drawback to the waterfall model is that there are some organizations and think tanks that look down on the waterfall model. Some organizations even go as far to be anti-waterfall model. This can hinder my future career prospects and projects because certain clients may end up falling into this line of thought and could have certain apprehensions about me, personally, as a developer because I utilize this particular working model. Also, if a larger organization has apprehensions about this certain working model, that limits the level of future contracts that I can secure in the future. Seeing as how various United States governmental agencies are always in need of quality software developers and cybersecurity agents.

Finally, the traditional waterfall model of project development does not encourage any type of retroactive editing or revision. Only if I were to use one of the modified versions of the waterfall model of development would I be able to fix mistakes from previous phases that I was unable to catch until the testing or operations phase of development. This causes issues down the line because I may have to work with multiple developers at once, and their working models may encourage constant editing and revision, which would strongly contradict with my working habits and may cause a type of professional friction in the workplace.