How People Really Are

You can't be sure that you'll need the functionality later, but you can be sure that you don't need it now.

But of course everyone will learn to use the code the way it is because they won't know enough to make changes or just won't make changes. More wrapper code will get generated to make up for what the class can't do. When the new changes are actually made it takes a long time for the "training" on the new capabilities to filter throughout the development group. Old code won't get changed and it's unlikely a lot of new code will take advantages the new features. And why? Because some code may not get used. Your fear makes the system worse, not better. It's actually a lot easier to remove stuff nobody used than add useful stuff later. The large group dynamics make this true. And if you think nobody will take it out then there's no reason to expect anyone to add anything in either.

This points to a deeper problem, though. When someone wants a method in a class, and it's not there, why don't they just add it right then on the spot? Is it because they're afraid of breaking something else? Then you need to make more use of UnitTests. Is it because they're not allowed to change the class? Then you need to consider CollectiveCodeOwnership.

But until then, it's best to leave the unused functionality out. When you read prematurely generalized code, it tells you "This is what the code might be used for one day." When you read pared-down code, it tells you "This is what the code does right this minute." Which would you rather know?

The code is what it does right this minute. It was generated by UseCases and has UnitTests. There's no "one day" about it.

You also need to consider HowPeopleReallyAre, HowGroupsReallyAre?, and HowManagementReallyAre?. It's wonderful to talk about CollectiveCodeOwnership and Refactoring and all those other things that allow you to assume magic can happen, but that ain't how it is at many places, much of it having to do with politics and a management not understanding software. The same culture that may work for small centralized groups of dedicated people does not work for large groups of decentralized people with varying skills managed by marginal managers. You can say this is a problem. It is, of course. But saying IfOnlyEverythingWorkedThisOtherWay? we could do this is of very little help.

A cynical view might be that we aren't that much interested in "how it is at many places". We are concerned that things should be better where we work. I'd rather work with a team that knew how to add functionality or generalize existing functionality just in time, and wasn't afraid to do it. If I can't have that, then I'm going to do my damnedest to get them to that point, even if they have to be dragged kicking. -- LaurentBossavit

So if you go to Africa as part of PeaceCorps? you'll recommend that a small blighted village just get itself a fission reactor, a water purification plant, create an industrial base, adopt a democratic governance, and just say no. If they don't "get" this you'll just drag them kicking? There's such a thing as appropriate technology to the environment.

This comparison is a bit out of proportion, though. In the PeaceCorps? example, you're trying to help people and help your own karma. If you don't do it, there aren't many other people who will, and you may help to drastically increase their quality of life. Most computer work does not have such a drastic effect on the quality of people's lives, and in any case since the whole enterprise is for-profit, you're not under any ethical burden to do work you don't want to do. (See also: ChangeYourOrganization)

I know strictly nothing about what would be good for African villagers. I do consider myself, because that is part of my job description, entitled to empower my coworkers with respect to tactical design decisions, even if this involves some painful unlearning on their part (and, quite likely, some painful learning on my part). -- lb