Yagni And Cost Of Change

Moved from YouArentGonnaNeedIt

YouArentGonnaNeedIt feels philosophically 'wrong' to me, or "too eXtreme" if you like. The assumption seems to be that "when I realize I do actually need it, I can make it then". However, when external change happens as it inevitably does, the key factor for survivability is adapting to that change as quickly as possible. You aren't gonna have time to implement it from scratch once you realize that you do in fact need it. YouArentGonnaNeedIt is just the other end of the spectrum from overplanning. Personally, I would prefer something along the lines of RationalForethought? -- anticipating probable changes. There will be a tradeoff between time wasted in the present on anticipation of those possibilities that never eventuate and the gain in reaction speed to those anticipated possibilities that do eventuate. -- AndyPierce

YouArentGonnaNeedIt definitely relies on low cost of change to be effective. The key is to realize that YAGNI is a statement of (what is usually) fact, not just a cute name for something to consider in your work. In software development, far too much effort is wasted because developers thought they should add something for the future, but never used it. Basically, if experience shows us that we repeatedly show poor judgement in deciding what to plan ahead for, we need to find a new approach. YouArentGonnaNeedIt can provide a large enough increase in productivity by removing the time wasted on unused features, that even a moderate cost of change can still be acceptable. -- PeterHansen

Anyone for IrrationalForethought? ? ;-)

The funny thing is that XP is optimized for reacting to external change extremely fast. If you really want to build some infrastructure in early to save work later while still being a little Extreme the important thing would be to get the customers to agree to the work at the time and to make sure that you have some proper stories and functional tests for the work. That should stop any InfrastructureCreep and ensure that everyone understands the costs of what you are doing. -- TomAyerst

Something that worries me about You Aren't Gonna Need it is the binary nature of the decision compared to the somewhat more analytical EconomicsOfXp. Why can't we assign probabilities to the likelihood of needing facilities and factor those into the decisions? After all, if it's 75% likely we'll need something in 2 months, and it will take three times more effort to add it then (maybe it's an extra layer in the architecture), maybe the risk is lower just doing it, and accepting the downside cost of its not being used. -- DavidThomas

Because the time and energy spent deciding whether or not to work ahead can be more profitably spent doing a better job of testing and refactoring what you know you have to do. This is compounded by my observation that when I feel like working ahead on this thing it is almost always because I am afraid of working on the next thing. I am far better off facing my fear and continuing. Plus it won't take three times more effort, it just won't, not with tests and refactoring and pairing. -- KentBeck

I disagree about the level of effort involved in some cases. Say for example we were writing a database-based system. Initially it was speced for a single user, so there's no need for locking (say). Now we could write it that way, or we could say "adding locking now is a linear process, but adding it to existing code is really, really hard, so let's put it in now, as the user is likely to want to make this system multi-user in future". (I've been there-I once came into a 100kloc project where no one had known about transactions. They had to abandon most of it, as they couldn't add the transactional stuff without major, major restructuring). Wouldn't we be better off taking a small hit now, even though we technically didn't need to?--dt

No question that you can climb the cost curve without unit tests, pairing, and refactoring. My working hypothesis is that with these practices, the cost doesn't go up nearly as fast, nor are you as likely to have to make massive refactorings, and even if you have to completely restructure, you can do it in digestible little chunks without disrupting ongoing development.

We have a TwoByTwoMatrix?- with and without the practices, and with and without thinking ahead. Without the practices and without thinking ahead clearly doesn't work (as you said above). With the practices and with thinking ahead pretty clearly will work. Without the practices and with thinking ahead is problematic if you guess wrong or you simply don't know. With the practices and without thinking ahead is the XpWay?, and it has lots of advantages.-- KentBeck

In the database situation above, hopefully the XP team would ask the customer before adding transactions. The team might explain the cost of transactions through the PlanningGame, and ask if the customer wants to rewrite some stories to support a future multi-user system. The developers could explain that future conversion to a multi-user system may be much harder unless multi-user stories are implemented early in the project. (This would be like making a stronger foundation if one hopes to add extra stories to a building.)

If the customer chooses to revise the stories, the team would write the transaction code for the "multi-user-capable" stories/tasks. If the customer decides to keep the single-user story, then single-user code will be written. One of the most attractive features of XP is the power it returns to customers. The developer's role is not to decide what the customer should want, but instead to give prices for what the customer really wants. -- CliffordAdams

Transactions might very well be the simplest way to implement earlier stories. If so, and you know about them, put them in. You're not supposed to be deliberately stupid, just not put in unneeded complexity.

One thing that may be an issue for such systems is when changes to future classes break data versions of a class. Adding/deleting/moving members around can cause problems for systems which rely on those data members being present in particular class level. This is a particular issue with Java Serialisation, because in the serialised file there is a specification of what members are present and what are not.

In order to future-proof data files, we have had to spend some time designing our data hierarchy so that we can easily extend it at a later stage. Failure to do this up front may result in run-time exceptions when loading older data into newer classes. -- AlexBlewitt?