The half-life of a radioactive substance is the time required for half of a sample to undergo radioactive decay.
en.wikipedia.org/wiki/Halflife

Scott Bellware is talking about the rate of decay of the maintainability of a project.

The rate of decay of maintainability is the measure of how fast your maintainable code looses it's maintainability after your agile development guru or consultant moves on to another project.

This is a subject of a particular concern of mine, since I was often accused of building software that only I could work with. I am currently teaching an MSPD course with the express purpose of grokking the way that the average developers go about their work. It has given me a lot of insight into why Microsoft does some things (and I still vehemently disagree with the decision).

I taught data access approach using With and anonymous delegates:

With.Transaction(delegate(SqlCommand cmd)
{
   cmd.CommandText = "SELECT COUNT(*) FORM Customers";
   return (int)cmd.ExecuteScalar();
});

This is for people who learned C# as part of the course. It works, and while this is not something that they are likely to build on their own, once you set up the infrastructure and explain how it works, there weren't particular issues with this.

The crux of Scott's post is this statement:

The keystone of intentional maintainability, nestled in the slot at the apex of an arch of XP practices, is code that is instantly understandable by the folks who have to do the maintenance.

That is an argument that I have had with quite a few people, quite often. Because the problem is with the definition of "the folks who have to do the maintenance". At one time, I had a... discussion with someone that thought that they can hire someone off the street (purposefully low level, to keep costs down) and have them start working on a big (10 months of continuous development) project from day 1.

That meant, as far as they were concerned, that we were to use only the "standard" approaches, so we wouldn't break the wizards and make the application "unmaintainable". That is not maintainable in my book, quite the opposite, frankly.

From my point of view, an application is maintainable if I can take someone of the street, give them the overall view of how things work, walk them through a use case or two, and then set them on the code on their own.

This method belongs to the LoginController, and I am going to assume that it is going to be instantly understandable my most people who can read code. But, and this is important, it is not maintainable unless you figure out what is going on all around it.

/// <summary>
/// Authenticates the specified user, will redirect to the destination page
/// if the login is successful.
/// </summary>
/// <remarks>
/// If the login is not successful, additional information may be found on:
/// Scope.Flash[Constants.ErrorMessage]
/// </remarks>
/// <param name="user">The user.</param>
/// <param name="password">The password.</param>
/// <returns>True if the user has authenticated successfully, false otherwise</returns>
public virtual bool Authenticate(string user, string pass word)
{
	
	bool isValidLogin = authenticationService.IsValidLogin(user, password);
	if (isValidLogin)
	{
		Usage.SuccessfulLogin(user);
		string returnUrl = Scope.Input[Constants.ReturnUrl];
		if (!string.IsNullOrEmpty(returnUrl))
			Context.AuthenticateAndRedirect(returnUrl, user);
		else
			Context.AuthenticateAndRedirect(Settings.Default.HomePageUrl, user);
		return true;
	}
	Usage.FailedLogin(user);
	Context.SignOut();
	Scope.ErrorMessage = Resources.BadUserOrPassword;
	return false;
}

I think that I have done a moderately good job in making my recent projects maintainable without me, and I am trying to make sure that there won't be many cases of "This is Oren's Code^TM, I can't touch that". We aren't there yet, but we are getting there. Another developer is going to take over a project that I have led, and I have confidence that after the initial panic, things would settle down.

My criteria for maintainability if that if you know X, Y and Z (usually technologies that I use in the project, mainly NHibernate), you should be able to get everything from the code.

Then again, my current project's Guide to the New Developer does have two pages dedicated to dependencies and links to the documentation...