Software Rockstar

SRP is one of the fundamental object oriented software design principles, first introduced by Tom DeMarco in 1979.

In simple terms, SRP states that every class should have a single well defined goal, and that all members of that class (properties, methods, etc.) should work together to achieve that goal. Robert Martin puts it in slightly different terms:

There should never be more than one reason for a class to change.

Essentially SRP enforces the concept of high cohesion that should not only be applied to classes but also internals of a class, such as methods.

So why is SRP such an important design principle? It is because a class with multiple responsibilities is more difficult to change and more difficult to reuse (design smells: fragility and immobility).

While SRP is quite easy to understand, it’s not always logical to implement. Consider the following class:

Given the convenience of having a customer class that is smart enough to know how to load and save itself, would you rather break it out like this?:

According to SRP, you should, because the combined customer class shares multiple responsibilities: customer business logic, and customer persistence logic. In fact if you use TDD, you may even be forced to separate these two responsibilities.

In practicality, however, while we should keep this principle in mind and try to apply it wherever it makes sense, we should never get so carried away that we start introducing other design smells in our architecture, such as Rigidity, Viscosity, and Needless Complexity.

While FxCop is an invaluable tool for analyzing the external (public / protected) API of our assemblies, I was really hoping to have a way to also fire it against internal members of our code in order to enforce coding standards across our organization. David Kean’s tip shows us exactly how to do that! It turns out to be a simple matter of turning on the Run all overridable rules against all targets option under Project | Options | Spelling & Analysis menu.

Currently I am working at a company with a fast-paced environment, very aggressive deadlines, and historically a high rate of failure in the form of poor product quality and missed deadlines. Back when I started at the company, I introduced them to Agile methodologies and how they could benefit the organization in higher employee and stake-holder satisfaction, fewer or no missed deadlines, and better product quality. After some initial mixed reactions I was able to get them on board with the idea — or so I thought!

While I have been successful in implementing many of the Agile practices such as earlier stakeholder involvement, EDUF, iterative development, code refactoring, unit testing, continuous integration, etc. in a relatively short amount of time, I still have to deal with the fact on a daily basis that they have to have very good estimates too far in the future. They must have this information from a budgetary standpoint and in order to be able to make executive decisions in advance about whether or not to proceed with a given project.

I have tried my best to explain how the Agile estimation works, and how trying to estimate too far in the future could be a wasted effort, but after all the time and energy spent, I am beginning to think that perhaps the Agile philosophy is not for all mindsets after all!