Dear Joel,...Here's a letter I just received from Joel Spolsky's company, FogCreek Software. One year and a half later, they've sent me, for the second time, a DVD I had ordered. Good customer service, you would say: my first package was lost in the wild so they graciously sent me another one. But I really didn't expect that they would resend me the initial DVD that was miraculously returned to them after more than a year! Is that exceptional service or what?
Why did they do that? I was already pretty much satisfied the first time when they quickly sent me another DVD after the first one was lost (I've even heard about some companies doing that on purpose, just to show how good their support was afterwards). But what could they gain by over-satisfying me? Well, I assume, they just didn't miss that wonderful opportunity to show me how much they actually care about me. Not that I felt so miserable and alone on earth, but I was really touched by the attention. Now I really can say that this company has something special.
Ok, ok. How can they afford that? How can they sustain a double-digit growth each year by wasting so much time? Well, they simply don't ("Fog Creek is focused on growing slowly and carefully and staying profitable"). However if they pay so much attention to each of their customer, which I think they do, they are certainly here to stay.
Less is more
There is some kind of "less is more" pattern here. Less market growth, conquest, expansion,... but also more satisfied customers, upgraded installations, license extensions (anyway, Joel thinks that it takes ten years). And guess what, I think that the people working at the customer service are happier too. They certainly prefer 1000 times receive congratulations than coping with angry clients.
In a sense, this is also a "political" decision. Deliberately choosing to do less but to do better shows how you care for others: your customers, your co-workers. It is some kind of "idealist" choice. But is it also a "pragmatic" choice? Is it also a good economic choice for your company, especially for a software company (yes, I don't speculate often about fashion,...)?
Just wondering
Unfortunately, I don't have an answer with elaborate studies. But I am wondering,...
1. Are there times when you should choose "speed" against "quality"?
From the moment you select a feature to implement in your next release what do you get from delivering it faster but buggy? One more customer, of course! The one who is craving for this new feature. The one who's considering that not having it is a deal-breaker, the one,... who will be so mad to discover that it doesn't work!
[Unless he's just a golf player, he's a close buddy of the CEO, and he doesn't care so much as long as your software is buzzword-compliant. But this is another discussion]
Even when prototyping a new idea, we should be careful with "speed", because the frontier between "rapid prototyping" and "semi-chaos" is pretty thin (not to talk about the frontier between "prototype done" and "let's call it 1.0"?)
2. Is it so expensive to focus on the user-interface?
Yes, this can be pretty expensive. You may have to hire a usability engineer for the sole purpose. And I say that because I know what's the big gap between the half-baked interfaces I will ever produce and the interfaces that are carefully crafted by professionals. But this is not only for the beauty of the game. How many hours are going to be lost by: your helpdesk, your consultants, your newly-hired engineers, your partners? Oh, yes, and your customers,...
3. Why not set-up an "aggressive plan"?
This one really makes me wonder,... I guess that for any project, if you could start it over a thousand times, you may discover the most efficient way to order and parallelize activities so that the least amount of time is lost. But you can't do better, can you?
What are the variables you can play with when starting a project?
1. deadlines
2. quantity of people
3. motivation
4. quality of people
5. customer expectations
So far, an "aggressive plan":
1. fixes deadlines using ballpark estimates of the project estimates and insists that the target can't be missed. Time lines being then the only success criteria, this usually compromises any chance of success before the project even begun.
2. throws in between a moderate amount of people ("we can do it") and a big crowd ("we'll do the maximum")
There are strong suspicions that throwing more people on a project can only make it worse (Brooke's law and this study). Anyway, I am not sure there's much "aggressiveness" to have here. The "right" number of people will do. The good question is not: "is it aggressive enough?" whatever it means, but "are we properly staffed for this?"
3. motivates highly everybody
By either: insisting on the "heroic" aspect of the venture or reminding that "aggressive" concerns each one personally,...
4. tries to gather talented individuals,..
As far as 2 or 3 weeks allow it (because the preparation phase was also "aggressive")
5. decides bravely to deliver only one single feature.
No, just kidding!
Quality, ergonomic user-interfaces, sustainable project pace and even slack, why not go slow?
"less is slow, slow is fast, fast is more" (or the other way around ;-) )
One place where it makes the most sense in certainly when coding:
- less is slow: you need time to find the right abstractions, the proper structure, the proper names. You need time to remove the unessential (the famous StExupery word about perfection)
- slow is fast: you worked hard to produce less, but you get more value because code is a liability, and less allow you to move things around faster
- fast is more: there is a tipping point when you can add much more ideas to your software because you just play with the right legos
Perceptions
Try this at home. As an experiment:
- crank out code (I mean "crank" if you don't religiously follow the red-green-refactor mantra)
- take time to refactor it
- add some meaningful comments (the why, not the how)
- add some user doc (it can be a document or a few comments in a header)
- take note of the additional time taken
- forget all that for a few months (2 will usually do)
- try to estimate how much time was saved -just for you- when you read that code again
Same idea, different context: why don't we do TDD all the time? Because we don't perceive the difficulty of what we're doing. If you'd realize that each line of code can bear many different and subtle bugs, you would just want to secure it before coding the rest. [And there are plenty of other benefices too].
I am ashamed to confess this, but 2 days ago I wrote a simple "Table" class, taking a list of n row names, a list of m column names and an array of n x m values. I had to create a method that returned the value for a given row name and column name. Can you do it with you eyes closed? Good for you. I was inspired enough to write a few specs before using the class,...
Those are 2 examples showing that we should be careful with our perceptions and ask ourselves:
- Can we really "not afford" to refactor?
- Can we really "not afford" to give more time to a project?
- Can we really "not afford" to hire a usability engineer?
- Can we really "not afford" to look for better tools and practices?
Higher-order ideas
In my next post, I'll go slow again. I'll have a look at a language I just started learning. Yes, there's going to be a substantial learning curve, desperate evenings just trying to understand why this f*****g line doesn't work. But I am pretty sure this will pay off, allowing me to get more with less, to go fast because I was slow.
I've chosen Scala as my "Programming language of the year". Scala is not even in the 50 most popular programming languages, but I think it really embodies higher-order ideas, ideas that let you express other ideas with less words, doing more with less.
Stay tuned for the "Scala to Heaven"!
No comments:
Post a Comment