I have the great misfortune of working at a big company which has tons and tons of specs AND frequent spec changes.
Our process is waterfall that refuses to accept the reality that marketing runs this company and they change their minds a lot.
My point is only that if there was something better I would quit mediately. But I would rather deal with this at a biotech, then work at the most wonderful company working on social apps, or advertising apps, or ticketing, or booking, etc.
Heh, that sounds very familiar. When I got my job, it was told that the reason for using a waterfall model was that "the specifications are very clear, and developers just have to implement them".
Sounds like my last job. They had gotten burned a few times by waterfall projects failing, so their reaction was to try to implement waterfall even more rigorously.
You had to design and document the entire project up front and then break it out into individual tasks and estimate them. Two points that I thought were particularly horrible:
Your estimates immediately became hard deadlines. If you guessed 3 months ago that gnarfling the garthok would take you 8 hours and you were wrong, it went against you on your metrics. Even better, if you finished the job in less time than you estimated, they'd complain and tell you that you missed low and needed to do a more precise job of estimation next time.
I suggested to my boss once that if they insisted on having all this documentation written (seriously, we were supposed to write up docs on what the function names were going to be, what the arguments were, and what they'd do -- before we were allowed to write any code) then we should probably build some time into the schedule to make sure we could update them based on what we'd learned during the actual process of writing the code. He told me "I understand what you're saying, but that's not possible. We need all of the documentation done up front so that if we're behind schedule, we can add more people to the project and they can read that documentation to get up to speed quickly."
I looked at him for a few seconds, stunned speechless, then basically said "In my experience, that never works." A few weeks later, I was laid off, I suspect because I wasn't toeing the line and buying into the "new" Lean waterfall process. Best thing that ever happened to me, in the end.
It's kind of the same here. We first have to write a design document, then get it reviewed by people all over the organisation. This reviewing has to be done in a meeting, which is impractical because it is almost impossible to find a time where everybody is available AND a room is available.
Writing a design document doesn't sound that bad, but the requirements are completely unclear when you start the project. Usually, the stakeholders don't even exactly know what they want, so it's very hard to get concrete requirements. And they change their mind all the time, so if you just scrapped something, many times you have to add it back later.
Only when it is deemed OK, it is officially allowed to start programming. If not, back to the drawing board. Worst part is that the opinions differ on how detailed this design document should be. Some people complain if it is not detailed enough, others complain if it is too detailed.
When you have the OK, the red tape only starts. You have to mail or run around asking people to grant change access to their part of the source code. In many cases, simply referring to the design document for explanation is not enough. Nope, as they generally had "no time" to go over the document, if you want to get work done, you should explain everything that you're going to change in their part.
Even the SCM system that we use is slow. Checkouts take ages, builds take ages. This way of development really doesn't work for me and many others. Luckily there is an (unofficial) way to "fork" the code, so that you can start working and experimenting while writing the design document. Without this, it'd be almost impossible to get the amount of detail required.
And when you're done coding, you need to write a document with testcases, which goes through the same review process. When you're done testing, another document with test results...
In this case, the process works because it is not very rigidly enforced. Unluckily, some people in management think that code quality will improve if and only if more checks are put in place. So every half year there are more checkboxes and process steps.
Our process is waterfall that refuses to accept the reality that marketing runs this company and they change their minds a lot.
My point is only that if there was something better I would quit mediately. But I would rather deal with this at a biotech, then work at the most wonderful company working on social apps, or advertising apps, or ticketing, or booking, etc.
Pick your poison kids.