Agile patterns & practices and the developer divide

In what little free time I have, I've been slowly working my way through the book "Agile Principles, Patterns, and Practices in C#" by Robert C. Martin. This is a GREAT book, and a real eye opener.


This book has shaped some of the fundamental ways that I look at software. Whenever I look at a problem now, I think about how I'm going to create the building blocks to solve that problem. As an example, MSDN magazine just had a great article about the opened-closed principle which actually discusses this book.

Sure, I used to have excellent test coverage and modularity, but this book has given me insight to take it to the next level. For example, following the single responsibility pattern is a concrete way of making your code more adaptable to change, and makes your code easier to maintain and understand.

The book even offers information about studies that have shown a correlation between how often working software is delivered, and the quality of the final product. When points are made, evidence is often provided to back it up. It's difficult to argue with real numbers.

The book covers these areas:

  • Agile principles, and the fourteen practices of Extreme Programming
  • Spiking, splitting, velocity, and planning iterations and releases
  • Test-driven development, test-first design, and acceptance testing
  • Refactoring with unit testing
  • Pair programming
  • Agile design and design smells
  • The five types of UML diagrams and how to use them effectively
  • Object-oriented package design and design patterns
  • How to put all of it together for a real-world project

If you haven't read this book, I highly recommend it. I think just about everyone could get something out of it. Even if you're not practicing or learning agile, the techniques themselves are still valuable.

On a personal note, I feel like I'm entering a completely new level of software development. I don't know if I've just been unlucky, but I've never worked with a team that really understood and/or practiced these patterns and practices. They certainly didn't teach this stuff in school.

I became curious as to the adoption rates of agile, and the rate of success that people are seeing. There is plenty of information that shows that the agile process is being used, and has been working well for lots of teams.

Like this post? Please share it!

See a mistake? Edit this post!

An intro to Search Engine Optimization (SEO)

I'm going to assume that a fair number of my readers have a website, blog, or other web presence. Many of you have probably built a website or two. I'm going to give you some quick SEO tips that I have found to be most important.


Our resident SEO expert spends nearly every day researching the current trends in SEO. If you try to do the same, and you're the only one running your site, you won't have any time to improve your site and come up with new content. You need to determine the right balance of time to make your site a success.

  • Define your goals - The first thing you need to do is ask yourself what the purpose of your site is:
    *   Are you trying to sell something online?
    *   Are you trying to get leads?
    • Is your site simply a place you direct people to for more information?*
  • Focus on Google - Google is the by far, the most popular search engine. Most likely, you'll want to focus your attention on them.
  • Make life easy for Google - If you expect Google to make decisions, you might not like the results.
    • Avoid duplicate content - If you have the same content on more than one page, you may be penalized. At the very least, Google won't know which content to give you credit for.
    • Make your HTML as simple as possible. A well formed XHTML design will go a long way.
  • Optimize the way your pages look in the search listings - Google will only show the first 60 or so characters in your title, so keep that in mind. Make sure you DO use meta description tags in your pages, because Google WILL use those in it's listings. Remember, you're not just optimizing for the Google index, you also want your titles and descriptions to entice users to click on your result.
  • Write original content - Google is looking for original content, and it has often been said that content is king. Even if Google isn't giving you points for original content, Google is looking for information that is relative to the times. If you're consistently writing good, original, and up-to-date content, Google will eat it up.
  • Create a sitemap - Sitemaps allow you to give the search engines a "map" to all of your pages, which ensures that they'll be found as quickly as possible. It also gives you an opportunity to specify how often pages change. If you're using Wordpress, you can use an automated sitemap generator.
  • Get relevant links - Google is built on a reputation system. When reputable, related sites link to you, Google will realize the popularity of your pages. The best way to get good links is to write good content. Another way is to make friends in the community, that have similar interests. They might be willing to add your site to their blogroll, or mention you in their content.
  • Tell Google what to NOT index - You can create a "robots.txt" file that tells the search engines what they can, and cannot index. You want to filter out all of the pages that are not original content. For example, on this blog, I filter out everything except the front page, about page, and the posts themselves. You can see my robots file here. I have talked about using a robots.txt file to avoid duplicate content in the past.
  • Use the Google webmaster tools - If Google is having problems indexing your site, you'll certainly want to know why. I check the webmaster tools daily to make sure that there are not any problems.
  • Do what Google asks - Google publishes their recommended webmaster guidelines. You definitely don't want to do something that Google explicitly forbids. Your playing their game, you need to play by their rules.
  • Have simple URL's - Your URL's should be human readable, and more importantly, should be simple enough that search engines won't get confused. Avoid URL parameters, and instead opt for path or page based names. For example,

If you have the time to take your SEO skills to the next level, there are immense resources available. The best way to find them is to simply do a Google search. The sites that do the best job with SEO should appear at the top!

Like this post? Please share it!

See a mistake? Edit this post!

A Dependency Injection example with Spring.NET

As requested, here is a real world example of how I used dependency injection to simplify a project, increase modularity, and subsequently increase testability.

Here's the project. I have a successful website called which allows you to track packages using a simple, common user interface. It also allows you to track pages using RSS.

Here is a list of features:

  • Supports multiple shippers, including FedEx, DHL, and USPS. The tracking number is resolved to one of them, and if a tracking number could belong to more than one, they are called simultaneously, and the one that returns the results is used.
  • Results are cached to avoid overusing the shippers servers
  • Errors are handled appropriately

I boiled the design into a tree of classes:


To greatly simplify the design, I decided that each module would implement a common interface. After all, they all take in a tracking number, and return tracking data. Here is the ITracker interface:

public interface ITracker
    TrackingData GetTrackingData(string trackingNumber);

Simple enough? Every class in the diagram above implements the same interface. If I want to add additional functionality, such as logging for example, I can simply add a class to the chain, and implement the same interface.

Now I can wire it up with Spring.NET:

<object name="postUtility" type="YTech.ShipperInterface.Tracking.Http.PostUtility, YTech.ShipperInterface" />

<!-- The trackers that actually do the work -->
<object name="uspsTracker" type="YTech.ShipperInterface.Usps.Tracking.UspsTracker, YTech.ShipperInterface">
    <constructor-arg ref="postUtility" />
    <!-- Code removed for readability... -->
<object name="fedexTracker" type="YTech.ShipperInterface.FedEx.Tracking.FedexTracker, YTech.ShipperInterface">
    <constructor-arg ref="postUtility" />
    <!-- Code removed for readability... -->
<object name="dhlTracker" type="YTech.ShipperInterface.Dhl.Tracking.DhlScreenScrapeTracker, YTech.ShipperInterface">
    <constructor-arg ref="postUtility" />
<object name="simulationTracker" type="YTech.ShipperInterface.Tracking.Simulation.SimulationTracker, YTech.ShipperInterface" />

<!-- Combine all of the other trackers into one stream -->
<object name="multiTracker" type="YTech.ShipperInterface.Tracking.MultiTracker, YTech.ShipperInterface">
        <list element-type="YTech.ShipperInterface.Tracking.ITracker, YTech.ShipperInterface">
            <ref object="simulationTracker" />
            <!-- Order these by popularity -->
            <ref object="fedexTracker" />
            <ref object="uspsTracker" />
            <ref object="dhlTracker" />

<!-- Cache the upstream tracking data -->
<object name="cacheTracker" type="YTech.ShipperInterface.Tracking.CacheTracker, YTech.ShipperInterface">
    <constructor-arg ref="multiTracker" />

<!-- Handle errors by logging them, and returning a special ErrorTrackingData object -->
<object name="MainTracker" type="YTech.ShipperInterface.Tracking.ErrorHandlerTracker, YTech.ShipperInterface">
    <constructor-arg ref="cacheTracker" />

Now in my code, this is all I have to do:

var ctx = ContextRegistry.GetContext();
var tracker = (ITracker)ctx.GetObject("MainTracker");
var td = tracker.GetTrackingData("my tracking number");

Every piece I've written is fully testable. I even created a class that posts data to a remote web server, and returns the response. This allows me to completely test the tracker classes. They don't care if they're hitting against a real server, or an in memory request/response mock class.

I have nearly 100% test coverage, and making changes to the site is a breeze.

The next step is to convert the actual web project to an MVC project so that I can unit test the actual page functionality.

Hopefully I've given a good example of how inversion of control can be a really good thing. Have any more questions about the architecture? Feel free to leave a comment.

Note: I haven't replaced the code on the live site yet, but I plan on upgrading in the next couple of weeks.

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG