Moving

I'm not moving my blog to my new home page at http://curtiscooley.com. The main reason is I'm starting my own software contracting and agile consulting company. At first it'll just be me trying to find companies willing to give me money in return for helping them build software. My main value add will be my many years of agile consulting. Not that I'll try to convert shops to agile, but just that my agile experience has taught me how to maximize value to the customer.

Thank you all for following me here and I hope you follow me to my new site.

You can also follow me on twitter:CurtisRCooley

Also, my new blogging software does a much much better job of formatting source code, as you'll see by my first post there: Why You Should Program To Interfaces Part I

Are We Asking Too Much From Programmers?

In the olden days software teams were split into two distinct groups: architects and programmers. Architects designed the system and programmers implemented the design.

Then Extreme Programming came along and said splitting teams up wasn't a good idea. Everyone should be in the same room. Collective code ownership said that anyone should be able to work on any piece of code. Now architects had to code and programmers had to design.

Architects advanced to architect from programmer, so they'd coded before. The transition to writing code, while humbling, was not a huge task.

Programmers were programmers because they were not architects. They had not designed before. This transition is more troubling.

I'll cop out a little and lean back on the age old construction metaphor. See, construction workers aren't architects. Most of them don't even strive to be architects. They build things with their tools and their hands and enjoy it, why would they want to build things with paper and pencil?

In agile development we are asking programmers to design. Maybe they don't want to design. Maybe, for some reason, they can't design. It's not part of their mental makeup. They construct. They are good and constructing. Why are you asking me to do more than construct?

I've read and signed the Craftsmanship Manifesto, http://manifesto.softwarecraftsmanship.org/ and joined their Google group, http://groups.google.com/group/software_craftsmanship/web/the-new-left-side?pli=1. There is a thread in the group titled something like "Should we/can we convince programmers to care about their craft?" This thread got me thinking and that thinking lead to this blog.

So, are we, the Agilists and craftsmen, asking too much from programmers?

OO Basics: Create the right object

Most people learn structured programming before they are exposed to object oriented programming. That's just the nature of the beast, since you need to learn the basics of a language before you can move on. At least that's the latest theory. The problem with structured programming is you learn to use flags to signal changes in state. You then end up with ifs and switches all over the code. For example

if (item.isTaxable()) {
  item.setCost(item.getCost *= TAX_RATE);
}

The root of the problem is that you only have one kind of Item.

public class Item {
  private boolean taxable;

  public boolean isTaxable() {
    return taxable;
  }
  ...
}

where two types are needed:

public interface Item {
  double getTax();
}

public class TaxableItem implements Item {
  public double getTax() {
    return cost * TAX_RATE;
  }
}

public class NontaxableItem implements Item {
  public double getTax() {
    return 0;
  }
}

You also have a problem with how the object is created:

Item item = new Item(true);

Say you are implementing a shopping cart, and as the user adds items to the cart, the correct type of item is added. Then at the end, you can calculate tax for the taxable items because the cart already contains the right kind of item.

cart.addItem(ItemFactory.createItem(itemId));

Now there are no ifs in the domain code:

for (Item item : cart.items()) {
    tax += item.getTax();
}

The moral: a lot of ifs and their accompanying headaches go away when you take the effort to create the right object.