Shun The Light

Developers neither like nor trust innovation. The tried and true, the safe and known, the tidy and obvious, there are many dozens of wiki pages that emphasize again and again the folly of grand schemes and untrod paths. If the wiki is to be believed, YouArentGonnaNeedIt.

The wiki doesn't say it, just some ExtremeProgramming guys. And please, YouArentGonnaNeedIt doesn't say don't innovate: it says do what you need now now, what you need later later. Innovation is orthogonal to YouArentGonnaNeedIt. See further below. --RonJeffries

And yet there are many among us - WardCunningham for example - who have innovated successfully and thereby done great things. Ward's CRC techniques and this here wiki amply demonstrate that, sometimes, innovation and vision are what's needed. For every pattern here, tried three times and vindicated, there must have been some unreasonable smart-ass who first championed and implemented it, no doubt over a chorus of derision and disgust.

So ... when should the patterning leave off and the innovating start? How can we make it easier for innovators to work within a pattern language? Must an innovator really implement the thing three times before the howls of pain cease? Is there no room for the soaring vision? Must we always ShunTheLight?

1. You don't have Ward's talent that enables him to make such breakthroughs.

2. You don't want to pay the price that Ward has paid to make such breakthroughs.

3. It is far better the ShareTheLight?, for you, for your team, and for your customer.

4. If you feel like telling me to bugger off right now, maybe you are willing to pay the price. Good luck to you if you are.

Yes. Innovation must always be painful. Our instincts to stick to the tried and true serve us well because there are far more bad ideas than good ones. The only way we can distinguish the bad from the good is by attrition, by beating down the innovator to force him to refine his germ, by only accepting innovation when all else fails. Think of it as evolution in action.

And yet ... evolution is a punctuated equilibrium. When we do come to a halt, when all else fails, then an explosion of innovation and trial ensues. It's important that we both take on the refined wisdom and keep our minds open to new solutions. Neither NoveltyVampires nor PatternPrudes can carry the day - weigh your costs, pay your money, take your chances.

"The unreasonable man is the one who expects the world to adapt to his needs, the reasonable man is the one who adapts himself to suit the world. Therefore, all progress depends on the unreasonable man." -- GeorgeBernardShaw

Developers neither like nor trust innovation.

If by this you mean "professionals who are being paid to produce timely solutions to problems prefer to minimize risk by choosing proven technologies and methods," then we have some basis for agreement. I enjoy innovation, but avoid it when placing large bets with other people's money.

How can we make it easier for innovators to work within a pattern language?

This presumes that it's hard. I rather think the opposite is true. Laying the groundwork for an innovation takes time. Having a toolkit full of patterns within reach helps makes the groundwork go quicker, leaving more time for innovation.

If the wiki is to be believed, YouArentGonnaNeedIt.

I recommend re-reading RonJeffries accounts of the C3 project with greater care. Kent and Ron used some innovative process ideas to pull that project off. --DaveSmith

Thanks, Dave. The ExtremeProgramming practices don't say not to innovate: they say to innovate simply and only in the context of what (innovation) you actually need. In my opinion, if you are trying to innovate, your best hope is to do as little as possible, to get to the core value of the innovation rather than get buried in trivia that don't add value. --RonJeffries

Hmm. Developers neither like nor trust innovation doesn't sound like my experience of developers; NotInventedHere is more the norm. Suspicion of innovation for its own sake would be more the reaction of the seasoned professional engineer (I know, DisciplineEnvy, but there's a need for some range of terminology), and often represents conscious suppression of an urge for innovation (in my experience anyway).

Patterns, in practice at least, represent the accumulated knowledge of effective ways of doing things (whether they can be taught as such without the experience seems to me an extremely open question). Some zealots today seem to envision a world in which developers simply refer to a printed catalog of published patterns and treat those as the "Software ICs" that objects were going to be, according to some. Such a usage pattern (PatternPrudes?) might stifle innovation, but I don't see it happening.

YouArentGonnaNeedIt is a point of lively debate, not wiki consensus. I think it's a great pattern, but relies on a context of considerable institutional wisdom and can't be taken in isolation. --JimPerry

Just so. Further, YouArentGonnaNeedIt and DoTheSimplestThingThatCouldPossiblyWork are practices for getting done what you have to do, not statements that you shouldn't try to do hard things. It's fine to do hard things, but to succeed it's best if you do them simply, and without doing what you don't need. --RonJeffries

There's innovation, and there's reinventing wheels. The pattern movement is partly a reaction to having too much of the latter. People spend time worrying at problems which already have adaquate solutions. If you know and apply existing art, you have more time to innovate in those parts of your project which are unique. -- DaveHarris

Innovation comes in many directions, and on many planes. My work is focused very much on simple, flexible, robust, well-factored code, and very little of it uses fancy algorithms. My work isn't boring, though, because solving these simple problems simply gives me more time to take on bigger things. I get to have more free time to pursue freelance writing and art; at work I have more time to spend talking to my boss and having an influence on the overall (non-technical) direction of the organization.

Don't make trivial problems difficult. Keep them trivial, and save time for the truly difficult problems. -- francis