Architecture Aikido
Over the past year I have been doing some side work building a web application for a startup. The project has been very interesting and the process has helped me stay in touch with my inner developer. It has also allowed me to practice agile product management philosophy to an extreme.
Last week I read Andy Hunt's article "Uncomfortable with Agile" and I have been ruminating on that feeling of being in a constant state of discomfort. If you click through and read the article, you will learn that discomfort is a good thing. The alternative is blissfully trusting a process — and then finding that you were wasting your time. Agile revolves around challenge. You challenge your assumptions and your limitations. That discomfort that you feel is really the sense of awareness that everything is in play and you are personally are accountable for a successful outcome.
Recently, I have been feeling like architecture in an agile environment is a little like wrestling or aikido. The goal is to maintain your balance and stay on your feet. Your opponent (the customer) pushes requirements in one direction and you respond by building up the architecture in that area like you might move your feet to stop yourself from being knocked over. Then, all of the sudden, the customer changes direction and you need to quickly adjust. The trick is to never over-commit in one direction or the other. Over-committing will put your balance at risk because, if the direction of force changes, all your weight will be on the wrong foot.
We see over-committing in architecture all the time. You go in thinking one feature will be the center of the application but then you find that little thing you built on the side as an afterthought is the killer feature. This is especially true with startups that are constantly "pivoting" or redefining their product. In my experience, most over-commitment sins are done in the name of performance optimization. You structure the data or the code in such a way that you can cut some corners and shave some processing time. Sometimes these optimizations are absolutely necessary but they leave you exposed for the next weight-shift. When this happens, your next iteration is spent regaining the balance of the application (refactoring) rather than adding new features.
The next time you are in charge of the technical design of an agile project, think of it as an aikido match. Fluidly adjust to changing requirements but try to stay away from positions that extend too far from a position of balance. Otherwise plan to take time getting back on your feet.