And then there’s the other type of developer. We’ll call him Einstein. Einstein is super smart. He thinks on a whole ‘nother level. In fact, he’s so smart that when he writes software, he writes it on a whole ‘nother level. On the UI level, the program runs and performs well. It does everything that it’s supposed to do. It might even do it REALLY well. Einstein has certainly outdone himself. He finished the project a few days early and the client is happy with the product.

Fast forward 6 months when the client needs to add a feature. Einstein is tied up with another project. The client has to hire another developer to modify the code base. We’ll call him Innocent Bystander. The client says to Innocent Bystander, “We’re really happy with Einstein’s work. You should have no trouble at all modifying this program.” So, Innocent Bystander cracks open the code and starts reading.

What he finds is a code base that only an author could love. It’s a tangled mess of spaghetti code and obscurely reused code blocks. Variables are named with acronyms that have long since been forgotten. There are no tests to show how code is expected to behave. Classes and methods cover pages and pages of scrolling. Nothing makes sense. It’s like trying to listen in on an encrypted conversation. The code base, for all intents and purposes, is encrypted.

So, Einstein was so “smart” that he wrote a code base that no one but he could understand. Innocent Bystander has accepted the task of adding a feature to that code base. Innocent Bystander has a couple choices… 1) Spend hours of the client’s time decrypting, modifying, and handling regression, or 2) Spend hours of the client’s time re-writing a section of the code, re-factoring the code that uses it, and handle regression. Either way, the client pays more than he should. Either way, there is regression. At least with the second option, the code base is left a little better than how Innocent Bystander found it.

Friends, countrymen, fellow developers. PLEASE please pLeAsE hear me out. If you are an Einstein and you’re still reading this… welcome to your first step to recovery. Admit you have a problem and start thinking about others while you code. Think about your client. Think about the next guy who has to come behind you. You don’t want either to hate you, right? Learn how to code in maintainable ways.

If you want to make sure your code is removed or re-written, just make it complicated and convoluted. No one will be able to follow your code and, boom… mission accomplished. You’ve effectively wasted the money of your client. The world would have been better off if you had applied your vast, immeasurable intelligence to something that lends itself to tangled webs of scattered thought process.. not software development.

If you want your code to stick around and make a difference, write it so that the next developer can read and understand it. Name your variables and methods to express their intent. Adhere to engineering principles like Single Responsibility, Open-Closed, and Dependency Inversion. Code in standard ways. Don’t try to be clever by stuffing loads of functionality into one reusable function. Spend time learning new ways to make your code expressive and readable.

No one cares how smart you are. It matters not that you’re on a whole ‘nother level. People only really care about your contribution over the long-haul. Clients may love you when you deliver the product early like a rock star, but the will cease to love you later when they have to pay again for the same code. No one will write blog articles about your awesome “swiss-army-knife-function-that-does-everything”. No, sir… in fact, they’ll write blog articles like this one.

When do you throw an exception? I never asked myself that question until a few weeks ago when some guys on my team started wondering aloud. I suppose I never asked because I just threw exceptions whenever I felt like it. But the question on the minds of my collegues has got me thinking too. When should I throw exceptions?

One team member says that exceptions should only be thrown when there is exceptional behavior. That sounds reasonable, right? But now, we have to define exceptional behavior. Google says that an exception is, “A person or thing that is excluded from a general statement or does not follow a rule.” So exceptional behavior is conduct that breaks rules, simply put.

Take the following code for example:

public Monkey GetMonkeyById(int id)
{
    var monkey = _monkeyRepository.Get(id);
    return monkey;
}

The purpose of the function is expressed in the function’s name: “Get a monkey by its ID.” So, what if there is no monkey found by the given ID? Is that exceptional behavior? If you were inclined to say, “no,” you could do a few things in response to your lack of monkey. You could return null, but that’s a cheap shortcut that will cause problematic code down the line. You could possibly change the method to return an object that contains a monkey, a success flag, and a message (for when there is no monkey found), like so:

public class MonkeyResponse
{
    public bool Success { get; set; }
    public string Message { get; set; }
    public Monkey Monkey { get; set; }
}

So, then, your function can go something like this:

public MonkeyResponse GetMonkeyById(int id)
{
    var monkey = _monkeyRepository.Get(id);
    return new MonkeyResponse
        {
            Monkey = monkey,
            Success = true,
        };
}

There is something wrong with that function that I REALLY don’t like. The MonkeyResponse class will ALWAYS return a null or some empty value. If there is a monkey found, it will return a null/empty message. If there is no monkey found, the monkey property will be null. Neither of those options are satisfactory.

The fact of the matter is, there is a rule being broken in this function when an invalid ID is passed in. The function’s purpose is to retrieve a monkey. If that is not possible, then the code’s course has to change drastically from it’s intended purpose. We need to call a spade a spade, address the broken rule appropriately, and throw an exception.

Here’s my refactored function including an exception:

public Monkey GetMonkeyById(int id)
{
    var monkey = _monkeyRepository.Get(id);
    if(monkey==null) throw new Exception("Monkey not found by that ID.");
    return monkey;
}

I got rid of the MonkeyResponse object because I don’t need it anymore. Now, my function returns a Monkey if one is found, and throws an exception when someone passes in an invalid ID. This feels much better. I know that the repo is returning a null when no monkey can be found, but that’s a refactor for another day. I would probably move the exception from this function into the repo function and let the exception bubble up.

This really isn’t rocket science, but I think it’s important to question your methods from time to time. I’ve been throwing exceptions (on purpose) without justification for years. Now, I have at least gone through the thought process of justifying my methods. In a nutshell, here’s what I’ve come up with:

Throw an exception when a function’s behavior breaks the rules and causes the code to change course as a result.

One reason a lot of Webforms developers might be hesitant to move to MVC is because the apparent lack of web controls. Web controls save time and make development of ASP.NET applications a breeze (sometimes). So, if developers want to branch out and get into MVC, they need to know that THERE ARE wonderful control-like things they can use with ease. Here are some examples to get you rolling:

Data Sources:

In WebForms, it’s typical to drag a data source like ObjectDataSource, XmlDataSource, or SqlDataSource onto your page in order to provide data to a control like a GridView or Repeater. We have no such construct in MVC. The closest equivalent can be found in the concept of a “view model”. A view model is an object that has been passed to the view in order to populate the it with data from the controller. With WebForms, you usually think of the page going out to get it’s data. In MVC, the view is given the data. It’s a subtle difference, but an important one. So, when you find yourself in MVC and you need to have dynamic data on your view, think “view model”.

GridViews:

The GridView is possibly one of the most important controls for a line-of-business application developer. It’s also one of the more involved controls to mimic since there’s so much going on (paging, sorting, grouping, searching, etc). However, there’s a company called Trirand who has put together an open source library that does what the GridView does plus a LOT more. The library is called JQuery Grid and is written completely in JavaScript using JQuery (of course). Check out a ton of demos and example code here. You can download JQuery Grid (jqGrid for short) from their team blog. Also, here’s an article by Phil Haack that explains one way of using jqGrid with MVC. Even though I mentioned view models above as the preferred way to get data to a view, you should also look into using a JsonResult (from the controller) to populate a JQuery Grid.

Labels:

I know this one might seem like a no brainer, but I remember using the Label control a lot when I was developing Webforms apps. When the Label renders down to HTML, you get a <span> tag surrounding your text. Also, you would set the value of the Label from code-behind (though, with a bunch of ViewState mess). Instead of a Label control adding tags for you, if you’re so inclined, you can easily add your own <span> tags. Otherwise, let your model do it’s thing. If the “Name” property on my view model has been set to “Byron”,  then <%=Model.Name%> will render down to “Byron” (without the quotes). Sorry if that’s too simplistic, but I promised some web control replacements, and I aim to please.

TextBoxes:

The TextBox is an incredibly important UI control. In Webforms, you just drag a TextBox control onto your design surface and change its ID to something reachable from code-behind. With MVC, its almost the same, minus the clicking and dragging. Just enter <%=Html.TextBoxFor(x=>x.Name)%> into your view. This will render down to something like <input id=’Name’ name=’Name’ value=’Byron’ />. Pretty clean. Pretty easy.

Calendars:

I have to admit, the first time I used the old ASP.NET Calendar control was also the last. That thing was hard to use and it looked like death warmed over. Eventually, the AJAX Toolkit came out with a much better rendition, but I had already fallen in love with another open source calendar control. Nevertheless, those aren’t available to me in MVC. So, I just use a textbox and apply JQuery UI’s Datepicker plugin. Here’s the documentation page for the Datepicker plugin. You can download JQuery UI from the same site. If my model has a property on is like “Birthdate”, I could just enter <%=Html.TextBoxFor(x=>x.Birthdate, new { @class=”datepicker” })%> into my view. This would eventually get rendered down to something like <input type=’text’ id=’Birthdate’ name=’Birthdate’ value=’11/12/1978 17:35:00′ class=’datepicker’ />. Now, assuming you have a reference to JQuery UI in your view (or master) somewhere, you can equip your new textbox with a JQuery calendar by adding $(‘.datepicker’).datepicker(); somewhere in your JavaScript section.

Lists and Repeaters:

When a GridView won’t cut it, many WebForms developers turn to ListViews or Repeaters. ListViews were my particular favorite once I got the hang of them. If you’re familiar with these great controls, you will be right at home with MVC. As mentioned above, when you want to get data to a view, you pass it an object called a view model. The view model might contain a list of books or people along with other data that the view can use. If you have such a list, just code the iteration in HTML using a bit of c# to help it along (gasp! mixing c# with HTML?? — yes, get over it). You could do something like this:

<ul>
<%foreach(var book in Model.Books) {%>
    <li><%=book.Name%></li>
<%}%>
</ul>

I think you get the point.

Try it out! Between JQuery, MVC’s HTML Helpers, and your own noggin’, you should be getting the web control warm fuzzies in no time. After the initial learning curve, you’ll be cranking out apps left and right.

I credit my enlightenment to three things: my newfound co-workers, my own desire to constantly improve, and ASP.NET MVC. The first two are self-explanatory. The last might seem suspect. How can a framework change the way a person thinks about programming web apps?

I started using ASP.NET (from here, known as “Webforms”) a few years ago and really dug in. Because I like to at least feel like I know what I’m doing, I got to know the framework top to bottom. I loved how creating a web app was almost as easy as creating a windows app. I didn’t love how far I was removed from the underlying HTML, CSS and Javascript. Oh, well… Just drag a control on the design surface and shut-up!

Enter the new hotness. MVC zooms me in a few levels of abstraction and reminds me of what is really going on behind the scenes of a web application. If http is the metal, MVC is closer to it. Instead of clicky-draggy controls, I have to use the keyboard A LOT more. As a result, I actually know what’s going on. On top of all that, IT’S EASIER!!

After using MVC for some time, developing apps via BDD, I now feel like I know MVC top to bottom. After getting to know MVC so well and some residual (albeit waining) knowledge of Webforms, I wanted to provide my developer friends entrenched in Webforms-land a way to make the big switch, if they so choose.

Some Reusable Concepts in Webforms and MVC:

Page to view

In Webforms, you have the concept of a “page”. The page contains the big three (HTML, CSS, and JavaScript) and some place holders for data. Very close to the same thing with MVC. In MVC, I have the concept of a “view”. A view contains the big three, and some place holders for data.

Controls to Helpers and JQuery

In Webforms, you have the concept of “controls” that you can drag onto your design surface. The controls will eventually get rendered down to the big three. In MVC, I have the concept of “Html Helpers”. No dragging. Instead, you type the name of the helper into your view. Same as a control, an HTML helper gets rendered down to the big three when the view is loaded. Also, to make your UI elements look and feel snazzy, you’ve got JQuery. Actually we all do. JQuery is just a Javascript framework/library, so it doesn’t care whether you’re using PHP, Rails, or ASP.NET (or even ASP Classic for that matter). Code your own HTML or use a Helper, then apply JQuery to it… Victory.

Code behind to controller

In Webforms, when you want to add logic or data to a page, you drill into its “code-behind” file and add code to the Page_Load method. In MVC, I have the concept of a “controller” that has “actions”, each responsible for combining my data with my views.

Events to routes and methods

In Webforms, when you want a button to do something, you attach an event to it which appears in the page’s code-behind. Any actual logic that happens, does so during the post-back (after the post, before the back) and the page is (typically) redisplayed after the event takes its course. In MVC, I have links that describe the controller and action I want to kick off. If my action needs to receive some data (as is typical in a post-back), then my form action should describe the correct controller and action, and my action needs to know what to receive.

User controls to partial views

In my last year using Webforms, I had gotten into user controls big time. They are a great way to re-use code, which is my favorite pass-time. In Webforms, much like a typical control, a user control is a markup/code-behind combo that encapsulates some reusable, displayable functionality. However, unlike typical controls, user controls are custom and don’t come in a DLL. In MVC, I have something similar in the concept of a “partial view”. A partial view is simply a section of an HTML page with place holders for data. Like views, partial views can be rendered by controller actions. They can also be referenced in views themselves with a single line of code.

Master Pages

Where would we be without master pages, right? Imagine templating an ASP.NET website without a master page! As it turns out, Webforms master pages are so great, that they’re exactly the same in MVC. How’s that for reusable knowledge?

Things you’ll have to change:

Page lifecycle:

In Webforms, you typically think of an aspx page loading and then its code-behind Page_Load method being called. That’s not really what’s going on, but from 30,000 feet, everything looks simpler than it really is. Who knows? Maybe you have memorized the Webforms page lifecycle like I did. Well, throw away your complicated charts and graphs. It all gets a LOT simpler. In MVC, I have a route, a controller, a method, a model, and a view. The user enters or clicks a URL. The URL gets parsed into a route. The route specifies the controller and the method. The method scrapes up a model and returns a view.

Postbacks:

The concept of an http post is intact in MVC. As expected, right? MVC is “closer to the metal” as they say, so your typical http protocol methods are large and in charge. But, in Webforms, you have the concept of a “post-back”. A post back is nothing more than a page posting back into itself. In MVC, you have to put in some extra effort to achieve a real post-back. Instead, you post into actions that may or may not return the same posting view.

Models for Views:

In Webforms, the way to put data on a page is to call into the control on the page and give it the desired data. In MVC, I have to think about things a little differently. You know what a model is. Now imagine a view that expects a model with certain properties that the view may or may not decide to use. In MVC, when a view is rendered, it is often combined with something called a “view model”. At that point, any place holders are replaced with model data and the view is delivered to the browser. The difference is subtle, but it’s important. Instead of telling controls what to do, you provide them with what they need and let them do it on their own.

Viewstate:

In Webforms, state (anything kept in memory) is simulated by flooding the user’s browser with seemingly endless strings of encoded data called “Viewstate”. Every time the form is posted, all that “state” is transmitted and re-populated when the page is rendered again. In MVC, there is no state, just like any other web technology. The only thing that is transmitted is what you specify. This is dramatically cleaner and more efficient. Instead of depending on Viewstate to hang on to label and text box values, you are responsible for populating and repopulating. It turns out it’s not that big of a deal with help from the model binder and view models.

Give it a try!

If you’re an serious Webforms developer, you’ll probably end up loving MVC after you get comfortable with the framework. I hope some of this information is helpful as you take back control and move to ASP.NET MVC.

“As a user, I want to add numbers together so that I can know the sum.”

WHEN provided an empty string,
THEN it should return 0

WHEN provided one number,
THEN it should return the same number

WHEN provided two numbers separated by a comma,
THEN it should return the sum of those two numbers

WHEN provided an unknown amount of numbers separated by commas,
THEN it should return the sum of all numbers provided

WHEN provided numbers with a new line character,
THEN it should return the sum of all numbers provided

WHEN provided numbers separated by a specified delimiter,
THEN it should return the sum of all numbers provided

WHEN provided one negative number,
THEN it should throw an exception (“Negative numbers are not allowed – [Display the negative number.”)

WHEN provided more than one negative number,
THEN it should throw an exception (“Negative numbers are not allowed – [Display the negative numbers.”)

So, let's dive in and see where the story leads us! My job from here on out is to create a spec based on a single acceptance criterion, run the spec so that it fails, write JUST ENOUGH code in my new string calculator class to make the spec pass, and then move on to the next acceptance criterion.

Acceptance Criterion:

WHEN provided an empty string,
THEN it should return 0

Specification with mspec:

public class when_provided_an_empty_string {

	Establish a_string_calculator_context = () =>
		_stringCalculator = new StringCalculator();

	Because of = () =>
		_result = _stringCalculator.Add(string.Empty);

	It should_return_zero = () =>
		_result.ShouldEqual(0);

	static StringCalculator _stringCalculator;
	static int _result;
}

Resulting code:

public class StringCalculator {

	public int Add(string stringToCalculate) {

		return 0; //simplest thing to make it pass, right?

	}
}

Acceptance Criterion:

WHEN provided one number,
THEN it should return the same number

Specification with mspec:

public class when_provided_one_number {

	Establish a_string_calculator_context = () =>
		_stringCalculator = new StringCalculator();

	Because of = () =>
		_result = _stringCalculator.Add("5");

	It should_return_the_same_number = () =>
		_result.ShouldEqual(5);

	static StringCalculator _stringCalculator;
	static int _result;
}

Now, I'm starting to see some repetition in my context. Before moving forward, I'm going to refactor my specs a bit to use a common context. For this, I will use an abstract class that starts with the word "given".

public abstract class given_a_string_calculator {

	Establish a_string_calculator_context = () =>
		_stringCalculator = new StringCalculator();

	protected static StringCalculator _stringCalculator;
}

So, first spec looks like this:

public class when_provided_an_empty_string :
	given_a_string_calculator {

	Because of = () =>
		_result = _stringCalculator.Add(string.Empty);

	It should_return_zero = () =>
		_result.ShouldEqual(0);

	static int _result;
}

...and my second spec looks like this:

public class when_provided_one_number :
	given_a_string_calculator {

	Because of = () =>
		_result = _stringCalculator.Add("5");

	It should_return_the_same_number = () =>
		_result.ShouldEqual(5);

	static int _result;
}

Resulting code:

public class StringCalculator {

	public int Add(string stringToCalculate) {

		return string.IsNullOrWhiteSpace(stringToCalculate)
			? 0
			: int.Parse(stringToCalculate);
	}
}

Acceptance Criterion:

WHEN provided two numbers separated by a comma,
THEN it should return the sum of those two numbers

Specification with mspec:

public class when_provided_two_number_separated_by_a_comma :
	given_a_string_calculator {

	Because of = () =>
		_result = _stringCalculator.Add("2,5");

	It should_return_the_sum_of_those_two_numbers = () =>
		_result.ShouldEqual(7);

	static int _result;
}

Resulting code:

public class StringCalculator {

	public int Add(string stringToCalculate) {

		return string.IsNullOrWhiteSpace(stringToCalculate)
			? 0
			: stringToCalculate.Split(new char[] { ‘,’ })
				.Sum(x=> int.Parse(x));
	}
}

Acceptance Criterion:

WHEN provided an unknown amount of numbers separated by commas,
THEN it should return the sum of all numbers provided

Specification with mspec:

public class when_provided_multiple_numbers_separated_by_commas :
given_a_string_calculator {

	Because of = () =>
		_result = _stringCalculator.Add("3,4,5");

	It should_return_the_sum_of_all_numbers_provided = () =>
		_result.ShouldEqual(12);

	static int _result;
}

UH OH! This spec passed without any modification to the calculator. I don't like when this happens, but I don't think I could have made the Add method much simpler when adding two numbers separated by a comma. Now, because of my use of Linq's Sum extension method, it passes with any amount of numbers. Moving on...

Acceptance Criterion:

WHEN provided numbers with a new line character,
THEN it should return the sum of all numbers provided

Specification with mspec:

public class when_provided_numbers_with_a_new_line_character :
	given_a_string_calculator {

	Because of = () =>
		_result = _stringCalculator.Add("3,4\n6");

	It should_return_the_sum_of_all_numbers_provided = () =>
		_result.ShouldEqual(13);

	static int _result;
}

Resulting code:

public class StringCalculator {

	public int Add(string stringToCalculate) {

		return string.IsNullOrWhiteSpace(stringToCalculate)
			? 0
			: stringToCalculate.Split(new char[] { ',', '\n' })
				.Sum(x=> int.Parse(x));
	}
}

Acceptance Criterion:

WHEN provided numbers separated by a specified delimiter,
THEN it should return the sum of all numbers provided

Specification with mspec:

public class when_provided_numbers_separated_by_a_specified_delimeter :
	given_a_string_calculator {

	Because of = () =>
		_result = _stringCalculator.Add("//;\n3;4;7");

	It should_return_the_sum_of_all_numbers_provided = () =>
		_result.ShouldEqual(14);

	static int _result;
}

Resulting code:

public class StringCalculator {

	public int Add(string stringToCalculate) {

		var delimiters = ",\n";

		if (stringToCalculate.StartsWith("//")) {
			delimiters += stringToCalculate[2];
			stringToCalculate = stringToCalculate
				.Substring(4, stringToCalculate.Length - 4);
		}

		return string.IsNullOrWhiteSpace(stringToCalculate)
			? 0
			: stringToCalculate
				.Split(delimiters.ToCharArray())
				.Sum(x=> int.Parse(x));
	}
}

Acceptance Criterion:

WHEN provided one negative number,
THEN it should throw an exception (“Negative numbers are not allowed – [Display the negative number.”)

Specification with mspec:

public class when_provided_one_negative_number :
        given_a_string_calculator {

	Because of = () =>
		_exception = Catch.Exception(()=>
			_stringCalculator.Add("-1,2"));

	It should_throw_an_exception = () =>
		_exception.Message
			.ShouldEqual("Negative numbers are not allowed: -1");

	static Exception _exception;
}

Resulting code:

public class StringCalculator {

	public int Add(string stringToCalculate) {

		var delimiters = ",\n";

		if (stringToCalculate.StartsWith("//")) {
			delimiters += stringToCalculate[2];
			stringToCalculate = stringToCalculate
			.Substring(4, stringToCalculate.Length - 4);
		}

		if(stringToCalculate.Contains("-")) {
			throw new Exception("Negative numbers are not allowed: -1");
		}

		return string.IsNullOrWhiteSpace(stringToCalculate)
			? 0
			: stringToCalculate
				.Split(delimiters.ToCharArray())
				.Sum(x=> int.Parse(x));
	}
}

Acceptance Criterion:

WHEN provided more than one negative number,
THEN it should throw an exception (“Negative numbers are not allowed – [Display the negative numbers.”)

Specification with mspec:

public class when_provided_more_than_one_negative_number :
	given_a_string_calculator {

	Because of = () =>
		_exception = Catch.Exception(() =>
			_stringCalculator.Add("-1,-2"));

	It should_throw_an_exception = () =>
		_exception.Message.ShouldEqual(
			"Negative numbers are not allowed: -1,-2");

	static Exception _exception;
}

Resulting code:

public class StringCalculator {

	public int Add(string stringToCalculate) {

		var delimiters = ",\n";

		if (stringToCalculate.StartsWith("//")) {
			delimiters += stringToCalculate[2];
			stringToCalculate = stringToCalculate
				.Substring(4, stringToCalculate.Length - 4);
		}

		if(stringToCalculate.Contains("-")) {
			throw new Exception(
				string.Format("Negative numbers are not allowed: {0}",
					string.Join(",", stringToCalculate.Split(
						delimiters.ToCharArray()).Where(x=>
							int.Parse(x) < 1 ))));
		}

		return string.IsNullOrWhiteSpace(stringToCalculate)
			? 0
			: stringToCalculate
				.Split(delimiters.ToCharArray())
				.Sum(x=> int.Parse(x));
	}
}

Here are the results from all eight specs:

when provided more than one negative number
» should throw an exception
when provided one negative number
» should throw an exception
when provided numbers separated by a specified delimiter
» should return the sum of all numbers provided
when provided numbers with a new line character
» should return the sum of all numbers provided
when provided multiple numbers separated by commas
» should return the sum of all numbers provided
when provided two number separated by a comma
» should return the sum of those two numbers
when provided one number
» should return the same number
when provided an empty string
» should return zero

8 passed, 0 failed, 0 skipped, took 1.05 seconds (Machine.Specifications 0.3.0).

In a simple kata like this, the end-result is pretty similar to what might come out of a traditional TDD process. Imagine doing a much more complicated code project, and you'll probably begin to see how powerful and valuable Behavior-Driven Development can be.

Download Source Code

Forget lofty terms like coupling and inversion for a few minutes.

Let’s say you a have a computer program that checks movies in and out of a movie store. Employees can log in and help customers at the counter. Customers can pick movies off the shelf and bring them to the counter to rent or check out. This program stores customer and movie information so that it can be retrieved later. It is also able to fetch extra movie information from the internet. When movies are returned, employees can check them back in to the program and put them back on the shelf for others to rent.

If you were to make a list of all the things the program needed to be able to do, you could pretty easily mark all the items that depend on some external system. For the sake of a simple discussion, an external system is something outside of your program that you have limited or no control over. Just from my description of the program above, you could extract a few possible dependencies:

1. Log in/authentication system
2. Database for storing inventory
3. Web service for getting extra movie information

Now, the majority of programmers handle such dependencies by embedding them inside the program. But, what happens when something needs to change in one of the dependencies? The database gets too big and you have to upgrade to another type of database. The web service you were using closes shop and you have to add another one. Since these dependencies are embedded, the programmer has to change the core inner workings of the program. You already spent months fixing bugs after the first release. Well, get ready for another round of bug fixes and broken code.

A better way is to separate any external dependencies from your core code and refer to them very loosely. Everything still works like it did before, but, now, your dependencies are modular and interchangeable. Swapping database vendors? No problem… You don’t even have to touch your core program. Want to write tests? No problem… Just swap out your external dependencies for fake ones and test away!

So, instead of your movie store app “having” a greenMovieStoreDatabase (just a name I came up with), it “uses” a genericMovieStoreDatabase and is told, “today, your genericMovieStoreDatabase will be a greenMovieStoreDatabase.” In this example, there’s a massive difference between “having” and “using”. If your program “has” a database, then it clings to it with iron claws daring you to mess with it… It’s embedded. If your program “uses” a generic database, it doesn’t necessarily care what color the database is as long as it acts like a database.

I would include some code samples, but my mom probably wouldn’t care about interfaces and implementations, IOC containers and bootstrappers. Who am I kidding? She probably didn’t care about dependency inversion either!

She’s a good lady for listening.

I was consulting on a large project one day and discovered that it had a big problem. The company had been dealing with this problem year after year, having the same discussions, and coming up with the same broken solutions. One poor fellow even tried to help them escape the cycle, but got bogged down by the complexity. All this trouble over something I had never considered to be that big of a deal until then. So, it got me thinking…

System time is an external dependency! Maybe you’ve always known this, but the thought had JUST occurred to me. It seems harmless, right? Every language has some form of system time and the API for it probably hasn’t changed since the language’s first release. It sings a sweet lullaby and soothes into a false sense of security, but beware! System time is a wolf in sheep’s clothing… an evil tyrant. You see, once you begin to write time-based logic into your code, you have upgraded system time to a full-blown dependency. If you’re familiar with the concepts of “coupling” and the “dependency inversion principle“, then a siren should be going off in your head right about now. Any external system that your code depends on to function should be injected into your class in some way, shape, or form. System time should be NO exception.

Back to the company I was working with. They had more than five independent systems that depend on system time in one way or another. Logging, validation rules, emails, you name it. For the most part, system were designed and written fairly well. The company was trying to follow Uncle Bob’s SOLID principles as best they could, though with little focus on automated testing. After all the systems were built, someone said, “Well, how can QA test the system for different days? On October 1st, the home page is supposed to turn blue. We need to be able to see that happen.” Even after creating such a loosely-coupled masterpiece, they didn’t think to consider system time to be the external dependency that it truly was. The entire code base, every tier and independent system, was SO tightly-coupled to system time (on multiple servers) that the final solution ended up being to set up a separate server cluster (including a domain controller) and change each server’s time manually. WOW.

Retrospect is a wonderful teacher. If each system had been built with automated testing as a priority, then we wouldn’t have ended up calling up the infrastructure team to set up a temporary network with which to do manual testing.

I’m sold. From here on out, I’m considering system time an external dependency. With that in mind, here’s a solution that I would propose to any team who is about to use system time in one of their projects.

First, a way to get a configured time out of some data source. I will use the section of an app.config or web.config for this demo. You can write the implementation of ITimeConfiguration to pull from any data source (database, text file, registry, or nowhere at all).

public interface ITimeConfiguration
{
    DateTime GetConfiguredTime();
}

public class TimeConfiguration : ITimeConfiguration
{
    public DateTime GetConfiguredTime()
    {
        var configuredTime = ConfigurationManager.AppSettings["ConfiguredTime"];
    var outputDateTime = new DateTime();
    if( !string.IsNullOrWhiteSpace( configuredTime ) )
    {
        DateTime.TryParse(configuredTime, out outputDateTime);
    }
    return outputDateTime;
    }
}

Next, we need a time provider to consume our ITimeConfiguration:

public interface ITimeProvider
{
    DateTime Now();
}

public class TimeProvider : ITimeProvider
{
    readonly ITimeConfiguration _timeConfiguration;

    public TimeProvider(ITimeConfiguration timeConfiguration)
    {
        _timeConfiguration = timeConfiguration;
    }

    public DateTime Now()
    {
        var configuredTime = _timeConfiguration.GetConfiguredTime();
        return configuredTime == DateTime.MinValue
            ? DateTime.Now
            : configuredTime;
    }
}

Now, when we need to access the current (or configured) time, we can just pass ITimeProvider in to the class as a dependency. It’s mockable, testable, extensible, flexible, and it does laundry.

Well, maybe the laundry part is going too far. But I really do think this is better than consuming system time directly. I just implemented this scheme in a project and it’s working great. And I feel like a huge weight has been lifted off my shoulders. The tyranny of system time is finally over!

I started to learn computer programming around 1986 with my good friend, Garret Hamann. We didn’t know it at the time, but we were practicing a technique that would soon be known as “Pair Programming”. Garret learned from his dad who was an engineering student at Vanderbilt (probably via pairing). Garret transferred what he knew to me when we would pair for hours on the weekends. We would write RPG’s on my Commodore 64, taking turns on the keyboard, talking, arguing, learning. Then we would re-write those games on Garret’s Apple II. What a great way to learn to code!

“Pair Programming” is kind of a big deal these days. Adoption is widespread, especially amongst those who run in Agile circles (ever increasing, thankfully)… and with good reason. The benefits are huge. Here are just a few:

• TRIBAL KNOWLEDGE: Even if you never switch pairing partners, your team feels the benefits or pairing simply because you’re not the only person on the team that knows how a section of code works. If you get hit by a bus or win the lottery, your team has another way to access your knowledge through your partner.
• NO NEED FOR CODE REVIEWS: Code is reviewed as it’s written. This provides a much more thorough and meaningful code review process and saves time.
• BETTER DESIGN MEANS LESS REFACTORING: Two heads are better than one, no matter how smart you think you are. When done right, pairing partners can help each other make better design decisions as the code unfolds. Because the code is designed better, you will naturally have fewer needs to go back and refactor code.
• CONSISTENT FOCUS: Ever feel like your focus is waning? It happens to everyone, but it doesn’t always happen at the same time for everyone. When pairing, when one partner’s focus begins to suffer, the other partner can help keep the ball rolling with a word or two. Better focus means more forward progress.

Without realizing some of the benefits, it might be easy to look at “Pair Programming” as a waste of time or a productivity reducer. But, in fact, coding in pairs make the overall software development process much more efficient and enjoyable.

In my earlier article about “Pair Programming,” I proposed some ways to kill it off. Today, I’d like to suggest a few ways to help your team thrive in pairs.

1. BE WILLING TO LOSE: When you have an opinion and your pairing partner has an opposing opinion, you should talk it out. Maybe draw some circles and lines on the whiteboard. The goal is to arrive at the best decision, not for your opinion to be the winner. Sometimes, the best decision might be to stop discussing it and pick one. After all, you can always refactor later if it turns out you went the wrong direction. Being willing to lose is an essential part of working as member of a team and is even more essential for pairing.
2. BE AN ENCOURAGER: You like to be praised for a job well done. Give the same consideration to your pairing partner. Take opportunities to build him/her up in front of the team and make it genuine. Talk about your partner more than yourself. Call attention to his/her best contributions.
3. VOCALIZE CODE: Code certainly isn’t English, but we all have the ability to speak an English version when we’re explaining code to someone. Instead of coding silently, vocalize as you code. Keep a constant conversation going. If the only sound in the room is fingers on keys, you’re doing it wrong.
4. EXPECT AND ACCEPT CORRECTION: Part of the huge benefit to pairing is the combining of two sets of experience. The only way to truly tap into that combined experience is to correct and discuss. Expect your pairing partner to question your decisions. When they do, put your pride in the trash can and discuss it like you care about the project more than your own opinion. If your partner isn’t starting discussions, start them yourself and invite him/her to interrupt at any moment.
5. LEAVE SOME SPACE: Even though it’s a good practice to correct and discuss while pairing, it’s not so good if you go crazy with it. If your partner misses a semicolon or enters a typo, give them more than a half second before chiming in.
6. ALLOW SPEED DIFFERENCES: Some programmers like to zip through code like it’s a race. Other programmers take their time and move at a much slower pace. Decide as a pair how you will handle the differences in speed and stick to it for an entire iteration. If you’re vocalizing your code, you will naturally slow down at some points and speed up at others. The main thing is to respect your partner’s pace.
7. SWAP DRIVERS OFTEN: Being in the driver’s seat is admittedly more fun. With that in mind, swap seats every so often. If your partner doesn’t request it, you should offer it.

For more information on “Pair Programming” and how to make it work for you or your team, check out these great articles:

• Pair Programming in Extreme Programming (XP) Rules – http://www.extremeprogramming.org/rules/pair.html
• Wikipedia’s Take – http://en.wikipedia.org/wiki/Pair_programming
• Jeff Atwood’s comparison of Pair Programming and Code Reviews – http://www.codinghorror.com/blog/2007/11/pair-programming-vs-code-reviews.html
• Alan Shorkin’s views on effective and ineffective pair programming – http://www.skorks.com/2009/07/effective-vs-ineffective-pair-programming/
• Rod Hilton expresses his undying love for Pair Programming – http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/

Wikipedia.com describes “Pair Programming” this way:

Pair programming is an agile software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator[1]). The two programmers switch roles frequently.

Sounds nice, right? Well, if I described you correctly in the paragraph above, then the answer is, “wrong!” Working so closely with another programmer is likely to end badly for you. However, “Pair Programming” has been building momentum over the last few years, especially since there has been an increased focus in software engineering practices, code quality, and ethical programming. But who needs any of those things? You make great software and you don’t feel like you should have to change the way you work… ever.

It is for those reasons and more that I decided to release this list of useful weapons in the fight against progress.

1. EXPRESS YOUR SUPERIORITY: You’re a better coder and you know it. Be sure your pairing partner knows it as well. Take every opportunity to hold your knowledge over your partner’s head. The best way to elevate yourself is to make your partner a little lower, even if only in your own mind.
2. NEVER BACK DOWN: Your opinion is correct, or else it wouldn’t be yours. A correct opinion is worth fighting for to the bitter end. When one argument tactic begins to fail, switch to another, thereby flanking your opponent. Eventually, they will give up.
3. GLOAT: Remember that discussion from 15 minutes ago where your opinion gained the victory? Of course you do. Well, in case your partner has already blocked it out of his/her mind, bring it back up when you see a place where it applies. Say things like, “See how much better it is since we did this my way?”
4. WATCH SILENTLY: Nothing is more boring than watching someone code, right? Well, why make it better by communicating? Instead, sit silently and watch the code go across the screen. After a few minutes, take our your phone and update your status on Twitter or check your email. You may miss opportunities to discuss coding decisions, but you’ll likely be able to gloat about them later when refactoring becomes necessary (which is inevitable since you’re not in the driver’s seat).
5. CODE SILENTLY: Why should you have to explain what you’re doing in your code. Your pairing partner can see it on the screen! Besides, they probably wouldn’t understand anyhow. Better to just code the way you always have because that’s when you’re at your best. Don’t talk through your code and certainly never explain any decisions you’re making.
6. BETRAY TRUST: When you’re shooting the breeze with your co-workers or chatting on IRC, be sure to bring up funny or embarrassing stories from your “Pair Programming” experience. Of course, avoid subjects that reveal your own deficiencies, but be sure to highlight your pairing partner’s lack or prowess. Doing this behind his/her back is encouraged, since you will likely feel more free to embellish.
7. DOMINATE THE KEYBOARD: Even though you are bent on killing “Pair Programming” in your team, you’re not a complete tool. As the better coder, you feel responsible for getting the project complete despite the handicap the “agile crazies” have placed on your team. To that end, and working within the confines or “Pair Programming”, you should make every effort to keep your position in the driver’s seat.
8. CODE ALONE: Even though your team has decided to adopt “Pair Programming”, it doesn’t mean you can’t sneak in some private coding time (for old time’s sake). Ideal times to code privately are during coffee, lunch or restroom breaks. Be sure to start one or two sections of code while your partner is away from your workstation. As a result, you’ll get more time in the driver’s seat because you’re the only one who knows your intent and direction.
9. WIN: Defeat is not an option for you. Stalemate is also not an option. It is imperative that you argue your point until your pairing partner sees your way of thinking or has laid down his guns and surrenders. One way to know you’ve won is when your partner ceases to express opinions and blindly accepts anything you say. One other benefit to this technique is that you will likely get to drive for the remainder of the project. Victory is sweet.
10. COMPLAIN: Chances are, your organization or team has one or two “agile crazies” that sold the higher-ups on the concept of “Pair Programming.” That means the higher-ups are probably eager to hear about how it’s going. If your other attempts at sabotage are effective, then you should have quite a bit to complain about. Go around your team mates and fire off some emails to your manager or his/her superiors. Be sure to explain the obvious reasons why two programmers on one keyboard simply cannot work. Explain that morale across the entire team is low and that productivity would be back to “normal” if they would just put you in a position of influence. Be sure to taint the reputation of the “agile crazies”, maybe even calling them names like “agile crazies”.

Above all, remember your greatness. You’re better looking, smarter, more experienced, faster, and certainly more humble than anyone else on your team. Let those truths guide you, and, even though you’ll be viewed by everyone around you as a jerk, you’ll have single-handedly defeated the “Pair Programming” dragon and that should be enough to keep you warm at night… alone… with your cats.

I’m tired of saying to my friends, “I want to see that movie,” and quickly forgetting. I might even say that I want to see it when it comes out on video, but I don’t make a habit of going to the video store so I miss it that way as well. Then, five months later I’m the only guy at a party who hasn’t seen it. So, my idea is to create an app that helps me remember movies I want to see and reminds me when they are available (and on what medium).

My plan today is to produce this app in stages. Here’s a break-down.

1. Create a web app.
2. Add a mobile-friendly implementation of the same web app.
3. Re-use code from web app’s domain for iPhone app.
4. Re-use code from web app’s domain for Android app.
5. See where that takes me.

I’m going to be developing this app using .NET 4.0 and C#. My reason for that, besides the fact that the .NET stack is my back-yard, is because I can create a great, well-designed, loosely-coupled, web app using ASP.NET MVC2 and then turn around and re-use my domain layer on nearly any other platform with Mono.

You are my customer. If you’re reading this, I’m talking to you. Let me know what you think. Shoot me an email, a DM @sommardahl, and a comment. Expect to see something on this soon!

For sneak peeks, check out http://flicktrap.com.

Source can be found on GitHub at http://github.com/bsommardahl/FlickTrap.