Planning for the corners in software design

The critical skill that is an indicator of success when designing software is planning for the corner cases. I often describe this in relation to a project or feature as a hallway, and just because you can't see the terminus you can assume there are branches. There are going to be corners to look around. When you approach a corner in an office building perspective lets you see a limited hint as to whats coming next and as you get closer it becomes a little more clear.

While this metaphor might be something you get a chance to experience often, it's the same exercise you take in software design. When designing a feature, you have to project yourself down the hallway. Maybe you are doing this as the user exploring the product or as the next developer expanding the product. It's probably a combination, to be honest.

Here's the secret: oftentimes, you can predict what's around the corner in an office because offices are systems. Its not going to be an open field of flowers (wouldn't that be nice). Software designs are not going to evolve into illogical paths either (I guess they could but I wouldn't expect anyone to use them). Point is pragmatism in software design is not about doing the least and iterating its planning for the optimal and iterating (Subtle I know).

I don't know if I blame this on inexperience, LEAN, or a misaligned understanding of the cost of software maintenance. But planning for the least is going to be a bad time, and the speed at which that bad time arrives is strictly based on situational ambiguity—not the ambiguity of the ask, say, in a ticket, but the ambiguity of purpose, the "spiritual goal" being served.

Good software designs result from comprehension, not actualization, which is the difference between understanding and giving the appearance of reality (Again, subtle). A plan can present a reality and is arguably complete while lacking understanding. It floats in the correct space, but it's not connected to all the other hallways in the office. Comprehension leads to completeness. This isn't an argument for Test DD(TDD) directly, but I could find an annex where I would put up posters for it cause it helps. But this is pre-TDD, pre-Technical DD, and starts at the user or developer experience. It is the beginning of the hallway and ends when we have projected ourselves towards enough of the hallway offshoots and corners to hint at the actual solution.

Ok, so now that you understand the skill, get ready for the next challenge: getting others to believe you. I think you may have experienced developers who "go off into the woods on their own" and ask for no feedback on a design and build something that works but isn't worth talking about. This is a coping strategy where a decision has been made, and the efforts required to sell the vision aren't worth the effort. They decided, in isolation, that just completing the act was proof enough. Not everyone has the right to put their voice on a design; only those with comprehension should make the decisions. It's a middle ground between design by committee and collaborative design. Simply put, not everything needs an RFC; some things need to be built, and some things need to be planned, but in design, the shorter the cycle and the more iterations, the better.