Simon Brown gave an interesting lecture on “Agile Architecture,” entitled The Frustrated Architect at GOTOCon. Here are some notes and reactions:
- Whatever methodology you use, aim for the best of flat, self-organizing teams. Make sure to mind the inter-team gaps. That’s where architecture helps.
- My team could probably use UML more for modeling the architecture (the “what” and “how” of interactions between our features) more. Color-coding different class/component roles adds another dimension of description.
- Do class-responsibility-collaboration (CRC) modeling for architecture. Using Post-Its makes it “Agile.”
- “Coding the Architecture” = Win. “Project Managing the Architecture” = Fail.
- Focus on functional/nonfunctional requirements, constraints, and operating principles.
- Use “paper prototype”-like activities in small groups to create effective sketches of the architecture. Then ask “Would you code it that way?” If the answer is no, redo/fix it.
- The architecture should highlight both the domain (e.g., accounting) and software design (e.g., GUIs, model-view-control, etc.).
- Base the architecture on requirements and prove the architecture works via experiments.
- Architecture is what is difficult to refactor in an afternoon (or week). It’s costly to change, complex, risky, and (often) novel.
- Do “just enough” design. How do the significant elements work together, mitigate key risks, provide foundation to move forward.
- Just document what the code doesn’t describe.
- We need our technical mentors to keep teaching as they keep moving up the corporate ladder.
Dear Diabetes Blog Week readers, we’ll be back to our normal programming tomorrow. Stick around. (I don’t post techie stuff like this very often.)