Agile Scenario, which is correct? [closed]

Question

Imagine you have user story 1 which requires the implementation of a method:

public static void MyMethod(string paramA);

Several classes will be using this method, and MyMethod does everything required to complete user story 1, but nothing more.

You are pretty sure that in a future iteration another story (user story 2) will come along which will require the method to become:

public static void MyMethod(string paramA, int paramB);

The previous calls to MyMethod will need to be refactored, and some new calls to MyMethod will need to be added to meet the requirements of user story 2 (Note after story 2 it never makes sense to call MyMethod with only paramA).

When working on user story 1 is agile thinking to:

1) Only implement: public void MyMethod(string paramA);

2) Implement: public void MyMethod(string paramA, int paramB); - But do nothing with the second parameter for now. Calls pass in 0 to the second parameter at this point.

3) Implement: public void MyMethod(string paramA, int paramB); - But do nothing with the second parameter for now. Calls pass in the correct value (according to the expectation of user story 2)

4) Implement: public void MyMethod(string paramA, int paramB); - And all calls Completely to cover user story 1 and 2

Answer 1

Just do 1.

Refactoring is easy, predicting the future isn't.

The project may be canned, new more important stories may appear that means story 2 is never needed, by the time you get to story 2 you may understand the problem better and need to refactor everything. There are endless reasons you mightn't need it.

Answer 2

On one end of the spectrum are the Agile purists that insist that everything can be accomplished by refactoring later. On the other end are the old-school Big-Design-Up-Front crowd that think you should build a complete architecture first and then snap features onto it. Your question is perfect because it exposes the failings of both philosophies if you mindlessly follow their processes. What you want is maximum efficiency. So you need to analyze what Story 1 and Story 2 are in your situation. Is your software shippable without S2 or did you just split up the stories to help with estimating and planning? If S1 is "Add to shopping cart" and S2 is "Check-out" it is silly to not build the interface to support S2 because your software is worthless without it. In every project there is a certain set of known "Have-to-have" features that make your software even worth shipping. If Both of your stories are from that set then I would say build the interface to support both now and don't waste time refactoring later (#3).

Usually if S1 and S2 are both in the must-have set they will be close together on the Backlog. If this is not the case then you either have a huge amount of must-haves and your project isn't going to gain that much advantage using Agile techniques or S2 really isn't a must have. So if you are expecting a large chuck of time (months?) to pass between the commitment to S1 and S2, then I would go with the 1 parameter interface. Time is always a huge contributer to uncertainty.

Answer 3

The purists will say option 1, but I'd listen to common sense and if you're absolutely 100% convinced that this is a requirement then I'd factor this in to your design.

HOWEVER Agile is also heavily based around refactoring, so as long as you aren't publicly releasing this interface then I would actually go with option 1 if changing this won't impact my design.