We are developing the agile way for a few months now and I have some troubles understanding the agile manifesto as interpreted by my colleagues. The project we are developing is a framework for future projects and will be reused many times in the next years.

Code is only written to fulfill the needs of the current user story. The product owner tells us what to do, but not how to do it. What would be right, in my opinion, because he is not implicitly a programmer. The project advanced and in my eyes it messed up a little bit. After I recognized an assembly that was responsible for 3 concerns (IoC-Container, communication layer and project internal things), I tried to address this to my colleagues. They answered that this would be the result of applying YAGNI, because know one told them to respect that functionalities have to be split up in different assemblies for further use.

In my opinion no one has to tell us that we should respect the Separation of Concerns principle. On the other side, they mentioned to prefer YAGNI over SoC because it is less effort to implement and therefore faster and cheaper. We had changing requirements a lot at the beginning of the project and ended up in endless refactoring sessions, because to much has to be adapted.

Is it better to make such rather simple design decisions up front, even there is no need in the current situation, or do we have to change a lot in the later progress of the project?

  • 1
    If your team uses the YAGNI principle as an excuse for not keeping the code organized and clean, then it is just that: an excuse. The agile idea is to separate concerns when they occur, not earlier (what would be upfront design), but also not later.
    – Doc Brown
    Jun 25, 2012 at 15:50
  • 4
    "The project we are developing is a framework for future projects and will be reused many times in the next years." No. You are not doing anything agile.
    – Euphoric
    Jun 25, 2012 at 16:24
  • 1
    @Euphoric: Really? That's a shame. It would seem that agile is not suitable for anything that promotes code reuse. Surely you can work from a pre-established API, and be agile in your implementation. Jun 25, 2012 at 16:47
  • 3
    Key point of agile to get user feedback as soon as possible. How are you gonna get this feedback, when users of your library are in the future? If you want to develop a library in agile way, you need projects that use this library at the same time, as you develop this library. And for code reuse, do you know what code do you want reused? No, because you don't know what future will bring.
    – Euphoric
    Jun 25, 2012 at 18:19
  • 2
    Building systems requires vision. Forget acronyms, customers don't care about YAGNI and Agile, etc. Lisa in accounting will send an email to her boss that the system is a waste of resources on the least missing feature and you'll curse all those fancy phrases, sprints will not come to your help because the budget will be gone...Analyze and finalize requirements clearly, then phase delivery. Honesty is a must.
    – NoChance
    Jun 25, 2012 at 19:57

3 Answers 3


Is it better to make such rather simple design decisions up front, even there is no need in the current situation, or do we have to change a lot in the later progress of the project?

Delay architectural decisions until as late as possible (but no later). You are going to know more about the problem in the future than you do right now, and thereby likely come up with smarter decisions.

For instance, imagine you are trying to decide up front whether to use MongoDB, some other NoSQL or traditional SQL for a project. Delay the decision: write a simple repository layer that will simply save the data in memory, or save data to a JSON file for now, and continue on. Eventually you'll have to replace this stub with something - but later on, you might know with more of a certainty which way to go: "hey, all of this really is a great fit for a document store" or "you know, SQL transactions would really help".

Its important to do this in conjunction with the concept of prioritizing the riskiest parts of your application to be developed first - that is, the parts you understand the least you should do before you do other work. This should mean you end up with an architecture that fits your solution, instead of forcing your solution later to fit in to your pre-selected architecture.

I don't mean to suggest that every project start with an exhaustive comparison of every possible web framework, storage technology, and so on. Hopefully in most projects you can simply default to reliable frameworks that have been used in the past under guidance from the team architect. I'm suggesting that this technique of delaying architectural decisions should be used when you are faced with a decision to which you don't know the answer.

One way to look at it - in an Agile project, you're always doing architecture, instead of trying to do the architecture "up front". If a pair of programmers (you are pair programming right?) picks up a story and realizes that it requires an architectural discussion, they should have it. If they feel they should involve more devs, then they should do that. If this results in a desire to remove some technical debt caused by previous lack of architecture or previous poor architectural decisions, what we've done is had the devs write up a work item for this and work with the product owner to schedule it in. Generally, explaining it in terms of ROI: "we believe the removal of this technical debt will result in the following return", generally in terms of faster response times, or shorter future development cycles.

Also, as a commenter pointed out:

The project we are developing is a framework for future projects and will be reused many times in the next years.

This does not sound agile at all. Are you sure your business requirements demand this sort of thing? Agile is all about recognizing that change happens - this week's great idea is next week's "bottom of the backlog". What technique in future prediction is leading you to be certain about what things will be important to you in three months, much less 'the next few years'?

As far as the original question "who should be the architect in an agile project", I've always selected the most experienced programmer on the team or the programmer that knows the code base the best, and given them the architect title. Sometimes the architect is just letting the developers come up with a solution and guiding the process a little bit, sometimes they are making the call. In teams organized this way, the architect is contributing code to the project most of the time, and playing the "architect" role whenever required.

  • 4
    Delay architectural decisions? Really? The decision to use something like MVC, databases and repositories should be the first one you make; all you need is a general idea of the nature, size and scope of the application to make these decisions. The sooner everyone is on board with a sensible architecture, the better the final application is going to be. Jun 25, 2012 at 16:53
  • 1
    @RobertHarvey Perhaps I've overstated it. I agree that before you begin writing your website you should select your web framework; that does make sense. I'm rethinking my stance, though I still fundamentally agree with what I originally wrote that delaying most architectural decisions is a good idea. Are there parts of my answer that you do agree with?
    – Kyle
    Jun 25, 2012 at 16:59
  • 2
    Sure, although I'm still surprised that more than one person has now stated that agile only works for certain kinds of projects. That implies that you need more than one software methodology or, as I've stated in a comment to the question, that Agile is really more about requirements gathering using UI prototypes than it is about writing software. Jun 25, 2012 at 17:03
  • 2
    "The project we are developing is a framework for future projects and will be reused many times in the next years." No. You are not doing anything agile. And your comment: This does not sound agile at all. Ergo, Agile can't be used for libraries. Jun 25, 2012 at 17:06
  • 2
    @woni You are describing a situation where you know you need it due to requirements - in this scenario I would not suggest delaying the decision. In the scenario I describe (and perhaps I should strengthen this point), you are torn between two possible outcomes. It is in this case that I suggest you delay the decision.
    – Kyle
    Jun 26, 2012 at 12:56

Is it better to make such rather simple design decisions up front, even there is no need in the current situation, or do we have to change a lot in the later progress of the project?


It would have been better if someone realized that by slapping in another responsibility that the resultant class would be bad. Agile doesn't mean no design, it just means design (well) for what you need. You'll always need a maintainable codebase if you're making a framework for future products.

That said, mistakes will be made. Requirements will change out from under you so something that used to be a good design is no longer so. Then you need to be dilligent in refactoring, or at the very least documenting that technical debt to be prioritized for later sprints.


You're asking fairly broad-brush stroke questions with a minimal amount of context. That will affect the quality of answers you'll get.

If you discovered a problem that violated SoC within a few sprints after it's creation, then YAGNI doesn't quite cut it as an excuse. That's more to effect of "deliver anything" rather than deliver a maintainable solution.

The product owner should be providing enough long-term vision so the development team as a whole can make the correct design decisions. If the long-term vision isn't there, then a broader level conversation needs to be had so everyone knows problems like this will creep up again. Keep in mind that you don't have to keep hammering on that issue. Note it, make sure the consequences were understood, and get back to coding. The next time that type of a problem creeps up, point out that this was noted a while back, deal with the schedule disruption, and get back to coding.

If the product owner isn't able to communicate that vision, then it's worthwhile to have a few key members of the team spend more time with the product owner so the team can get a better understanding of what's coming next.

Honestly, this sounds like more of a communication issue as opposed to a development methodology issue.

  • The problem in my opinion is the clash between "do the least necessary" against "do it the cleaner way". It feels not right for me mixing up the logic for feeding the IoC-Container with initialization infos with the logic for a hardware driver, because I know that I don't need the IoC-Container in that driver. Even if it is not intended to be used further, it is, at least for me, easier to understand what part of the programm is assigned to do what. Can you give me an example how to solve such an issue?
    – dwonisch
    Jun 25, 2012 at 16:29
  • 1
    @woni - part of what you're asking is the value placed on maintainable code. Often, people don't recognize the role of maintenance until they've been burned by fixing some pile of crud. I have found there are teams that want to improve and get better, and then there are teams that are just cranking out bits to pay the bills. Try to objectively demonstrate how YAGNI-as-an-excuse-for-lazy burned the team and caused significant rework. With time, you'll build up a number of cases where that occurred. Either the team will want to change to avoid that pain, or you'll want to find a new team.
    – user53019
    Jun 25, 2012 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.