I was recently in a meeting where we were talking about performance and someone posited that performance is the number one thing that should be focused on in enterprise software. While I will concede that I agree, I only concede in fourth.
I feel that ultimately software must be able to do four things, each of which are equally important:
1. It must meet consumer expectations
If a program has a million bells and whistles, all of which are great, it is utterly useless if the single bell all consumers want is missing.
2. It must work
This almost sounds silly to say, but there are countless commercial sites that I have not returned to because it was obvious that they had not taken the time to make sure that the most basic of things, such as logging in, work correctly. Directv is one such site that stands out in my mind – I can log in, try and pay my bill, and am returned to login – this becomes an endless loop. If consumers can’t trust you to test the basic and glaring issues how can they possibly trust you to protect their vital personal and financial information?
3. It must be fast enough
There is a marked difference between fast and fast enough. Fast is an ambiguous term that must be anchored to something relevant and, by itself, is just a meaningless number. Fast enough means that you can perform at a speed that the reasonable user would find acceptable. Fast enough means that you can handle the expected, and even above expected, load without sacrificing performance in the process.
4. It must be maintainable
We have all written bad code. Bad code sucks. Bad code is time consuming, frustrating, and overly detrimental to the company. Maintainable code should not just be functional but should be designed so that future developers are able to easily understand what is going on and quickly and accurately make changes. While this is not possible in every scenario, in most it is.
As a developer it is very easy to get focused on one or more of these factors, neglecting to treat each as a single part of the larger whole. The more time and effort developers are able to devote to making sure every application meets these four criteria, the more successful applications will be.
A younger version of me would have responded speculatively. However, the current me knows better. I don’t have any experience with direct customer interaction, so I don’t know how I would handle it. I would like to think I would go the honest route, because I have much more respect for customers than I do for management, which generally cares primarily about this quarter’s reaction from the gambling addicts on Wall Street, and I have zero respect for that.
Technically I am from the same realm, at least from Joel’s perspective. My background is in web based applications, which under his paradigm fits into the shrink wrapped software. I have experience as private contractor, as a corporate employee (both large and small corporations – small is my favorite), and through a brief but fun personal business. Through these I have done windows based stand alone application programming and web based programming, all of which fall into Joel’s realm of shrink wrapped.
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…
It sounds as if we might be from different worlds.
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?”
Why wouldn’t you tell customers the truth?
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…
My personal set of four edges, in priority order:
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.