What I've Learned

In my nearly eight years of writing code for Elsevier, regardless of what kind of project planning has been attempted or with whom I have been working, all projects go the same way.  Nothing decided in advance is correct.  No one knows what they want until they get their hands on it. 

We don’t use any particular project methodology.  What we do can’t be considered waterfall, iterative, or agile.  It’s more of, “fly by the seat of your pants while pulling things out of your ass.”

So, here’s my plan for all further projects while I am employed here.  I will not write a single line of code until we get to simultaneous QA and UAT.  I will only deliver static, HTML pages, basically a mockup of the application with no functionality whatsoever.   When they see it, they can decide what it is they want it to do and how it should look.

Sure, I’ll give high development estimates, then while away the time on Reddit.  I’ll start regularly updating my blog again.  I’ll zone out during meetings while the product owners, project managers, and BAs quibble about this or that.  I might even start drinking at work. 

Then, when the testing phase has begun, and the horde of opinions weighs in, my work will begin: reactionary and defensive.  I’ll wait for the bug reports to come in from QA.  I’ll read what the “expected behavior” is in those tickets and build to that.  At least then I’ll know what I have to do to satisfy someone.  Maybe I’ll even pass the “expected behavior” by the BAs and product owners to see if that’s really what they want.  If so, we might have something somewhat like a “requirement.”

Come to think of it, that sounds a lot like some version of an agile methodology.  Perhaps we’ll even buy into that style of delivery framework someday.  Then, we can work like this from the beginning of the project rather than vain attempts to cling to some iterative or, dare I laugh, waterfall strategy.

If there’s a new way, I’ll be the first in line.  But it better work this time.