I suppose when it really comes down to it you are right - the customer is concerned about themselves first and foremost. It is this self concern that makes me wonder why we shouldn’t play to it. When you phrase it as, “we need to take time to make sure our infrastructure is maintainable”, it is far less appealing than when you state, “we have recognized a number of issues that will keep us from serving you to our fullest potential and need to take a bit of time to make sure they are fixed”. The difference is primarily a sales one - you are stating the same thing, but putting a different spin on things.

I am not discounting your reasoning a bit - I tend to walk a bit on the theoretical/philosophical side and have a background in both business and software so the concept of hiding the truth, even discretely, is one that arouses my curiosity.

So let’s take a “theoretical” example that is loosely based upon my previous real world experience. There is a customer that we engaged long ago that our sales group made big promises to. The promises were originally thought to be copesetic until we actually profiled various aspects of our system and realized that they would not meet up with the customer’s expectations. So we now have a choice: do we go to the customer and say, “we screwed up - let us fix it”, or do we tell the customer everything is great and hope that we can fix things before they find out?

My experience and consumer sense states that you tell the truth and let customers know you screwed up. Customers are surprisingly forgiving when you are forthright with them. Conversely, they are surprisingly vehement when they find out you attempted to deceive them.

So in another example, lets say that you are the customer and have a good relationship with a vendor. If they need to do some kind of major maintenance to keep their systems up and running would you rather them tell you that they were updating their systems or tell you that they were doing work “for you” and keep quiet about the internal enhancements? Keep in mind that when they do the work “for you” you have to pay for it - when they do internal enhancements it is handled as a capital expenditure that is not mapped to a client’s cost center…

http://www.joelonsoftware.com/articles/FiveWorlds.html

I’m from the shrinkwrap world. The people who pay me are my superiors as opposed to our customers. (Our customers pay me indirectly and do not interact with our development process.)

What world are you from?

I suspect, though, no matter what world you are from, that if you were to tell your customers that code maintainability is your highest priority, they would nod and pay lip service to your wisdom, but within minutes would be back to chanting “is it done yet? is it done yet? is it done yet? is it done yet? is it done yet? is it done yet?”

In this case the truth is beneficial to them - you are spending time making sure that the systems and infrastructure are maintainable. This keeps them from being online one day and offline the next…

1. Maintainable. Without this, getting to 1.0 is impossible, so it’s the top priority of a successful project regardless of whether anyone likes it. From a longer-term standpoint, if you hope to re-use your code in 2.0 or in order to deliver other projects faster, this becomes even more important.

2. Works, which includes “meets consumer expectations”. This is the top priority of the people who pay you. You TELL them this is your top priority because they can’t handle the truth.

3. Fast enough. This pleases the people who actually use the software. Surprisingly few projects must care about this because they’re just hooking together chunks of code written by other people (including operating systems).

4. On schedule. Being late to the party didn’t prevent iPod from obliterating all competition.