I'm currently choosing between two viable software designs/solutions. Solution 1 is easy to implement, but will lock some data in a proprietary format, and will be hard to change later. Solution 2 is hard to implement, but will be a lot easier to change later on.

Should I go YAGNI on this or should I incorporate the exit cost in the decision making? Or asked differently, is the exit cost part of the TCO?

I'm thinking of going back to the customer with this to ask whether or not he thinks the exit costs are relevant, but I'd like to know what the community thinks first.

P.S. Is exit cost the correct term?

  • Can you add why you think the first solution will lock the data in and will be hard to change later? – Jaap Nov 13 '12 at 11:57
  • In essence, aren't all formats proprietary, even ones that are supposed 'standard' or 'open'? Yagni probably applies if the 'proprietary' format is easier to implement, straight-forward to use, and/or the defacto format for exchange. – JustinC Nov 13 '12 at 12:20
  • Without going into specifics; think of it as placing an Excel sheet (designed by the customer) into a document management system (solution 1), versus creating the appropriate tables and GUI's and generating the Excel sheet on demand (solution 2). Except that it's not Excel. – dvdvorle Nov 13 '12 at 12:23
  • However this probably doesn't preclude noting this aspect of concern in presenting the choice and decision to the project sponsor. – JustinC Nov 13 '12 at 12:26
  • @JustinC well eventually we are talking about cash here. Is it cheaper to use the 'proprietary' format in the long run or not? That is what I think is most important to the project sponsor – dvdvorle Nov 13 '12 at 12:34

Exit cost is part of TCO (the T does stand for total), but it's difficult to nail down unless you know a priori how long the system is going to last. In other words, if you know the system will be used for exactly one year and it will cost $52,000 to decommission it a year from now, you can be pretty confident in adding $1,000 a week to the operational budget to cover it.

That model goes out the window when you don't know the system's lifetime. The system could, in theory, remain in use forever, which means there will be no money spent shutting it down. Anything you factor in now will be in today's dollars, and those figures could well be meaningless five years from now because of changes in labor rates and technology that make the process easier (or harder).

You'd be best off giving your customer some idea of what's needed to transition away from the system and let them factor that into decisions about replacement when that time comes.

(And now, having written this answer, I get to vote to close this as off topic.)

  • The alternative to the exit cost being part of the TCO of this solution, would be that it would be part of the TCO of the next solution. Now I know this sounds weird if I say it just like that, but in my experience the cost of decommissioning a system is made part of the project plan/budget of the next system, not the project plan/budget for the current system. Does that make sense? – dvdvorle Nov 13 '12 at 13:02
  • 1
    Makes sense to me, and that's pretty much the conclusion I came to. You can't really come up with an actual total until the whole thing is over and done with. – Blrfl Nov 13 '12 at 13:08
  • I agree about the difficulties of accurately estimating the 'exit costs', I think there's value in providing one even if it is in today's money. Compare "this would be difficult and time-consuming" and "this would likely cost between $25000 and $50000 if done tomorrow". – vaughandroid Nov 13 '12 at 13:30
  • @Blrfl, what makes this question off-topic? – neontapir Nov 13 '12 at 16:37
  • 1
    @neontapir: The meat of the question is really about project management; the fact that it's about a program doesn't really make it about programming. The same thing could apply just as easily to telephone switches or pizza ovens. – Blrfl Nov 13 '12 at 16:46

YAGNI is a great rule in its place, but I'm not sure it should apply in this case. You're estimating future costs here, an activity which ought to involve some consideration of future requirements changes. If you were writing the implementation it would be a different story!

I'd suggest you do the costing, but make sure that the customer understands why you've done it. If they aren't very technical don't be surprised if they say something to the effect of "it can't be a good solution if you're already thinking of using something else!"

There may be some more fine-grained aspects to consider when you're doing/presenting your cost estimates:

  • How likely is it the data will be migrated to another system in the future?
  • Is it likely that the solution vendor will alter their own data format so that it will be easier/harder to migrate the data in future? If so, will this affect your solution?
  • Even if you don't want to change the data later on, is there a chance that you might want to present/access it in a different way? My experience is that this is quite common!

Working from your comment about the Excel file situation, I look at it as:

  • not changing the current format (solution 1)
  • versus parsing the format now, and storing it in a different format (possibly/hopefully more suitable/future-ready) (solution 1 + parsing step, a.k.a. solution 2)

I believe YAGNI applies to that parsing step; make sure you keep the knowledge about the current structure, but don't implement the parsing yet.

Additionally, the parsed data structure may not be as flexible as you think; the requirements could aso go towards storing different information/files, which would mean you have to update/expand your tables.

  • To be clear, there currently is no solution (solution 0 if you will). They currently keep all information in paper files. I would wholeheartedly agree with this answer if they already used the "Excel" file in the document management system, but there is still a choice here. – dvdvorle Nov 13 '12 at 12:41
  • Or do you think that is not relevant because the implementation of solution 1 is cheap? – dvdvorle Nov 13 '12 at 12:43
  • My point is that I believe that if solution 2 can be considered an enhancement of solution 1, but that enhancement is not strictly necessary now, YAGNI applies. – Jaap Nov 13 '12 at 13:45
  • I see what you mean. It's something to think about. Though I think it's time to go to the customer now, see what he thinks about it being an enhancement and whatnot. – dvdvorle Nov 13 '12 at 13:51

If you are not 95 % sure it will be changed in future - Solution 1 - YAGNI =)

Surely it depends on your customers, and on your experience programming something for this customer.

  • 2
    So you're saying that any cost related to the 5% chance the solution will change is irrelevant? – dvdvorle Nov 13 '12 at 12:32
  • I mean that this some kind of feeling... You know yourself what "YAGNI" means - the rest is feeling =) – MikroDel Nov 13 '12 at 12:33

In my experience, reinvented wheels take longer to reinvent than you think, and external wheels tend to be easier to replace. Both kinds of wheels tend to look worse once purchased than they did when you made your decision.

If you truly think that #1 is easy to implement, and are questioning how long #2 will take, I would listen to the question. Implement #1 now, and think about the bigger design as you go. That will help you if you later want to reinvent it.

Conversely if #1 no longer looks as easy as you thought it did, jump to #2.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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