Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
Odds are whatever you'd consider "flexible enough" up-front will be either too unflexible, or way too flexible. –  delnan Apr 25 '12 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 :/ –  Sameh Serag Apr 25 '12 at 15:21
add comment

2 Answers

up vote 9 down vote accepted

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.

share|improve this answer
    
Then, the key here is continuous refactoring + automated tests. Thank you! –  Sameh Serag Apr 25 '12 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. –  kevin cline Apr 26 '12 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 '12 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 '12 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 '12 at 14:21
show 3 more comments

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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