Today I got some feedback from my lead on an early draft HLD document. Being new to the team, I asked whether or not they intended to keep the overall UML static class diagram which there was a placeholder for. He said that he wanted to keep it. I agreed because it could be a good first exposure for someone trying to ramp up on how the system works. What we disagreed on was how and when that diagram is created.
I explained that I have no issue with the diagram as long as it is generated from the code, as opposed to it being created before any code is written. He responded with “up-front design is a software engineering best practice”. Right away I could see this was a philosophical difference. I responded that while I agree in principle, I have never seen an end system look like the UML diagram that came before it. There’s nothing wrong with that, the team just learns more about the system as it’s implemented and takes action to improve the design. They let it evolve. We can spend all day diagramming, but I’d rather not spend time documenting and diagramming details that have a high probability of not reflecting reality when it’s all said and done. It just makes the document misleading, and what’s more, we’ll end up having to reverse-engineer the diagrams from source to sync them up anyway.
In his defense, I’m sure he’s not really talking about the same big design up front that agilists abhor, but I still believe that up-front design all the way down to the static class diagram level is silly. If it’s a thought-exercise, fine, it’s usually helpful to at least identify your high level components in order to develop your metaphor, but don’t begin the process with the expectation that it will reflect the final system. You’ll be disappointed.
Is all design analysis wasteful? Heck. No. My stance would have been different if there were a lot of unknowns with technology or various functional behavior. The additional analysis can be used to further mitigate the risk of a costly failed implementation. Most of all, it allows the team to learn more before diving in. However, even in this scenario I would recommended a different approach, such as Spiking the feature or developing some examples to drive TDD. I prefer an approach that provides real feedback that I’m on the right track. Diagrams aren’t very good at this.
If the team is learning more about the system, that’s the value in performing some up front design, but only when the time isn’t spent on something they would have easily discovered on their own if they had just gone ahead. When faced with a choice of more up-front design analysis, ask yourself, “Is this still valuable?” If your team will gain something from it then go for it without remorse (there’s nothing un-agile about being responsible), but once mostly everyone is comfortable, move on and get to the real (and fun) work.