Conventionalism over Confucianism

Since the .NET 1.0 Beta was released in 2001, I've been firmly in the .NET camp. However, there is (at least) one thing that the Ruby-on-Rails guys really nailed - Convention over Configuration.

How should I organize my solution? What should I name my views? What should I name my product category table this time (tblProductCategory, ProductCategory, or product_category)? How should I test my data access layer? In my opinion, the best answer to these and the thousands of other trivial decisions we make as developers every day is "You tell me" or "I'll tell you", but let's be consistent.

During my time as a developer, I have made two observations about (non-Headspring :) ) developers. First, most developers feel entitled to largely contribute to these kinds of decisions or outright make them for themselves (and thus not be consistent with the rest of the team). Second, in pursuing their agendas, they feel justified in spending hours arguing the relative merits of their trivially different positions.

On the surface, this may seem like a plus. "Isn't it great that our developers are so passionate about pursuing perfection?" In practice, though, all this philosophizing about casing, underscores, solution organization, and other small issues comes at a price. That time is not spent thinking about software licensing, golf-club fitting, apartment locating, and Sarbanes-Oxley compliance (my last several projects). In short, it's not spent thinking about how to address the difficult business problems we were hired to alleviate through technology.

This is where clearly defined and rigorously practiced technical leadership is worth its weight in gold. Like in any discipline, a good leader relies on his or her own experience and seeks the input of other team members. The leader than aggregates all of this information, makes a decision, communicates the decision, and ensures compliance (through carrots and sticks). While developers tend to fear strong technical leadership, good leadership makes everybody more comfortable in their role by providing clear expectations. It also greatly increases team effectiveness (by eliminating wasteful discussions) and the likelihood of delivering software that truly meets the needs of the business.

This technical leadership is particularly important in the land of .NET. Let's face it - the development techniques Microsoft promotes in its sales demos, certified training curricula, and Patterns and Practices website do not generally constitute solid software engineering practice. For example, with the exception of Scott Guthrie and Scott Hanselman, I have yet to find anybody in Microsoft even talking about test-driven development.

To this end, Jeffrey Palermo has been working hard to harden the definition of the Onion Architecture. For at least our Headspring team, this architecture will provide guidance to better enable our technical leaders to move quickly and deliver excellence.