Steve Yegge is a big-time computer programmer, well-known in the industry, and he has a blog (Stevey's Blog Rants) where he posts about 15 times a year. This is not quite as limiting as it sounds, as his posts tend to be quite long; his most recent goes about 5500 words. His posts may touch on programming, but are by no means confined to that, and are always at the very least interesting.
His most recent post, Have you ever legalized marijuana?, is pretty good...for the first two-thirds, then goes off the rails. In that first two-thirds, you may wonder when Yegge will get around to discussing marijuana. After that, you'll wonder why he bothered.
The post is built around Dan Ariely's idea of "credit buckets," that is, partitioning people's credit limits by category. In that way, the consumer could manage credit at a more granular, and presumably more controllable, level. In effect, the very structure of the buckets would enforce a kind of spending discipline (you'd be limited in how much you could spend on gas, or on food).
The first inclination I have is to see the ways this wouldn't work. Wouldn't the average consumer just use more credit cards to get around these limits? I'm sure you can think of more. But I have to concede that awareness is a great deal of the problem, and the bucket idea might reduce the casual misuse of credit.
Ariely, in his book Predictably Irrational, goes on to talk about how he actually presented this idea to a bank board of directors, and how they never did a thing about it. Yegge then speculates that such a feature would work against the goal of the bank, which is, after all, to get people to use as much credit as possible, and it certainly has no problem with overdraft fees. This shows, yet again, according to Yegge, why "the banks are evil."
But then Yegge puts on his programmer hat, ponders how this simple idea would actually gets done, and theorizes as to the preliminary questions he would have to ask his boss (I will quote the entire list except for the last item):
And for what? For a feature that might or might not bring in any additional customers, and would almost certainly only bring them in by promising them that they would end up paying less to the bank. It's going to be real hard for the financial analysts to create a scenario in which the return on investment is positive.
I've worked on quite a few development projects in my time, and occasionally one of these things gets championed by a high-enough executive that it gets approved, and they pretty much all end badly (some time I'll tell the story of what happened when my management decided a new order and inventory system "needed" to be accompanied by a new user interface paradigm; it was not delightful).
Yegge goes on to apply this same kind of analysis to the legalization of marijuana, which he in general favors. But then he thinks of all the difficulties of implementing such laws, and finds that they get mired in the same complexity as credit buckets, and this is where the post kind of goes off the rails.
Because Yegge believes that making these laws are analogous to creating a complex piece of software, that it's an implementation of a project. The reason that the analogy doesn't hold up is that our political/legal system is built around just these sorts of issues, and the questions that he raises are not seen as deterrents.
If even one component of the bucket software doesn't work, it can prove calamitous for the project as a whole. If one component of the marijuana law doesn't work, well, people work around it in some way. Either the unworkable parts are ignored by law enforcement, or the public attorney avoids bringing charges around the problematic pieces, or the whole thing is left to the judiciary to interpret or rule. The imperfections that come out of the inability for people to anticipate every possible implication are handled by other people; if the problems rise to high-enough awareness, new laws are passed to delineate or modify the old law.
And that's why this post is valuable, even for non-technical people. Yegge's list of questions about the credit bucket project needs to be answered before work can begin. You can't just write up some of it, throw it out there, and hope it works (note that I'm not claiming that's true of all software, as there are projects that can be rolled out incrementally - but even that needs to be explicitly planned out). I don't believe the average person realizes just how difficult it is to create computer systems, and I think they should.
His most recent post, Have you ever legalized marijuana?, is pretty good...for the first two-thirds, then goes off the rails. In that first two-thirds, you may wonder when Yegge will get around to discussing marijuana. After that, you'll wonder why he bothered.
The post is built around Dan Ariely's idea of "credit buckets," that is, partitioning people's credit limits by category. In that way, the consumer could manage credit at a more granular, and presumably more controllable, level. In effect, the very structure of the buckets would enforce a kind of spending discipline (you'd be limited in how much you could spend on gas, or on food).
The first inclination I have is to see the ways this wouldn't work. Wouldn't the average consumer just use more credit cards to get around these limits? I'm sure you can think of more. But I have to concede that awareness is a great deal of the problem, and the bucket idea might reduce the casual misuse of credit.
Ariely, in his book Predictably Irrational, goes on to talk about how he actually presented this idea to a bank board of directors, and how they never did a thing about it. Yegge then speculates that such a feature would work against the goal of the bank, which is, after all, to get people to use as much credit as possible, and it certainly has no problem with overdraft fees. This shows, yet again, according to Yegge, why "the banks are evil."
But then Yegge puts on his programmer hat, ponders how this simple idea would actually gets done, and theorizes as to the preliminary questions he would have to ask his boss (I will quote the entire list except for the last item):
If you're not a programmer, or you've never been in a position in which you have to implement someone else's "great idea," you may not realize that this list is just the tip of the iceberg. These are just business-level questions, they don't even delve into the technical details. Chances are this bucket idea would cut across pretty much every existing system the bank has, which may well be divided by programming teams, so there are big organizational problems as well.
- Can customers control the buckets, or are they fixed?
- If fixed, how many are there? What are their names?
- Let's assume for the remaining questions that they are NOT fixed, since a predefined set of buckets would be "insanely stupid" and rejected by customers. So, how many buckets can a customer make? Min and max?
- Can customers give the buckets names? If not, do they have to use numbers?
- What characters can they use in the name? What's the maximum length? If we need to truncate the name in a printed statement, how do we truncate it?
- Can a customer change their buckets mid-month?
- Can a customer change their buckets between months? What if their balance is nonzero? Can they transfer balance between buckets?
- Can a customer change the name of a bucket? Do names have to be unique?
- Exactly how does a customer name a bucket? Online? Over the phone? By snail mail forms? Talking to bank teller? All of the above?
- Same question for all other configuration settings. How? Where?
- Do credit-card customer service reps have to know about the buckets? How much do they have to know? (hint: everything) Is there training involved? (hint: yes)
- Do the customer-service tools have to be redesigned to take into account this bucketization?
- What about the bank's customer self-service website?
- What about the phone interactive voice-response tree?
- What about the software that sends email updates to the customer?
- What about the software that generates printed billing statements? How exactly does it represent the buckets, the individual spending limits and balances, the carry-overs from month to month, the transfers, the charge-backs, the individual per-bucket fees?
- What about the help text on the website? What about the terms and conditions? What about the little marketing pamphlets? Should they try to explain all this shit, or just do some hand-waving?
- Can a customer insert a new bucket into the list? How are the credit limits of the remaining buckets re-allocated? What if adding a new bucket puts one or more of the older buckets over the limit? Do we charge fees? Do we tell the customer they're about to be charged a fee right before they create the bucket? Is it, like, OK/Cancel? Do we send them a follow-up email telling them they just fucked themselves over? What exact wording do we use?
- Can a customer delete a bucket? What if there's money in it? What if it's overdrawn? How do we represent the overdraft fee in the database? How do we show the deletion event in their bill?
- Can a customer merge or consolidate buckets?
- What if a customer has an emergency situation, plenty of limit in other buckets, and they really really need to charge to a couple of buckets, but they want to avoid an overdraft fee? What do they do? Are the buckets mandatory or discretionary?
- How the hell do we even tell if they're buying "chocolate", anyway? The vendor doesn't tell us the purchase type. How do we know how to charge the right bucket? What if it's ambiguous? What if the buckets overlap? Does the customer need a point-of-sale interface for deciding which bucket to put the charge in? Can they do "separate checks" and split the charge into several buckets?
- Where are you going? Answer me!
And for what? For a feature that might or might not bring in any additional customers, and would almost certainly only bring them in by promising them that they would end up paying less to the bank. It's going to be real hard for the financial analysts to create a scenario in which the return on investment is positive.
I've worked on quite a few development projects in my time, and occasionally one of these things gets championed by a high-enough executive that it gets approved, and they pretty much all end badly (some time I'll tell the story of what happened when my management decided a new order and inventory system "needed" to be accompanied by a new user interface paradigm; it was not delightful).
Yegge goes on to apply this same kind of analysis to the legalization of marijuana, which he in general favors. But then he thinks of all the difficulties of implementing such laws, and finds that they get mired in the same complexity as credit buckets, and this is where the post kind of goes off the rails.
Because Yegge believes that making these laws are analogous to creating a complex piece of software, that it's an implementation of a project. The reason that the analogy doesn't hold up is that our political/legal system is built around just these sorts of issues, and the questions that he raises are not seen as deterrents.
If even one component of the bucket software doesn't work, it can prove calamitous for the project as a whole. If one component of the marijuana law doesn't work, well, people work around it in some way. Either the unworkable parts are ignored by law enforcement, or the public attorney avoids bringing charges around the problematic pieces, or the whole thing is left to the judiciary to interpret or rule. The imperfections that come out of the inability for people to anticipate every possible implication are handled by other people; if the problems rise to high-enough awareness, new laws are passed to delineate or modify the old law.
And that's why this post is valuable, even for non-technical people. Yegge's list of questions about the credit bucket project needs to be answered before work can begin. You can't just write up some of it, throw it out there, and hope it works (note that I'm not claiming that's true of all software, as there are projects that can be rolled out incrementally - but even that needs to be explicitly planned out). I don't believe the average person realizes just how difficult it is to create computer systems, and I think they should.
No comments:
Post a Comment