What do software development principles have to do with writing?
Rather a lot, actually! I’m finding the parallels fascinating, and I thought I’d bring you along on this learning journey.
(Bear with me here. I started a different post about how Lean UX principles and ideas can be applied to writing … and then I went off on a TamiTangent and my very first vocabulary word is long enough for its own blog post.)
Waterfall in Software/Project Development
Waterfall is the most common and oldest project development methodology.
(Spoiler Alert: It’s usually bad news, Bucko.)
It’s called Waterfall because it assumes a great amount of effort and work up front — all flowing downward to the releasable product at the end. It is literally a series of hand-offs.
Step 1: The business sees a problem they’re having. They debate solutions, do the cost/benefit analysis, and hand the winning idea off to a product team. They then sit back and wait for the seeds of their ideas to bear fruit.
"Our sales are in the tank for another year running and we're losing out to competitors who can offer an online experience. Let's build an app!"
Step 2: The product team figures out EVERY SINGLE REQUIREMENT (often including experiences and screenshots and variables) … and they hand that off to the development team and tell them they have X number of days to make it work. They then sit back and wait for the tree of their idea to bear fruit.
"Here are all of the screens and workflows the user will go through to set up an account, use product pages, check out, etc."
Step 3: The developers use this “totally-ready” massive design document to build the thing, which is available for sale sometimes over a year after the idea was first germinated in step 1.
In other words, the developers are handed a hot mess and expected to produce fruit from what nobody thought to verify was actually an apple tree.
Step 4: Profit?
Yeah, it doesn’t work that way. The developers — you know, the ones actually doing the work to build the product? They often discover things as they build that wreak merry havoc with the carefully-ordered plans handed down to them from on high. Meeting those arbitrary deadlines (which were determined without ever asking the developer how long THEY thought it should take) is almost always a nightmare.
Waterfall makes businesses feel good up front, because they put a lot of work in and have deliverables and … well, how could it possibly not work perfectly? Look at all the planning! The words typed out on a page! The, the, the requirements gathering!
Oh hey, just out of curiosity. Any of you reading this blog post ever tried the planning/Outlining method of writing a book?
How. How’d that work out for ya?
Felt real damn good when you were building the outline, didn’t it? How could it not work perfectly? Look at all the planning!
(Just in case you’re new to this blog, I am a long-identified Planner with my outlines, and I’ve developed several super in-depth outlining methodologies that have never quiiiiite worked perfectly. If this is a callout post, it’s a post for ME, not necessarily you. Moving on.)
But yeah. I never really equated the hated Waterfall method with the Outlining method before.
Probably because most of the detractors of the Outlining method cite primary arguments around how restrictive and uncreative Outlining can feel.
I never thought about how it also amounts to the same “do all the planning first and obviously everything will work” mentality that I dread encountering at work.
And, of course, the size of the project in question matters. Waterfall on a small feature is less likely to end in disaster as Waterfall planning an entire system.
Pre-plotting a novel can end up feeling unwieldy and precarious, like planning an entire vacation with the expectation that airlines will be on time.
We’ll delve into Agile methodologies in the next post. Specifically Scrum, since I am a certified Scrum Master. (Does anyone say that without snorfling? It does not sound like a seriouspants certification, but I swear it is.)