Yagni And Reuse

Wow. This seems to go against at least one version of OO philosophy, which I understand to favor building objects with integrity and cohesion and completeness, so that they stand alone, and can be understood and reused in isolation. This may mean including features that are logically part of the object even if you don't need them right now.

Unless your project has a very liberal deadline, investing in reusability "in isolation" is done at the expense of whatever your customers think they're paying for. This is very risky and should be done only rarely and after careful consideration. It should not be a habit.

It's a lot of fun to exercise one's mind and build nicely general classes. But our job is to provide value to our current customer, generally within a tight deadline. Building for tomorrow is very risky when the project is due today. --RonJeffries

Suppose you write a Widget. Six months later someone needs a Widget. They come to your class, and find it's missing some obvious piece of functionality. Maybe they'll add it, maybe they'll ask you to add it, maybe they'll write their own Widget (and do it properly this time). Some of these choices involve politics and administrative overhead, depending on your company culture. This impedes reuse.

The XP way to do it is most likely to add the necessary functionality (we do not practice CodeOwnership). If the class is tricky to understand, practice PairProgramming with the original author.

Maybe you will do it properly this time. No problem, do it. If you replace the class, the right thing is to replace all the original references. (Here's where you get the reuse.)

As talked about below, this approach may (may) work better in the small than in the large. OTOH, I'm not aware of many organizations that are actually profiting from reuse. OO, especially in Smalltalk, provides more direct benefits in building apps quickly: these are the benefits most organizations need today. --RonJeffries

Reuse is a means to an end. It is not a goal in and of itself. Some people behave as if they think that it is. Some people who own code attempt to take advantage of that by selling it--in effect, they are saying "reuse of our code is good (whether or not you really need it)". These people, in my experience, are by far the loudest proponents of code reuse.

I smell a conflict of interest, especially when the persons or groups doing the selling have interests other than earning a living.

Reuse is just what you get after applying OnceAndOnlyOnce. If you need reuse (as opposed to gonna need reuse), you'll reuse. Otherwise you won't.

OpenSource and FreeSoftware projects are the ultimate proving ground for theories about the usefulness of reuse--there's no CodeOwnership, and few extraneous reasons not to reuse code. There's a lot of YAGNI, a lot of reuse, and a lot of just plain duplication (with and without cause). --ZygoBlaxell

I don't know if YAGNI discourages reuse. It simply suggests that you shouldn't plan for every possible contingency. I have created 'common' classes that start with a few simple methods, but over time have evolved to be a very full representation of a concept. (The object that I have created under at least three or four different contexts (i.e. employers) is a 'Date' object. They typically start small, but evolve to handle different constructors, validation methods, business logic, etc. Not much risk in adding methods, just keep a careful eye on UnitTesting) -- ChadThompson

Moved from YouArentGonnaNeedIt

RonJeffries asked: "Who is funding the development of these requirements that the user doesn't have?"

Some organizations have the following scenario: multidisciplinary projects, so software does have lead time. In-house systems which are planned to undergo a great deal of churn because they are used for scientific experimentation and new requirements grow viciously off the results of the work. The creation of a framework can help with these forces even though it is risky. One approach to dealing with things that "you are gonna need" is what I call GuerrillaDomainAnalysis. To answer the question, orgs fund this to get ROI. --MichaelFeathers

The funders don't pay for me to go to the bathroom yet i do anyway. Customers purchase features. As developers we decide what is the best way to implement them. Customers don't design the system and they don't program it. That's our job. You can't use the customer as an excuse not to do work. If i think the best way to make something work then i'll do it. An architect won't underdesign a building just because the customer only wants to pay for surviving a 6.0 earthquake when the architect knows these are common and it's standard to design to an 8.0 earthquake. Sure, this makes the building more expensive, but it's the "right" thing to do. --Anonymous

But then, wouldn't the architect have brought that up with the customer before he began on that iteration? --cwillu

I've been on lots of projects where management decided the reusable aspect wasn't worth it - the deliverable came first. Few where, when the schedule crunch came, they happpily extended the time to support future reuse. Your mileage? --RonJeffries

..varies a bit. But then, I work for a corporation that was private, but has just been bought by a public company. The squeeze will ensue, I suppose. --MichaelFeathers

What I've read in the magazines and journals suggests very low return on internally funded "reusable software". It is either created without a first use, by some separate organization, or created along the way by a team whose primary focus is delivery of something useful. Neither is ideal. Maybe reuse is a phantasm? --RonJeffries

I've seen it happen, but it takes a while to get it right. It is a game that requires commitment, timing, judgement, and a domain with some stable aspects. True enough, I've seen the two scenarios you mention play out. Obviously, the latter is better than the former. I've seen it happen when developers get tired of writing variations of the same code over and over, and a manager is willing to take a chance. -- MichaelFeathers

From what you are saying, it sounds like XP doesn't perform well in those cases where requirements are unclear. Consider a ProductLineArchitecture or ComponentBasedArchitecture? where you may have to meet the requirements of several products, not all of which have been fully specified. So, in a way, XP works best for low reuse projects or projects that do not have shared CoreAssets. However, when working on a single application with well defined UserStories, XP performs great. At least this is my impression taken from my experience. However, all I need to see is some evidence otherwise to change this point of view. Evidence would be a large component-based product or architecture that was developed using XP and not methodology talk. -- RobertDiFalco

What methodology works well when requirements are unclear, and why?

Well, I mean for something like a product-family architecture where one wants to accommodate future products that fit in that family. There is a big difference between the requirements for the applications of a framework and the requirements for the framework itself. For the latter, and regardless of what is said, these requirements are largely manufactured from (a) the analysis of the problem domain and (b) the experience of the architect(s) or designer(s). Any large component-based framework or ProductLineArchitecture requires a good bit of design and analysis up front. Actually, JanBosch has a great book on the topic which discusses the idea of having to come up with an architecture when the requirements are unclear. Whether you like it or not, requirements will be unclear anytime you design assets for reuse. Something else you may want to check out is the SEI's ProductLinePractice (PLP) initiative. This is a little more rigorous, but also fits well for these kinds of situations. -- RobertDiFalco

I think you are probably right, XP only works with clear requirements. Rather than building reusable frameworks up front for unclear requirements it builds system based on requirements which may evolve into frameworks over time. Having skimmed the ProductLinePractice stuff at SEI it looks like PLP is still in the 'cool idea that has worked twice' category (a bit like XP really ;-). -- TomAyerst

Any code - shared or not - developed in the presence of unclear requirements will be found to be wrong as the requirements are exposed. A successful library that is born into the world had a period of development where its requirements were discovered and its design modified accordingly. If that period of development was hidden, and if the developers used the library like you use it, then you'll find a well designed library that appears to have been purposefully designed. Don't be deceived. It, like all successful code, was raised from a small, helpless child.

I never know how to reuse a piece of code until I've first used it. And I never know how to generalize something until I've used it at least twice, probably three times.

I think there is a pretty big difference between clear application-oriented requirements and knowing how a class will be used. While the latter needs requirements, they need not be static nor highly detailed. Consider, for example, the Smalltalk runtime classes. I doubt there were clear requirements for the types of applications that would use these, however, general understanding and use gave them a good idea how a collection hierarchy should be designed. And, guess what, their anticipatory design was pretty successful. Balance is the key, not everything can be YAGNI and not everything can be reused. -- RobertDiFalco