Do you build rooms with doors or doors with rooms?

Should every room be the same size with doors of different size, shape and placement?

Are some doors in the floor or in the ceiling, at floor level or in the middle of the wall?

Do your doors open in our out? Are they too small? Too big?

Rooms are code that does stuff. Does work. Holds stuff. Creates stuff.

Doors are code that gets stuff into and out of rooms.

Which one do you spend more time working on?

A certain angel investor chose three companies in which to invest a relatively large sum. In the first, he invested $10 million. In the second, he invested $5 million. And in the third, he invested $1 million. A year later, the first had doubled in value because it had boldly used the capital to execute on its business plan. The second company had also doubled in size because they had taken the investment and worked very hard to grow their business. The third company had run into some problems and was afraid of losing their capital, so they did nothing and had nothing to show for it. The angel investor liquidated his interest in the third company and those people are now looking for work.

Yes, I’ve borrowed the plot for that story from someone much wiser than me. But it applies in today’s world of technology and software development as much as it applies to the context for which it was originally told. Fear paralyzes us into inaction or into making unwise choices which almost always result in the corruption of otherwise sound business processes and just as often leads to complete and utter failure.

One of the greatest fears in software development that corrupts process and assures failure is the fear to tell the client or customer no. In the world of software development, especially in internal enterprise software development, the fear of saying no can be so paralyzing that we often place impossible burdens on teams already pushed to their limits. The fear of saying no can lead us to short circuit our process, skip critical steps and gloss over real analysis and careful design. The fear of saying no can lead to general discord when a team member objects and the manager angrily brushes her off, dismissing her concerns as irrelevant or inconsequential. This fear leads to chaos and assured failure. Failure to deliver on time. Failure to communicate and manage realistic client expectations. Failure to establish credibility and confidence with the client and the organization. Failure to keep and foster a well organized, happy and productive team.

So how can one overcome this fear? You just jump. How does the diver overcome his fear of heights to jump from a platform so high the first time? He just jumps. How does a skydiver overcome her fear of falling to her death from an airplane? She just leaps or is pushed. And then training and preparation take over and fear is overcome. You may never completely overcome the fear of saying no. But if you jump, take a leap of faith, just do it, you’ll find that you have not died and that you will have an easier time doing it the next time.

When we overcome our fear and take a leap of faith, we can accomplish great things. Let us work like the first two companies in our story and succeed.

Tracking down a problem in a commercial .NET library today, I found this little gem (identifying code in the try removed):

try
{
   //any code that could fail in any way here
}
catch (Exception)
{
}

Not only should this construct not compile, any attempt to do so should cause your computer to explode.

Nothing in this post is original. It’s just my reduction of the principles of class design from Uncle Bob in his Principles of OOD. If you don’t want to read, listen to the Hanselminutes interview with Bob. I just want to record my thoughts on these items here for posterity.

SOLID is just another acronym but if you are writing code it’s one you ought to know about.

SRP – Single Responsibility Principle: “A class should have one, and only one, reason to change.”

OCP – Open Closed Principle: “You should be able to extend a class’s behavior without modifying it.”

LSP – Liskov Substitution Principle: “Derived classes must be substitutable for their base classes.”

ISP – Interface Segregation Principle: “Make fine grained interfaces that are client specific.”

DIP – Dependency Inversion Principle: “Depend on abstractions, not on concretions.”

These are not new ideas and I’ve not visited these lately nor can I claim to practice these principles in everything I do. In fact, I’m sure that I don’t, but I am convinced that the more I follow these principles, the better my code will be.

I’m going to spend the next few days reabsorbing these and reading the PDF docs on the www.objectmentor.com site. If you want to follow along with me, start at the top of this post and follow the links.

Happy reading!