If I am about to develop an Enterprise application, but as far as I understand from agile process, I break features into small chunks and develop them iteratively. I used to create the database and the core of the application first, then I extend these iteratively.

The question is: Do I have to keep what I used to do previously (develop the core first) or I have to distribute core development over stories' development? In the later, I am not sure the code will be flexible enough for future extensions!

Any idea?

  • 2
    Odds are whatever you'd consider "flexible enough" up-front will be either too unflexible, or way too flexible.
    – user7043
    Apr 25, 2012 at 15:12
  • OK, are there any techniques for delivering good design/architecture while develop iteratively without developing the core first? sorry, I am new to agile :/ Apr 25, 2012 at 15:21

3 Answers 3


Do not develop the core first. A key principle of Agile development is to write the minimal code needed for the completed features. That way you can deliver at any time. The code stays flexible because you continuously refactor to eliminate duplication. Refactoring is supported by the automated tests you wrote for each feature as you built it. The core grows automagically as you factor out duplication from higher level code.

Basically, instead of building in flexibility in a usually futile attempt to minimize expensive future code changes, Agile builds automated tests to support refactoring, so that code changes are relatively inexpensive.

Martin Fowler's Refactoring is my favorite book on effective refactoring techniques. It is much easier to factor out a usable core than it is to define one up front. Defining a usable core before feature implementation is nearly impossible, unless you are merely reimplementing an existing API. And there's no value in that.

  • Then, the key here is continuous refactoring + automated tests. Thank you! Apr 25, 2012 at 16:58
  • 1
    @Girgio: Sorry, unclear. I meant there was no value in writing your own logging framework, or ORM, etc. instead of just adopting one of the many existing alternatives. It seems obvious, but I have seen multiple companies do just that. Apr 26, 2012 at 15:21
  • 1
    @kevin: I think that in certain cases there is value in going with your own solution. Something like Logging which is relatively small in scope, I would probably use an existing solution. Something like an ORM I can see value in rolling your own. Something like Doctrine has code to handle a ton of different use cases and features but what if I just need 25-30% of them. If I roll my own with own the 25-30% of the functionality I need, I will end up with something that is smaller, easier to use, and probably better performing.
    – ryanzec
    Apr 26, 2012 at 16:02
  • 2
    You can't simply refactor the architecture of a system into existence. This is a common myth of agile and architecture.
    – Michael
    Apr 26, 2012 at 17:26
  • 1
    @SamehSerag, "The core grows automagically as you [re]factor..." implies that the architecture is not being actively chosen but rather allowed to "automagically" emerge by coincidental choices about lower-level (not systemic-level) decisions. That is the problem with trying to organically "grow" the architecture through refactoring.
    – Michael
    May 25, 2012 at 14:21

My approach to agile development is to build "vertical slices". I take a story from the UI to storage and implement it. I have some lightweight tools that I use to help this process (like a simple IRepository/UnitOfWork framework that has adapters for In Memory(usually for testing), Entity Framework, and NHibernate. At this point I don't think there's much of an argument of whether one should use an O/RM but rather which one to use. And for me it depends on the environment.

I've found that this approach wins over naysayers regarding agile development because they get to see working software more quickly than if I spend a lot of up front time creating a core. Combined with Domain Driven Design and some other techniques I use, I'm usually able to get a lot of working functionality in front of the users very rapidly.

TDD or even post-hoc unit testing is important because part of maintaining velocity as your application grows is having that safety net that a comprehensive unit test suite provides. "I need to make a change to this class, how do I make sure I didn't break anything?" With a good unit test suite, it's as simple as running that test suite. Without, it becomes a matter of manually running through your app to verify. Not fun at all.


Craft the minimal horizontal framework that supports a vertical slice of functionality. The framework is crafted to be extensible and is where most effort is focused initially. The vertical slice of functionality is to demostrate that the framework supports real value. In subsequent iterations devote less effort as the framework is realized and more to building capabilities using the framework. Continue this way until the vast majority of effort is focused on functionality using the framework that developed over iterations.

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