I’m going to describe a methodology that will help you save time by writing better classes, and will help simplify your life by allowing you to solve problems with a top-down approach.

Developers such as myself often have a tendency to just focus on the class we’re currently working on. Of course I believe this is a good thing, because we all know the importance of focus. However, you should never forget the reason you’re actually writing that class. It is because other code will be consuming it.

There have been far too many instances where I would figure out which pieces I needed to build, and then build each one, from the bottom up. The problem is that I would write the class in the most short-sighted and easiest way possible, which is usually not the best way to use it.

Now, when there is a question of what a class interface should look like, I ask myself what it should look like to make the life of the consumer as easy as possible.

Sometimes we can even take code usability to an extreme. For example, Fluent interfaces, which allow you to chain together multiple calls. In many instances, this makes the code much easier to call, potentially at the expense of making the called code more complicated.

I’ve come up with a simple example to help illustrate. Suppose I need to process a list of x,y coordinates. Here are a couple of potential signatures:

• ProcessData(double[] xData, double[] yData);
• ProcessData(PointF[] points);
• ProcessData(IDictionary<double, double> points);

For now, just ignore the performance implications (they’re going to be linear in this case, or close to it anyway). To choose the correct signature, we need to know who the caller is.

Of course there is a good chance that we’ll have a slight intentional leaky abstraction. In the previous example, we may have been able to use the IEnumerable generic to be more flexible. That’s a topic for another day.

Thankfully, this problem is minimized, although not always eliminated when you follow the single responsibility principle. The better you can follow that principle, the simpler each piece will be. That tends to minimize the potential for the consumer to need the interface to look different than it would naturally be.

Another way to look at your classes from the consumers point of view is to practice test-driven development. In fact, I see this as one of the strongest arguments for test driven design. For each layer in your code, you’re creating code by consuming it before writing it. Every layer acts as an API to the layer above it.

In conclusion, I’m simply recommending that you don’t lose sight of why you’re writing that piece of code. You’re not just writing code for the sake of writing code, you’re writing it to be used!

Today’s tip is a hack for getting awesome tech support from a company for a product that you may or may not have purchased. It may not be polite, but it may be a method of last resort.

We all knows what happens if you buy a product and then call for support. If you’re lucky, you get put on hold. If you’re unlucky, you’ve called outside of their business hours of 1am to 3am. When you do talk to someone, you’re treated like an idiot (in their defense, it’s a learned behavior).

If you want great service, call their sales department. Tell them you’re evaluating their product, but ran into an issue. You’ll be talking to someone that actually wants your business. They’re typically very helpful, and remind us of the benefit of good customer service.

Just today a coworker sent me a link (unrelated site) that had a link to a page called "Pre-Sales Questions". They’re openly distinguishing between potential customers, and paying customers. The problem is that they make the pre-sales question form easy to use, but the paying customer form is not. Customer service is in a bad state.

My official recommendation is to to fully try out their product during a trial, so that when do you do talk to their sales team, they can at least earn a sale from it. Like I said, this is a method of last resort.

One of your goals as a developer should be to make your code as readable as possible, both for yourself, and for the other developers you work with.

One great way to determine if your code is well written, is to ask yourself if the code you’re writing is readable by itself. Another developer should be able to jump into a module, and have a fairly easy time seeing what’s going on. They shouldn’t have to sift through thousands of lines of interweaved code to figure out what’s going on.

Of course, what I’m talking about is simply a test for the single responsibility principle. If you’ve written a huge "do it all" class with thousands of lines of code, you’re ensuring that you’re the only one that will be able to maintain it. That that type of code usually suffers from high coupling to the other modules in the program.

I used to organize code into classes based on the type of functionality being provided. I used them more as containers for related functionality. At the time, I didn’t see a reason to split it apart. I was very wrong.

In a recent article by Jimmy Bogard, he walks through creating classes with a separation of concerns. In the conclusion is my favorite part:

Now we have many more classes (4 vs. 1) and interfaces (3 vs. 0).  For those who don’t like more classes, GET OVER IT.

That is an excellent point. Why should you be afraid of creating more classes and interfaces? It’s really not more code to write, in fact, it’s often less. Refactoring tools remove many of the obstacles of maintaining the interface, class, and method structure

When someone looks at your code and you have 4 classes instead of 1, and those classes are very specific and short enough to process by our tiny brains, it will be much easier to maintain and modify (or even better, extend).

As I mentioned before, I’m trying to consolidate the number of websites that I have to maintain. My young-technologies.com domain was badly out of date, and didn’t really have any useful information. I decided to redirect all of it’s pages to this site.

The only page that was getting real traffic on that site was the Subversion virtual machine appliance, which I created a long time ago. I decided to move that page to this domain. That means that I have only one page to manage instead of an entire domain.

If you haven’t seen that virtual appliance, it’s worth checking out. It’s basically a fully functional Subversion install on Ubuntu linux, with WebSVN installed to view it in a web browser. It’s been downloaded over a thousand times, and it’s now being hosted using Amazon’s S3 service.

While the appliance has found a new home, I’m not sure if an when it’s going to be updated. If there are any future announcements about it, they’ll be made on this blog.

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.