I really want codesqueeze to be a blog with a lot of discussion and ideas, so I was very pleased to see that commenting has started to pick up. So ‘thank you‘ to everyone who has commented this month. If you missed an opportunity to participate don’t worry, here is this month’s concentrated dose of codesqueeze.

Readers Choice:

1. The Secret To Only Working 8-5
2. The Software Process Imprinting Dilemma
3. Burning Down the Architect Title
4. The Gut Instinct Equation
5. How To Tactfully Gain Approval For Changes

Author Favorites:

• Lobsters Attack the Gut Instinct Equation
• When Quality Service Affects Quality Software
• The Software Process Imprinting Dilemma

A recent analogy comparing software maintainability with a lobster triggered a moment of inspiration about the Gut Instinct Equation.

From the Gut Instinct Equation we know that progress is not linear. What I am now pondering is if this is because of the cost of maintenance. Even on greenfield projects this cost starts coming into play once you write one line of code. For each added feature, you must maintain the integrity of every feature you wrote before it.

Could it be that the developer on the project never realizes that the system is unmaintainable, much like a lobster in a slowly heating pot. The lobster has no idea what’s coming.

Slowly over time, much like the lobster, the team slowly finds itself grinding its wheels. Productivity has not decreased, in fact, they are probably starting to work overtime even. Costs are starting to very slowly spiral in terms of labor per feature. Bugs might be incrementally getting worse. The team, however, hasn’t noticed any drastic change in the project or the way they work. – Evan Hoff

After reading the above analogy, I became very aware that perception is not always reality. Perceived progress stays linear because ensuring previously built features don’t break is a subconscious and automatic response. However, the cost of doing feature maintenance increases with refactoring, more testing, or just the time to slow down and think.

If this is the case, TDD and unit testing becomes very important. Having the comfort of unit tests allows developers to do fearless refactoring, quicker testing, and reduces the drag time pondering if something will break.

Remember young grasshopper…you may not be a grasshopper at all…but a lobster in a pot!

Imagine this, you are in a meeting with a client and they request something absurd. You respond that it is a bad idea from a technology view. Your business analyst (program manager, whatever) shoots you a look while calming the client and saying “of course we can do that feature“.

Sound familiar? If it doesn’t you haven’t been in the business long. While the last few years in the software consulting business have been great, I have had problems adapting to some of the consultant mentality.

The saying “provide a great customer experience” floats around often. I can completely agree with this; however it appears that engineers and businessmen view quality service from different perspectives.

Engineers would like to believe that a great customer experience is derived from two things: the delivered software and their professional opinions and expertise that created the software.

Businessmen view great customer experience as being as accommodating as possible. Making customers feel important and in control. This part of business should be accredited as well, it is an important part that keeps customers returning.

But here is the problem with these polar views…

Engineers may not care if the client experience is blunt, harsh, or hard-to-swallow; as long as the delivered software perfectly fits the customer’s need and is something the engineer is proud of.

On the other hand, the businessman is more interested in ensuring that the client walks away with a feeling of satisfaction over quality software, which might lead to feature creep and unrealistic promises. The perspective is that a happy customer with a piece of crap is better than a customer with great software but an unpleasant experience.

Maintaining customer relationships is like running a restaurant – you need to provide both quality service and product. If your favorite Italian restaurant is out of the lasagna, they will politely say they are out of the lasagna and give you other options – realistic and polite. They do not bluntly declare “Impossible!“, nor do they say “Sure! We will look into that…“.

When asked for a feature enhancement, most clients are asking if it can be done. If it can – accommodate. If it can’t – politely explain why not and provide some new options.