"In fact, software development methodologies are one of the biggest delusions of all. They help keep us sane by protecting us from the truth that building software is hard. They delude us into thinking that by following a preset script we will end up successful, that even the biggest software challenges can be overcome by engaging in a widely varying set of patterns and practices, that somehow if we all just planned better with a more precise schedule or gave ourselves the freedom to think big and react quickly the actual problems of finding the right solutions and building the software will take care of themselves. Yet, its just not true. On some level we know its just not true. Every project always ends the same, with some piece of something produced and everyone bemoaning how horrible the process was or how intolerable or inflexible.  Instead of realizing that it is just hard and we are not really good at doing it, we distract ourselves by diving deep into naval contemplation, trying to devise improvements for the process for the next go around. However, we might as well have gone out and gotten new haircuts for all the good it does us.

The truth is that most of us can't really build software well, no matter the system. A few among us, however, can with apparent ease accomplish just about any development task, to any degree or complexity, in spite of whichever methodology is in use. We deny this too because it upsets the belief that its the methodology, not ourselves, that is really at the heart of the matter. We think of these folks as renegades or cowboys. We build up even bigger defenses to minimize the damage and marginalize their impact. We tell them they can't work on the entire project, they must pick some smaller piece befitting a mere mortal. We wall them off into little rooms and let them build, and then we fear what they produce, because it always ends up grander, more complete and more compelling than all the work done by everyone else combined. Often their work surpasses even the most ambitious dream. Yet we react to it by squelching it using backroom politics, voting it off the island.

The truth is, that if we could only harness the power of these exceptionally brilliant few in a meaningful way we would be ahead of the game. Instead of devising systems to distract ourselves into believing we all can do it, why not acknowledge the fact that really only these few know what the hell is going on and build a system to basically keep them functioning at prime efficiency? Instead of textbooks lauding the latest practices to keep our armies of developers in sync and on track, we should be pull the men out of the silos and teach them how to be a support team for the guy or gal in the center.

" (Matt Warren)

 

You have to have talented people so that when the process breaks down, the project is still successful. Nothing replaces the people quality in a creative endeavor  like software programming. This why you see innovation such as RubyOnRails was created by one guy compared to the team of programmers, PM and processes in Microsoft ASP.Net team.

 

"Sure, you can take a bunch of typical developers and have them slog out the implementation of an LOB application, and you'll get what you get, some confusing, arcane, input-forms nightmare, babble of buttons.  Or you can focus them all on aiding the prime ape on his journey to producing a masterpiece of technical wizardry that not only solves the LOB application problem, but allows the company an opportunity to rethink its corporate strategy, refocussing instead on the sale of that very same LOB app to the other fortune 500's, boosting profits for the year by 1000%, cornering the market and becoming the next big software powerhouse to compete against Microsoft.

It's your choice." (Matt Warren)