Agile Design Philosophies

1. Agile designs are emergent, they're not defined up front. Your overall system design will emerge over time, evolving to fulfill new requirements and take advantage of new technologies as appropriate. Although you will often do some initial architectural modeling at the very beginning during “iteration 0” this will be just enough to get your team going.


2. Your unit tests form much of your detailed design documentation.
With a test-driven development (TDD) approach to development you write a test and then you write just enough domain code to fulfill that test. An important side effect of this approach is that your unit tests not only validate your code, they also form the majority of your design documentation in the form of executable specifications.


3. Design models need to be just barely good enough. You don’t need to model every single detail in your models, the models don’t need to be perfect, and they certainly don’t need to be complete. Remember the last time you coded from a design spec (if you ever did)? Did you really look at all the fine-grained details? No, because you were competent enough to handle the details yourself.


4. Each model can be used for a variety of purposes.UML class diagram can be used to depict a high-level domain model or a low-level design, not to mention things in between. Use cases can be used to model the essential nature of a process or the detailed system usage description which takes into account architectural decisions.


5. Designers should also code. Whenever a model is handed over to someone else to code there is significant danger that the programmer will not understand the model, will miss some of its nuances, or may even ignore the model completely in favor of their own approach. Furthermore, even when hand-offs are successful you will discover that you need far more details in your models than if you had simply coded it yourself. In short, separating design from programming is a risky and expensive proposition. It is far more effective to have generalizing specialists on your team that can both design and code.


6. Prove it with code. Never assume your design works; instead, obtain concrete feedback by writing code to determine if it does in fact work.


7. Feedback. Expect to receive feedback about your work and be prepared to consider it and act accordingly. Not only will your system be the better for it, you will likely learn something in the process.


8. Iterate, iterate, iterate. With an iterative approach to development you work a bit on requirements, do a bit of analysis, do a bit of design, some coding, some testing, and iterate between these activities as needed. You will also iterate back and forth between working on various artifacts, working on the right artifact at the right time.


9. Design is so important you should do it every day. It is critical to think through how you're going to build something, to actually design it, before you build it. Your design efforts may take on the form of a sketch on a whiteboard, a detailed model created with a sophisticated modeling tool, or a simple test that you write before you write business code. Agile developers realize that design is so important that they do it every day, that design isn't just a phase that you do early in the project before getting to the "real work" of writing the source code.


10. Design for your implementation environment judiciously. Take advantage of features of your implementation environment, but be smart about it. Trade-offs are normal, but understand the implications and manage the risks involved. Every time you take advantage of a unique performance enhancement in a product (such as a database, operating system, or middleware tool) you are likely coupling your system to that product and, thus, reducing its portability. To minimize the impact of your implementation environment on your systems, you can layer your software and wrap specific features to make them appear general to their users.


11. Document complicated things. If it is complicated, then document it thoroughly. Better yet, invest the time to design it so it is simple.


12. Do not over document. You need to document your design, but you shouldn't over document either. Remember, users pay you to build systems, not to document them.


13. Remember user experience (UX).
To your end user, the user interface (UI) is the system. The implication is that an important aspect of your design is the UX.