Andrew Peters’ Blog

The BackgroundMotion community site and ASP.NET code sample that we worked with Microsoft to develop has gone live. w00t!

If you’re interested in ASP.NET you definitely want to check out the sample as it illustrates one approach to architecting .NET web apps. The architecture was really designed to facilitate rapid development so emphasizes things like testability etc. My personal highlights of the sample are:

• Use of a domain-driven design techniques. Repository and Unit of Work abstractions over LINQ to SQL
• Model-level validation using the Validation Block
• Dependency injection using Composite Web Block
• Using Lucene.NET to index a domain model
• Using MVP with declarative data-binding in the presentation layer

Let us know what you think.

Ambler nicely articulates in The consequences of fixed-price IT projects the fundamental problem facing IT services companies.

Basically, the problem boils down to an impedance mismatch between the traditional customer/vendor dance on the one hand and modern software development methods (agile) on the other.

My feeling is that IT services shops should use variable-priced contracts as a competitive advantage! Why? Because as Ambler points out, more often than not, fixed price projects are a mess. I’ve seen this first-hand and it seems particularly endemic in the New Zealand market. Such projects lead to, among other things:

• Angry/disappointed/frustrated customers as the price goes up late in the delivery, or when the delivered system sucks.
• Low staff moral as they are left to pick up the pieces (read long hours.)
• Developer frustration as attempts to bring in agile methods are mostly futile when working in a fixed-price setup.
• Propagation of the fixed-price vicious cycle. The customer was burnt last time so this time the contract will need to be even more bullet-proof.
• Increased risk for all stake-holders! The vendor has no idea what they are building or how much it will really cost - even though they have committed to both in a contract! The customer has signed up to get a system that may not meet their requirements and will most likely cost more than they expect. When these cost overruns come near the end of delivery, they are virtually impossible to walk away from. Some despicable vendors actually leverage this approach to make more money. i.e “That sounds like a change request and it sounds expensive.”

So what would I do if I were running a services company?

Embrace contracts based on “variable-priced projects with gated investment based on interim deliverables (ideally working software.)” Sure, some customers will require education and some deals will just have to be walked away from. But over time, constantly delivering better software, more quickly and with less risk is just too compelling and word gets around. I have no doubt that the first service shops that can successfully adopt this strategy will win.

As Obie points out, an additional benefit of pairing, although not often mentioned, is the fact that if forces developers to actually do some work! In the age of continuous distraction, how many hours do you spend actually writing code vs. gawking at YouTube etc.

“Most developers that I’ve met (except at TW) hate pair programming and I chalk it up to human nature. Truth is, pair programming is one of the only effective ways that a lot of us have ever witnessed keeping average developers from pissing away 95% of their productivity engaging in non-work such as reading and writing blogs, instant messaging, personal email, shopping online and otherwise wasting time on bullshit. When you’re pairing, you simply HAVE to work all day. Yes, it’s exhausting, but incredibly effective. As my friend and former boss just mentioned to me a sec ago…”

I have a feeling that, in light of this insight, most arguments around pairing being wasteful of resources fall flat.