Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

The Most Productive Programming Language

The most productive and useful programming language you know, by a long shot, is English or Hindi or Portuguese or Spanish or French or whatever human language your team uses. Good communication skills are way more valuable to you and your customers than picking up a new language every year. That is, while there is value in the item on
the right, I value the item on the left more. Sound familiar?

Developers that name things well and program with a respect for human
languages create more maintainable and easier to follow code. Being able to communicate with a customer, analyst and/or product owner can save you hour upon hour of effort and keep your solution simple. No programming language no matter how syntactically minimal or internal DSL friendly can ever come close to this.

Posted in basics, coaching, craftsmanship, Language | 8 Comments

London Workshop, December 1-2

UPDATE: The workshop is scheduled for December 2-3.

A little housekeeping. I’m doing a two-day workshop I’m doing in London in December (1-2).


I’ll share the experiences and tools I’ve developed as a team
lead over the last decade doing architecture on Agile then Lean teams.
My thesis should sound familiar: we need a Chief Architect-like role in
development, someone who considers all aspects of the system and can
coach the team toward emergent design in product and process. The
workshop is aimed at giving you actionable tools and an overview of
things I’ve seen work really well together. Some of the
Lean/Kanban-related topics include how XP works with Kanban and how
architectural/design approaches can help get to release-per-feature and higher ROI for your business.

The course is appropriate for technical leads (current and
aspiring), product owners and designers, coaches and senior developers or
software architects.

Hope to see you there (and have pints with the London Kanban and AltNetBeers kids)!

Posted in announcements, architecture, housekeeping, kanban, lean, XP | 1 Comment

Exceptional and Substitutable

I watched Sean Chambers deliver an excellent talk about S.O.L.I.D. principles last weekend at Tallahassee CodeCamp. It motivated me to look a little deeper into the Liskov Substitution Principle, which states:

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

We accept this as a truth and it’s what makes us hate the is keyword in C# so damn much. I wrote a post a while back that explains (or attempts to) what LSP and why it’s important, which is to say I won’t harp on the what and why here. I’ll spend your attention, rather, on how LSP works with exceptions.

The LSP article on Wikipedia provides clarification around exceptions and subclasses:

No new exceptions should be thrown by methods of the subtype, except
where those exceptions are themselves subtypes of exceptions thrown by
the methods of the supertype.

Here’s a contrived and fugly example in ruby:

class FileSystem

def save(path, text)
File.open(path, 'w+') {|f| f.write(text) }


class AmazonFileSystem < FileSystem

include 'amazon_library'

def save(path, contents)
write_to_s3(path, contents)
AmazonWebServicesError.new('cannot write file');


class AmazonWebServicesError < StandardError

def initialize(message)
@message = message

def message
return @message


def backup_system

file_name = 'book.txt';
my_important_text = 'hello world';

[AmazonFileSystem.new, FileSystem.new].each do |file_system|
rescue AmazonFileError


A try-catch (or begin-rescue) is a conditional pattern and it’s my sense that when we use this with implementation inheritance we’ve made a particularly egregious and insidious violation of the LSP.

First off, we’re know things about the internals of our subclass in our consumer. We’ve broken encapsulation and increased coupling.

Secondly, our special AmazonWebServiceError only shares StandardError with what’s likely to be thrown by our FileSystem class. This means we can’t treat errors that are likely to fall out of Ruby’s IO core polymorphically. More conditional logic/branching, more cyclomatic complexity, more coupling, and these are bad things.

What can we do to stay on the good side of LSP when dealing with exceptions in inheritance hierarchies, you ask? Well, as the rule states, we can make exceptions subclass the exception the parent throws. For example, we could catch whatever error our fictitious amazon library throws and decorate it with a custom error that derives from the error File.write in ruby core throws. Another, perhaps, better option would be to hold off on coding defensively wherever you can and let the exception bubble up to a central part of your program that deals, exclusively, with these corner cases. That is, implement an exception shield wherever we don’t need compensating logic.

LSP and exceptions: another thing to pay attention to while on programming’s happy trail, friends.

Posted in C#, design, oo, principles, Ruby, solid | 2 Comments

The Secret Sauce

Are you listening? I’m about to give away the secret to to all of this this Lean/Agile/Software Craftsmanship fuss. The secret is… DISCIPLINE.

“The time is always right to do what is right” — Martin Luther King, Jr.

Assuming we know what to do, and I know a lot of you reading this do, we should always just say no to shortcuts. Delivery pressure is a real thing, but if you’re estimating a piece of work, estimate what it’ll take to do the right thing. If real Object-Oriented Programming is new to you, it’s going to take you a whole lot longer to get something done. If the language is new to you, it’s going to take you a lot longer to get something done.

Sometimes we take embarrassing and unprofessional shortcuts like:

  1. Getting out of TDD mode.
  2. Rolling shoddy spike code into production.
  3. Using an older, more familiar but less quality recipe to a common coding task.

The best way I know of to keep discipline up is pair programming. Some would say pairing is the way because two heads are better than one. I say it’s a great practice because it creates a healthy peer pressure.

Learning and discipline are the two halves of continuous improvement. In short: live what you learn, act on your new knowledge and skill.

Posted in continuous-improvement, kaizen, teams | 6 Comments

Return False on the Happy Path

When you call a query method that returns true or false, I
highly suggest that you make true results trip conditional logic /
guard clauses / etc. I was driving out some code today in an MVC controller that had a dependency on an type who’s responsibility it is to check for unique email addresses in a database of user which looks like so:

public interface IUniqueEmailValidator
bool EmailAddressIsUnique(string email);

All well and good, but you’ll notice that the method returns true in the happy path. That is, if an email address is unique (working on an authentication system), the object returns true.

I use an auto-mocking container when doing TDD with .NET. Most implementations give you back a so-called dynamic mock which just absorbs calls and returns default values on methods that return value types. So in the case above, a dynamic mock will always return false unless you tell it otherwise. I’d end up having to put noisy stub code in all of my other specs. For example:

.Stub(u => u.EmailAddressIsUnique(null))

In the controller we’re working on right now, there are about 10 specifications that failed because of this default behavior. This is a big problem because the introduction of a new specification results in me having to change a bunch of other contexts which is stinky, fragile design!

An opportunity to make things better! I changed the interface to this:

public interface IUniqueEmailValidator
bool EmailAddressIsUnique(string email);
bool EmailAddressIsTaken(string email);

The new EmailAddressIsTaken method simply inverts the result of EmailAddressIsUnique. Really frighteningly simple stuff, but, by calling the new method, my test code stays isolated and the special cases don’t break my numerous other specs.

Posted in BDD, C#, code, design, oo, TDD | 12 Comments