Quality & Trust

Recently we had a new release of an application that didn't go as well as planned, which I'm sure a lot of you can probably relate to - after all, how many rollouts do go as planned?

This new release contained miles of bug fixes and enhancements and was being touted as a major step forward. Lots of work had been put into making this release "a fresh start", enabling an excellent foundation for us to build on in future versions - something the previous versions were lacking.

So from a development point of view this new release was a great success.

However, even though we (the developers) were pleased, once we rolled it out we began to notice a few problems, mainly related to the different environments (dev, test, live). You know - the errors that seem to "work fine on my machine" but crash horribly on the server.

Whilst we have since resolved the errors and the application is now working great, the questions remain - did we take a step forward in the eyes of the user? Will they overcome the inconvenience we caused them during the upgrade now that they see the benefits of the new version? etc, etc

Yes, I think so. BUT - we have tarnished a fragile relationship. The relationship the users have with us. They depend on the application to work, and work well, hence they depend on us. They trust us. They trust us to make sure each new version is better than the last. They trust us to make sure every release is smooth and seamless. They trust us to make sure we performed in-depth testing.

So did we break that trust? Did we deliver the quality the users have the right to expect?

I hope not, but if we did - trust is something that's going to take a while to rebuild - perhaps a lot longer than it will take to rebuild the application alone.


Comments (1)
  1. David C says:

    does the Marketing department break your trust when the new accounts rate is down every month? Does Customer Support deliver on the quality you expect when client attrition rates are climbing every quarter?  Do you as engineers, developers, whatever you call us have the right to hold a grudge, or hold some kind of abstract concept of "trust" that shouldn’t be "broken"?  No more than Marketing or CS or anyone else.

    You said it yourself – they are seeing the benefits now.  If they are too stupid or petulant to respect that and now move forward, then your leadership needs to find ways to make that difference ($$$) more obvious to them.

    And don’t worry about their feelings too much.

    And assemble a seasoned, veteran, environments team and give them lots of money to buy stuff with.

Comments are closed.

Skip to main content