Agile Architecture Myth #5: Never Look Ahead

Stop it! Stop anticipating! Get coding. Get that next user story working. Don’t. Ever. Anticipate.

This seems to be a common agile mantra these days. Since we allegedly aren’t good at anticipating how code will evolve, well frack it, let’s just stop all speculation.

Instead, just do your level best to code for what you know right now. Let the design emerge. Keep it clean. Period.

But is that the best we can do?

Underlying these beliefs is the assumption that you will get burned if you look ahead because you are bad at anticipating change or the need for design flexibility. Since you never get it right, why ever bother looking ahead?

Well, who says we are bad at looking ahead? Is it really true?

The fact is we all make design mistakes, whether we look ahead or not. But that doesn’t mean looking ahead is the cause of more mistakes. (Sometimes it even prevents mistakes).

I believe that you can and should look ahead. And that most developers, given half a chance, are pretty good at incorporating past experiences and making anticipatory design choices. We might even say that an “experienced developer” is one who has the ability to use past experiences to help make good forward-looking decisions.

When you refactor code to reduce dependencies you are making an on-the-spot judgment call about what part of your code is more stable and what is more likely to change. You make these decisions based on concrete evidence. You are only speculating a little bit (things keep changing here, so I’ll try this).

Experienced designers developers look ahead at a larger scale. And the longer they’ve been at it, the more they incorporate past experiences into daily looking just a little bit ahead. You learn to anticipate where the design wrinkles will be.

If you’re less experienced, this seems like magic. How can you ever know when you’ve made an appropriate anticipatory design decision when the payoff only comes sometime in the future? Well, you don’t ever know for certain.

But you get better at looking ahead by practicing it in a safe, supportive development environment. One where you are encouraged to look around and look ahead. You get to see what more senior people do. And, if you are lucky, when you ask them why they are doing something they take the time to explain their reasoning.

Looking ahead isn’t antithetical to refactoring. In fact, it might even help you avoid some rework. Over time, we learn to make even more reasonable judgment calls based on experience, wisdom, and gut instinct. (And sometimes people think that we aren’t thinking ahead because we can fluidly make on on-the the-spot design changes).

If you never practice looking ahead, well, you might just be doomed to refactoring your way to a good design. For me, that simply doesn’t cut it. And it can simply be too painful and inefficient for large, complex projects.

Recently, a thoughtful agile coach and architect told me:

“When I start a project, I try to figure out what is the minimum architecture we need to do for that context. I start from a few key things:
What are the requirements in terms of performance, scalability, reliability, security, localization, functionality etc.?

What deployment structure best fits these requirements?

What platforms and frameworks facilitate the development of the application?

What don’t we know how to do at this point? How can we find out?”

Asking these questions helps him, “define a basic but good architecture. One that ensures the right [architectural] features, minimizes time/costs and reduces risks.” That’s just enough upfront speculation to establish a baseline architecture.

But being ever thoughtful, he also asked, “I am wondering however: Should I do more? In what circumstances?”

Under certain circumstances it may be appropriate to do even more upfront design work.

Agile heresy?

I think not.

When we tackle really big unknowns it makes sense to explore more before making costly investments. Experimentation backed up by evidence-based decision making makes our designs better. Looking ahead can save us time.

But still, too many are deceived into believing in those vividly scary look-ahead failure stories. Then they overreact, pulling back from any speculative design.

My advice: Don’t overlook the many times when you have successfully looked ahead and saved time and effort. Not looking ahead is symptomatic of inexperience.

6 thoughts on “Agile Architecture Myth #5: Never Look Ahead

  1. One of the small flaws with agile is that it was developed by a lot of smart people who are really good at developing software. They underestimate how much of their experience plays in the decisions they make as they create the emergent design. Things that come natural to them do not necessarily come natural to the rest of us. That said mistakes are going to be made whether I spend time planning up front or if I jump in and start developing. If I am going to err on one side or the other of spending too much time designing verses too little I would rather err on the side of too little, because I am going to learn more by the processs of implementing something than I am about talking about implementing it. The principle of not implementing something until I need it has worked well in practice for me. Too many times when I try to anticipate what I will need I end of developing something that is never needed or used.

    I have worked on projects that have spent so much time in requirements and design that they did not have the funds to implement the project. Agile seems in some cases to be an overreaction to this problem and the knee jerk reaction to the extreme other end of the spectrum.

  2. I agree with you Chris. One great benefit of incremental and agile development is that you quickly get feedback on your ideas. Design ideas aren’t worth much until they are proven. There is no substitute for working code.

    Both overdesign and underdesign can get you in trouble. So making the time for some thinking and exploring (especially when you are making something totally new) is important. But that is no excuse to over-embellish a design. Looking ahead, just far enough ahead is what I strive for.

  3. Experienced Developers using well understood tools in a very familiar domain use ‘look ahead’ all the time, whether they realize it or not. Imploy less experienced Developers, new unfamiliar tools and/ or new domain concepts and ‘look ahead’ becomes more difficult, less natural — but more critical! The trick is to balance design and analysis in an incremental fashion with implementation. Chris indicated that one may learn more through the process of implementing rather than talking about it. I would say that if new things are being learned, whether one is modeling, designing or coding, then keep going; and if little is being learned — switch gears, do something else.

  4. John makes a great point about using tools in a familiar domain. Many familiar techniques like relational data modeling and OO modeling do this for you. Even with those there are many choices and experienced developers get the abstraction level and identify the base types the first time. Even then experienced developers differ on how much understanding they like before cutting code. The art is in how much requirements are enough to design and how much design is enough to code and I think this is true no matter what the length of the iteration is.

  5. Pingback: Do We Need Architecture when Doing Agile or Lean? : Mozaic Works

  6. Pingback: Do We Need Architecture when Doing Agile or Lean? – Mozaic Works

Leave a Reply

Your email address will not be published. Required fields are marked *