Back when I began creating software, on my first job, I was taught a waterfall development process with overlapping Requirements, Design, Development, and Test phases within a twice yearly release cycle. As we handed features over to release test, we began looking into how to implement the features asked for next. When the occasional bug came in from test, we switched to bug fixing. Usually there would be plenty of time for clarifying requirements and writing design specifications.
As we preferred not to have main branch diverge too much from the release branch during release test, we were usually reluctant to write much code on new features before the release test had completed.
Which meant that you would have weeks to study the requirements and plan for how you would create a solution to deliver them. Without writing a single line of code towards the implementation.
We had detailed design templates to follow. Business logic, user interface, data model, configuration, data migration. We had a workflow with design tasks and design review tasks in our task management system. We called for structured design review meetings with stakeholders from across the company. People came prepared. Formally approved design documents placed in a central repository. We worked in the context of a development environment and application frameworks that set clear boundaries of what could be achieved.
Upsides lost
With what Agile has preached for a generation, you might think that this was horrible. What a waste of time. Today’s mantra is two week sprints and working software delivered every sprint.
Yet, I’m reflecting that the former approach had upsides that we have since lost. Agreed, a long time to market and a long delay between development and test were not fantastic features. But the process did come with natural seasons that encouraged engineers to think things through before jumping in and writing code.
Especially with object oriented design. You easily spend days getting into a new project. Reading code, running tests. Before you get the deep insight that allows you to simplify and rearrange the code into something that better expresses what it does and is easier to test. I recon I spend 80% understanding the problem and 20% writing code (then another 80% testing and bug fixing if I missed something first time around).
A systemic effect of Agile?
It is something I’m missing now. We plan two weeks ahead and break everything down into stories that move from one side of a Kanban to the other within a day or two. Often they are engineering tasks, not stories, as they otherwise don’t fit within one sprint. We can deploy things to production so quickly now that we care less about getting it right the first time. Some days it feels more like constant bug fixing.
Engineers should be thinking, not sprinting. There is nothing more harmful to creative thinking than being stressed by a broken production system. Sure, production issues focus your attention on getting things done now. But you are not motivated to go back and remove the duct tape and rusty nails you used to patch it up.
Is that a systemic effect of agile? Long term planning done outside the scrum team? Analysis and design done outside the “real” process that we are reminded by daily rituals to think is what matters? With everyone so focused on sprinting for two weeks with no incentive for thinking ahead? Backlog grooming done ad hoc when the right people have time for it? With no tangible outcome other than a one-liner Jira ticket and a design sketch buried in someone's OneDrive? Burying the consequences of shipping partly completed features in the occasional innovation sprint?
How can we bring back the beneficial upsides of up front analysis and design?