Back in developer school you are taught to simplify a problem. You are encouraged to look for commonalities and abstract them, look for repeated patterns and reuse them.
When you wind forwards to a large software project these ingrained skills turn into statements that follow this sort of pattern
We will implement complex solution X because it will be easier if we ever have to implement Y
I am torn when I hear this. I am a developer at heart so I know the person is saying this for the right reasons and best intentions. Developers are efficient problem solvers and that this is a sign of an attempt to find the most elegant solution for a problem.
But I’m torn because there was an “if” in the statement. Do something if something else happens. So the Agile part of my brain is saying “the if might never happen”. The team are building something without any requirements. No-one making design decisions is doing so based on fact. So any decisions from that point are guesses. If those guesses are incorrect not only has effort been wasted implementing the wrong thing you have may also have made it harder to implement the right thing.
Agile projects are typically arranged into sprints and each sprint contains a number of stories. It’s quite common for a number of stories to deliver a coherent feature, but those stories may be split across a number of sprints. So a feature consists of many stories and some of those stories may be in one sprint, some in the next sprint and so on.
Along with many other purposes, stories provide a way to deliver incremental business value and also allow the team members working on the story to focus on a very small dimension of a bigger problem. Most “good story guides” encourage you to create stories that represent a single dimension of a feature. Dimensions vary. They could be screens, user journeys, requirements, business rules or anything else. I like to use this model to give me ideas for different ways to break up a story.
When you have stories that are part of the same feature in a single sprint there is an argument for optimizing the design and delivering them all at once. The benefit is that the design is efficient but the risk is that if the work takes longer than planned the whole thing can’t be finished within the sprint. Depending on your circumstance that could risk a major release milestone. So you could say the team has been very efficient but it has been less effective because it has failed to meet a release commitment.
Sometimes I see teams optimise the design based on stories that exist in the backlog, and not always the ones at the top. Stories in the backlog are possible work. There is no commitment to deliver this work until they are in an active sprint. Priorities may change. As time passes more information might be uncovered that completely changes their purpose. They may no longer be required.
I have worked with a number of teams that have struggled with this. Somewhere deep inside many developers is a desire to tackle a big problem with a superb solution. Talk about incremental delivery of the software is met with retorts such as “it would take much longer that way”, “we’d be duplicating effort” and my favourite “that approach is inefficient”. All of these responses are judged against a potential product and probable solution. However one of main reason for doing Agile is to enable rapid changes of course so why build in unnecessary rigidity? So what if the team will take longer and effort might be duplicated as long as they build what the customer needs when they want it. The team may be less efficient but are they more effective as a whole? They definitely can be.
I liken this to Premature Optimisation. Creating a software solution to cater for something that might happen is just another form of this. This quote from Donald Knuth is often misquoted:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
People just tend to focus on this bit
premature optimization is the root of all evil.
I still think the full quote applies to software design . We probably spend far too much time thinking about optimisations we could make that have little positive value.