You are here

Agile Design

On Wednesday, I (along with 80 other people) heard Jeremy Miller give a presentation on Agile Design at Agile Austin. Generally speaking, it is a hard topic since it is difficult to discuss without going into specifics. Jeremy did a great job at it. This blog entry captures what I took away from his talk.

Perhaps the most important point was that all design should be traceable to immediate business needs (i.e., what you're currently trying to implement). Do the simplest thing that works. Don't speculate. If you don't follow this, then you risk over designing (i.e., putting complexity in that you'll never need). This complexity will cost you in the long run by unnecessarily dragging down your future productivity. It is much harder to remove complexity than it is to leave out from the start.

Also important to note is that simplest doesn't mean brain dead. Good design principles still apply in Agile. Copy paste is bad. Constantly refactoring your design to simplify / prevent duplication of effort (i.e., DRY, Don't Repeat Yourself) is good. If you don't, it'll be that much harder to maintain (you have to go to multiple places and hope you don't forget one). Keep a list of potential refactoring ideas. Apply them when needed for what you're currently trying to accomplish.

Being a big Longhorn fan, I appreciated when Jeremy modified Darrell Royal's quote on passing to apply it to agile design: When you do abstraction, three things can happen and two of them are bad. Reuse of code can make it easier to develop. But, you could add unnecessary complexity and worse, you could make future changes more difficult. So don't overdo it.

What about the future? How do you prevent major redesigns and / or backing yourself in a corner? Think ahead, but don't act ahead. Make decisions at the last responsible moment. This is the point at which if you waited longer, you'd eliminate one of the potential options. By waiting, you ensure that you have the most information possible available to you when you make the decision.

The last part of his talk had to do with teamwork. It is important that team members share values (i.e., what is valuable in a design). It is also important that everyone is active in the overall system design. This will not only yield a better design, but it will give you more flexibility in who can take on tasks and will allow team members to do a better job.

Bottom line: Keep things as simple as possible, refactor constantly and make decisions at the last responsible moment.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer