(…) Gore has been a team-based, flat lattice organization that fosters personal initiative. There are no traditional organizational charts, no chains of command, nor predetermined channels of communication.
Instead, we communicate directly with each other and are accountable to fellow members of our multi-disciplined teams. We encourage hands-on innovation, involving those closest to a project in decision making. Teams organize around opportunities and leaders emerge.
Corporate IT needs the ability to run their own internal infrastructure projects without needing permission from the business.(…)
Most people in corporate IT want to do a good job. Most people in corporate IT are capable of doing a good job. Every developer I know is driven crazy by crappy code; they want nothing more than to get in there and make it better, stronger, faster. Most of the time, however, they are actively stymied from doing a good job because they can’t act on their own, best instincts. Sorry pal, but that’s not in the business plan.
The Free Electron is the single most productive engineer that you’re ever going to meet. I have not even provided a definition and I’m guessing a person has already popped into your mind that fits the bill.
A Free Electron can do anything when it comes to code. They can write a complete application from scratch, learn a language in a weekend, and, most importantly, they can dive into a tremendous pile of spaghetti code, make sense of it, and actually getting it working. You can build an entire businesses around a Free Electron. They’re that good.
Here’s a theory of software quality for you: software must be nurtured. The existence of bugs isn’t mysterious to any honest programmer. They are the product of neglect. (…) Programmers have complete control over the quality of their code and, when working on code they care about, tend to produce things that work. The secret is to care for the programmers, so that they take good care of the software.
Large organizations generally drive their software bees into combat formations, rather than nurturing colonies. Standardization is the mantra. Everyone will use one language, one set of libraries, and three ostentatious software “patterns.” In such forced conditions the feeling of code ownership vanishes and quality goes out with it. (…)
The alternative is obvious: break systems down into their smallest practical units, and let small groups of programmers determine implementations from top to bottom. Necessary interfaces between modules are hammered out according to the best available standards; unnecessary interfaces are not built. Coders get to work in their favorite technology, or learn a new one.
Similar Posts:
- Factors for Software Project Quality
- Another category for this blog
- On the Need of Minimalist Polyglots
- To Java or not to Java
- 6 blogs you should read… absolutely
- BarCamp Lausanne 2
- Best books of 2008
1 Comment
04.20.2009
Excellent quotes from some very wise people. Thanks for this!
Commenting