| I worked at Oracle for a few years in their database development group (internally known as "RDBMS"). You would be surprised to know that they follow a strictly waterfall process to perform database development. The results are horrible. Process: - Let us say a release is planned for January 2018. Projects are decided around June 2017. By the way, In Oracle RDBMS, a project essentially means anything more than 5 lines of code change. - Each developer is assigned a project. - The developer is given a deadline to write a design spec by August 2017. Developer spends 3 months in writing a design spec. A lot of bike-shedding occurs for those 3 months on mundane topics like whether a certain timeout should be 0.5 seconds or 1 second. - Then the developer is given another deadline, say September 2017, to write a functional spec. More bike-shedding. - Then the developer is given yet another deadline, say October 2017, to write a test spec. More bike-shedding. - 5 months have passed and not a single line of code has been written. But 3 large documents with about 10000 words in total and another 10000 words of bike-shedding has been written. - Finally, the developer is given another deadline, say November 2017, to complete writing the code with tests. Results: - Developer writes 10 lines of code and checks in their code by November 2017. Project completed! - Everything looks fine for a few days. - About a million or so tests run over the next few weeks. 1000s of tests are found to be broken. So much for 5 months of spec reviews! (Note: This happens for every such project, about 20 or so projects in a year.) - The bugs are distributed to various developers. It takes them another 12 months to figure why each test broke, how tightly every layer and corner of the code is coupled with each other, and how they are solving the biggest puzzles of their lives: How to fix one thing without breaking 10 more things?! - The original design, functional and test specs go out of the window. This is really bad time. Management is unhappy. Larry is unhappy! We got to fix those tests, no matter what it takes to fix them. Radical decisions are made as developers discover clever tricks to fix one part of the code while somehow finding a way to keep the other part of the code happy. - 12 months have passed. It is November 2018 now! (Remember, the project was scheduled to be released 11 months ago!) It looks like everything is fixed. The whole 10 line project is somehow held together by tests. Nothing appears to be broken. But nobody is really sure. I am glad there are other saner companies where people understand that waterfall model development is flawed and embrace agility. Having done waterfall for a few years, agile development is a breath of fresh air where I can spend more time writing code than writing documents, where I can evolve the code based on actual user feedback rather than feedback from bike-shedding by people who have not contributed a single line of code to the software. |