22

I'm currently coding a new application for my company that is rather involved. To meet the deadline, the functionality has been toned down quite a bit so that we can have something ready to go for launch.

I've been given the task of getting version 1 up and running by the end of the month. I'm about halfway through development and I've come to the point now that there is an end in sight.

Yesterday, I spent some time coming up with a very nice easy solution for one of the requirements and am quite proud of how it turned out. This morning the version 2 document was sent out, and there is a requirement in there that will require the code I wrote yesterday to be either gutted, or severely changed. It would require a lot of work in the future if I leave it the way it is. I can take an extra day now to make my current solution more robust so that the v2 feature will be able to be added with a lot less effort, but that will put me a bit behind for the extra coding it would require.

I don't know if I'll be doing v2. It might be me or it might be a co-worker, or even an intern.

If you were in my shoes, would you spend the time now to make it easier in the future, or would you leave your solution and deal with it when the time comes?

Improve this question
2

6 Answers 6

Reset to default
18

If the deadline is Carved In Stone, just finish what you have to meet it. Make sure that you inflate the estimates for v2 to accomodate for the code changes for the new requirement. Also be sure to briefly document what you think will need to change for the new v2 features so that a co-worker can pick it up if you're reassigned to something else.

If there's enough flexibility in the deadline (1 day, by the sound of it, so aim for 2.5 days extension) then sure, go ahead and code for the known future!

Improve this answer
3
  • 1
    +1 for the suggestion to document the more robust solution. The feature may or may not be implemented exactly as you planned, but it's definitely a good idea to inform the future implementer about your thoughts on the changes.
    – Mike Partridge
    Commented Jan 17, 2012 at 16:34
  • 2
    I actually started writing out the method stubs for the v2 anticipation this morning after reading the document. I think I'll leave it at that and some comments to say how these will play in the future. Thanks :)
    – Tyanna
    Commented Jan 17, 2012 at 16:57
  • 1
    Keep your eye on the ball.... my experience is it's a bad thing to concern yourself with anything to do with V2 when you have V1 deadline about to hit you between the eyes If it's flexible its not a Deadline. If a development misses a Deadline, it is the developers fault.
    – mattnz
    Commented Jan 17, 2012 at 22:21
14

Avoid falling prey (early) to the Second System Effect. Here are some good techniques to apply:

  1. Definitely avoid de-railing version 1 just because of what you see coming up in version 2. Planning ahead is fine, but the creator of the v2 specs should be responsible for the failure of v2, not v1.
  2. (If possible) see if you can have the creator re-work the requirements for version 2 that won't require the larger changes now - and then plan for them later, maybe for v3.
  3. Keep YAGNI in mind, but try to code for extensibility in mind - avoid magic numbers, hard-coded values, write good unit tests or code contracts, etc. Applying good techniques early on will make refactoring and code changes less painful along the way.

Most software projects that grow like cities are successful in the long run. Evolutionary planning only into the limited future lets your software release on-time and with the functionalities required at release - and no more. See this excerpt from Carl Sagan:

The arrangement [of a city] might be more efficient if all civic systems were constructed in parallel and replaced periodically (which is why disastrous fires—the great conflagrations of London and Chicago, for example—are sometimes an aid in city planning). But the slow accretion of new functions permits the city to work more or less continuously through the centuries.

Improve this answer
2
  • I like the idea of talking with the designer and management to see if they are married to that feature. I see it more as a useless bell that will cause more work than it's worth...but then I'm a stressed dev atm. :)
    – Tyanna
    Commented Jan 17, 2012 at 16:55
  • 2
    +1: Avoid trying to predict the future. When it arrives it will be surprising.
    – S.Lott
    Commented Jan 17, 2012 at 21:38
8

Do not add code today for next month's requirement. Today you should write the cleanest code you can for the requirements you have. I'm skeptical that a day's work now will save multiple days later. I've heard claims like that, and can't recall a single case where it was true. You might be able to convince me by showing some code, but my experience tells me that is unlikely.

Improve this answer
3
  • It's true, but it's only true if you have the time up front to plan it out up front very thoroughly and you have the requisite business knowledge to anticipate the nature of various changes. Given most business situations though (now, cheaper, smaller) I agree completely with your statements. I do have some examples, though, if you're a true non-believer :)
    – Joel Etherton
    Commented Jan 17, 2012 at 16:43
  • @JoelEtherton: Even if you have the business knowledge, anticipating changes is very hard, to the point that it's often not worth trying... just my experience.
    – sleske
    Commented Jan 20, 2012 at 9:41
  • @sleske: Sometimes possibly, but my experience has been in both directions. In my current job, good planning and foresight has saved me a ton of extra headaches.
    – Joel Etherton
    Commented Jan 20, 2012 at 10:59
6

Leave as it as it is.

Developers actually APPRECIATE a legacy project that does what it is supposed to do and no more.

What, today, may seem like a good idea for "staging" the codebase to meet a "future" requirement, will in all likelihood act as an obstacle to understanding the code in the future. No one likes to deal with partially implemented functionality and vestiges of forgotten phantom requirements. I'm not saying that will be the case, but things often turn out that way despite the best intentions.

Improve this answer
1
  • +1 for "no half-implemented functionality". Wish I could upvote more.
    – sleske
    Commented Jan 20, 2012 at 9:41
1

Good answers. I would only add - what I do in a case like this is take a good diff so I can capture what I've done and squirrel it away in a safe place. Then if the opportunity comes to do it again in the next version, it will be easy.

In general, a good developer anticipates future requirements, but when a deadline is looming, it's time to respond to bugs in what you've already got and not "rock the boat".

Improve this answer
1
  • Good idea about keeping changes separate. Instead of a diff, a branch is probably a better idea (visible, easier to merge etc.). You can always delete it later.
    – sleske
    Commented Jan 20, 2012 at 9:42
1

It depends. There's a good old-fashioned rule: treat other people like you want to be treated yourself. What would you do if it was your own project and you knew all the priorities?

If v2 is definitely required and deadline is only a wish rather than hard necessity then don't create technical debt and mend your sails while weather is fine. Even if someone else will do v2 they will appreciate the foresight.

If there are any doubts about necessity of v2 then stick with YAGNI. Also if you on the other side of the spectrum and have one of those clients who constantly spam you with their ideas before they formed then check your emails only 2 or 3 times daily and don't rush with the action, you'll be surprised how many "problems" and requests become irrelevant before you even read them.

Improve this answer

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.