Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

How to maintain desired Application architecture, when using agile approach ?

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In a waterfall model, since application architecture and solution design and review is normally completed before code development, we have been able to maintain desired application architecture. Where in the process do you slot the activities to maintain and govern desired application architecture with agile approach ? With reduced emphasis on system documentation, where in the process do you produce or update artifacts like logical view of application architecture ?
Posts: 15733
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Vasu Anand wrote:With reduced emphasis on system documentation...

This is a common misunderstanding. Agile does not de-emphasize documentation so much as it shifts the approach away from producing Big, Up Front documentation. The emphasis is making useful documentation when it is actually needed. Writing a lot of documentation up front without developing software to validate that documentation often leads to wasted time and effort. Shared understanding via collaboration is emphasized. Important things that you want to remember should be documented. The target audience determines how detailed that documentation is. If it's meant to be a reminder for people who were involved in the conversations during development, you probably don't need to document as many details as you would if the documentation was meant for people who will inherit the project from the current team.

Jeff Patton, author of "User Story Mapping", compares it to a picture of people on vacation. For the people who were there, a picture can bring back a lot of memories and details about what happened at that particular moment. For people who weren't there, the picture doesn't do much for them and a video might be a better way to show them how much fun the vacationers had.

I think there's a lot of interplay between the kind of documentation that you write, when you write it, and the kind of design decisions that you make, when you make them. Documenting too many details too soon often leads you to making decisions about aspects of your design too soon. The "looseness" of your documentation should reflect the looseness/firmness of the design decisions you make.
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I talked about making decisions at the last responsible moment on this thread: -- and the same idea applies to architecture as well. We talk a lot about this in Learning Agile when teaching about XP.

Effective XP teams do a really good job of determining only the architecture that's needed right now, and leaving all other architecture decisions until later in the project. This can be very disconcerting for a "pure" architect who lays out a grand vision at during a design phase. But it's also surprising for more real-world developer/architects who feel much more comfortable making most of the architecture decisions up front.

XP teams handle this using a practice called incremental design, in which they design only the next increment of the software during each (short) iteration. They rely on decoupled design to keep their architecture flexible, constantly look for code smells, and refactor mercilessly. They also use test-driven development, which when done by an effective XP team can have a profound impact on the design by helping the team to construct their code from small, simple, decoupled units. All of this results in simple architecture -- simplicity is a core XP principle, and also a core agile principle (maximizing the work not done) -- and simple architecture is much easier to change.

This allows XP teams to embrace change: they build the most simple, decoupled code that they can today, which lets them expand the architecture tomorrow in the most minimal way possible.

This is a very different way of thinking for a lot of developers, especially those who are used to making a lot of architecture decisions at the beginning of the project. It feels to them like the team is diving right into code without thinking enough about the big picture. In fact, what's actually happening is that the team is thinking just enough about the big picture. Some decisions do need to be made now, but they trust themselves to make smart decisions in the future, too. And that's usually a better time to make a decision about architecture, because that's when you know more about the problem.
The harder I work, the luckier I get. -Sam Goldwyn So tiny. - this ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic