Saturday, September 29, 2007
This isn't what I meant, but...
This isn’t what I meant when I suggested saying that “Java is the right answer to the wrong question, Ruby is the wrong answer to the right question,” but who can resist this line?
The post is well worth a read!
If Java is the answer, it must have been a really verbose question.
—Chalain, Elegance Is...
The post is well worth a read!
Friday, September 28, 2007
Off Topic: Peace and Love
Obie wrote a wildly satirical post wherein he set his phasers to “Disintegrate, with maximum prejudice.” Of course, there has been a backlash. Including from people who love Ruby.
Well, first, let me talk to people using Rails and Ruby who are miffed that Obie has made people angry. Should be be censured? I say Non.
You are nice people. You don’t want to offend anyone. You want to reach out and hold hands and embrace and take over the world with non-violent peace and love. I’m all for that, and I applaud you. The world is a better place with you in it. Obie isn’t that way, not always, that much is obvious. If this were the sixties, I have a feeling he would be throwing rocks at the pigs. And you would abhor his actions as counterproductive. You would complain he’s alienating the people you want to convert.
That’s how movements work: There is no single cohesive, Ruby community with a single purpose and a single, coördinated plan of action. There are a bunch of people, some of whom form little groups, some form big groups, some go one way, some go another.
This is really why Ruby will not take over the world in its present form, of course. The other side has huge corporations, where everybody is in it for the career, for the money. They’re passionate about their career, about making money. So if you say “Hey, be nice to so-and-so so you can get a bonus cheque,” they are nice to so-and-so. What do they care about whether they actually like that person or not?
But people who are in it for the passion, they are opinionated. And the beauty is, we (I count myself as passionate) all have our own individual ideas. Which means we bring a lot more to the table than a million monkeys marching in lock step. They can overwhelm anything in their path, but they only have one path, they only go one way. We let a thousand flower bloom. And sometimes, we work against each other.
For example, why are the three major Ruby VM efforts (Rubinus, YARV, and JRuby)? Is this the work of people who can agree on anything?
let’s keep things in perspective
Anyways, so Obie tried to make a funny. I laughed, a little. Okay, I laughest hysterically at the line Java has a compiler. Ruby does not. That's great! Fuck compilers and their false sense of security. That was pure, unadulterated George Carlin brilliance
.
But a lot of people took it seriously and got very offended. That’s happened to me when I’ve joked about Java as well. And at the time, I told them to go soak their head in a toilet.
Today I’m a little more mellow. I just had a delicious, fresh roasted mug of Costa Rica’s finest. What do we care what Obie Fernandez thinks?
We’d have to be pretty insecure to get outraged when some guy who’s a drop-out from a consulting firm insults our tool of choice (no deliberate offence intended, I admire people who drop out of the rat race). If you read it and you were amused, great. If you read it and thought it was serious, you could respond. You could ignore it. But why get outraged? For what? One guy’s opinion?
What kind of life is it if we are to walk around all day with our happiness held hostage by people we’ve never met, just because they have a blog and they write about the things we use?
Or do we fear him? Is our manager going to read his list and say “Oh, what idiots we are to use Java here at BigCo, let’s switch to Ruby?” Are we worried that Obie is spreading lies and disinformation that will somehow get us tossed from our cushy jobs? Do we have to get the facts out this very instant before his heresies infect the world?
I didn’t think so.
So, my message to everyone, whether you love Ruby, or Java, or both, or neither, is simple:
Peace and Love.
Well, first, let me talk to people using Rails and Ruby who are miffed that Obie has made people angry. Should be be censured? I say Non.
You are nice people. You don’t want to offend anyone. You want to reach out and hold hands and embrace and take over the world with non-violent peace and love. I’m all for that, and I applaud you. The world is a better place with you in it. Obie isn’t that way, not always, that much is obvious. If this were the sixties, I have a feeling he would be throwing rocks at the pigs. And you would abhor his actions as counterproductive. You would complain he’s alienating the people you want to convert.
That’s how movements work: There is no single cohesive, Ruby community with a single purpose and a single, coördinated plan of action. There are a bunch of people, some of whom form little groups, some form big groups, some go one way, some go another.
This is really why Ruby will not take over the world in its present form, of course. The other side has huge corporations, where everybody is in it for the career, for the money. They’re passionate about their career, about making money. So if you say “Hey, be nice to so-and-so so you can get a bonus cheque,” they are nice to so-and-so. What do they care about whether they actually like that person or not?
But people who are in it for the passion, they are opinionated. And the beauty is, we (I count myself as passionate) all have our own individual ideas. Which means we bring a lot more to the table than a million monkeys marching in lock step. They can overwhelm anything in their path, but they only have one path, they only go one way. We let a thousand flower bloom. And sometimes, we work against each other.
For example, why are the three major Ruby VM efforts (Rubinus, YARV, and JRuby)? Is this the work of people who can agree on anything?
let’s keep things in perspective
Anyways, so Obie tried to make a funny. I laughed, a little. Okay, I laughest hysterically at the line Java has a compiler. Ruby does not. That's great! Fuck compilers and their false sense of security. That was pure, unadulterated George Carlin brilliance
.But a lot of people took it seriously and got very offended. That’s happened to me when I’ve joked about Java as well. And at the time, I told them to go soak their head in a toilet.
Today I’m a little more mellow. I just had a delicious, fresh roasted mug of Costa Rica’s finest. What do we care what Obie Fernandez thinks?
We’d have to be pretty insecure to get outraged when some guy who’s a drop-out from a consulting firm insults our tool of choice (no deliberate offence intended, I admire people who drop out of the rat race). If you read it and you were amused, great. If you read it and thought it was serious, you could respond. You could ignore it. But why get outraged? For what? One guy’s opinion?What kind of life is it if we are to walk around all day with our happiness held hostage by people we’ve never met, just because they have a blog and they write about the things we use?
Or do we fear him? Is our manager going to read his list and say “Oh, what idiots we are to use Java here at BigCo, let’s switch to Ruby?” Are we worried that Obie is spreading lies and disinformation that will somehow get us tossed from our cushy jobs? Do we have to get the facts out this very instant before his heresies infect the world?
I didn’t think so.
So, my message to everyone, whether you love Ruby, or Java, or both, or neither, is simple:
Peace and Love.
Thursday, September 27, 2007
Off topic: my new gig
Those of you who care already know that I have accepted a position with Mobile Commons in NYC. I have never felt the need to say, “I don’t speak for my employer” before, but today you can find out all about what we do in The New York Times. And as far as hot-button topics go, these are the the big red ones. Life. Liberty. And the Freedom to Advocate for Change. So...
I do not speak for my employer.
But personally, one of the major reasons I accepted this position was the opportunity to help people try to change the world. Whether I agree or disagree with what they are trying to change, I want my children to grow up in a world where people can make a difference.
This is going to be interesting.
I do not speak for my employer.
But personally, one of the major reasons I accepted this position was the opportunity to help people try to change the world. Whether I agree or disagree with what they are trying to change, I want my children to grow up in a world where people can make a difference.
This is going to be interesting.
Java is the right answer to the wrong question, Ruby is the wrong answer to the right question
Can we please stop calling each other silly names over the languages we choose and move on to calling each other silly names over our choices for writing literate programs, eliminating redundancy, decoupling modules from each other, and so forth?
The very next time you find yourself being drawn into a debate about Java vs. Ruby, try saying something obscure, such as, Java is the right answer to the wrong question, Ruby is the wrong answer to the right question and see if you can redirect the energy towards exploring new ground instead of stagnating in the same old tired place.
When we argue Java vs. Ruby, or testing vs. type checking, we are arguing about foot steps. Take the debate to the next level. What is it we are trying to accomplish with those features? What are we seeking?
My favourite example of this is the subject of automatic refactoring
. My current text editor doesn’t perform automatic refactoring (ducks). Are you about to blast a flaming comment or perhaps an entire blog post explaining what a dunderhead I am for not using an IDE that can move a method with a single dialog box?
Stop for a moment. Why do we move methods? What are we trying to accomplish? What is it about our code after we have refactored that makes the code better? Now you have a really juicy comment to make, a deep and insightful point of view to bring to a discussion. Let’s talk about that quality of good code first, and then we can talk about how to get there later, if ever.
So the next time you read that “Strong, static typing is superior because it enables the IDE to provide automatic refactoring support,” take a deep breath. Don’t nod and agree. Don’t shake your head and disagree. Ask a polite question: What are we trying to accomplish with automatic refactoring? And when told that “Unit tests are superior to compiler type checking for catching bugs,” don’t settle for “catching bugs” as axiomatic. Ask what quality really means for code.
Nothing is going to save us from talking ourselves to death. But at least we can debate at a higher level of abstraction.
Large code bases are the problem, not the language they’re written in. Find a way to break/decompose big code bases into little ones.
Bill de hÓra, calming a heated debate
Can we please stop calling each other silly names over the languages we choose and move on to calling each other silly names over our choices for writing literate programs, eliminating redundancy, decoupling modules from each other, and so forth?
The very next time you find yourself being drawn into a debate about Java vs. Ruby, try saying something obscure, such as, Java is the right answer to the wrong question, Ruby is the wrong answer to the right question and see if you can redirect the energy towards exploring new ground instead of stagnating in the same old tired place.
Do not follow in the foot steps of the Sages. Seek what they sought.
When we argue Java vs. Ruby, or testing vs. type checking, we are arguing about foot steps. Take the debate to the next level. What is it we are trying to accomplish with those features? What are we seeking?
My favourite example of this is the subject of automatic refactoring
. My current text editor doesn’t perform automatic refactoring (ducks). Are you about to blast a flaming comment or perhaps an entire blog post explaining what a dunderhead I am for not using an IDE that can move a method with a single dialog box?Stop for a moment. Why do we move methods? What are we trying to accomplish? What is it about our code after we have refactored that makes the code better? Now you have a really juicy comment to make, a deep and insightful point of view to bring to a discussion. Let’s talk about that quality of good code first, and then we can talk about how to get there later, if ever.
So the next time you read that “Strong, static typing is superior because it enables the IDE to provide automatic refactoring support,” take a deep breath. Don’t nod and agree. Don’t shake your head and disagree. Ask a polite question: What are we trying to accomplish with automatic refactoring? And when told that “Unit tests are superior to compiler type checking for catching bugs,” don’t settle for “catching bugs” as axiomatic. Ask what quality really means for code.
Nothing is going to save us from talking ourselves to death. But at least we can debate at a higher level of abstraction.
Labels: ruby
Tuesday, September 25, 2007
Dear valued client
Dear valued client:
Thank you for your recent letter advising me that henceforth you would pay all invoices in US Dollars instead of Canadian Dollars.
This brings back happy memories of 1974, although I wouldn’t dwell on it: as Richard Nixon remarked a few months before resigning, “One year of Watergate is enough.” Hank Aaron broke The Babe’s home run record, India joined the Nuclear Weapons club, and Ali’s rope-a-dope secured him the win in the “Rumble in the Jungle.”
And oh yes, the US Dollar was lower than the Canadian Dollar. Well, as long as we’re going in that direction, please adjust your invoice spreadsheet to pay me $77.1 an hour for 850 hours a year. I’m sure you agree that’s only $65,535, so think of the savings!
Yours very truly,
raganwald
Thank you for your recent letter advising me that henceforth you would pay all invoices in US Dollars instead of Canadian Dollars.
This brings back happy memories of 1974, although I wouldn’t dwell on it: as Richard Nixon remarked a few months before resigning, “One year of Watergate is enough.” Hank Aaron broke The Babe’s home run record, India joined the Nuclear Weapons club, and Ali’s rope-a-dope secured him the win in the “Rumble in the Jungle.”
And oh yes, the US Dollar was lower than the Canadian Dollar. Well, as long as we’re going in that direction, please adjust your invoice spreadsheet to pay me $77.1 an hour for 850 hours a year. I’m sure you agree that’s only $65,535, so think of the savings!
Yours very truly,
raganwald
Monday, September 24, 2007
Ockham's razor as it applies to the big rewrite
Oh dear, the latest nine days wonder seems shocking on the face of it. To quote the protagonist in the tale:
There has been a running flamestorm over this, mostly centered on whether Rails is or isn’t the perfect framework for web applications. In other words, there is a prevailing sentiment that this rewrite failed for technical reasons.
I have my own experience with project failure, and I can’t blame any of it for technical problems. This is because, in my experience, the technical problems in projects are not root causes, they are symptoms of people and management problems.
Amazingly, Chad Fowler identified six reasons that big rewrites of production systems fail. Given that opinions are like noses (everybody has one), what’s so amazing about Chad’s list? What’s amazing is that Chad wrote his list a year ago, and yet he thoroughly nailed Derek’s experience.
Expecting a plug for a book about the latest miracle cure for project failure blues? Nope, sometimes the technical whizzies blind us to basic, fundamental wisdom that is as true today as it was twenty or even forty years ago. Don’t believe the hype.
For a solid grounding on how to successfully develop software, start with The Mythical Man-Month: Essays on Software Engineering. It is one of the most important books ever written about developing software, from the small to the large. Read the book that spawned the expression, “There is no silver bullet.”
I’ll bring up his first reason, Software as Spec. Re-read the condensed story above. Note, with horror, that a Rails expert took two years to fail what Derek accomplished in just two months. Well, if Jeremy couldn’t do it, obviously Rails is seriously broken, a complete toy. But this is like a sleight-of-hand trick. The paragraphs tell two stories, and we are so focused on one, “Two years for Rails, two months for PHP,” that we ignore the prestidigitator’s other story:
Two years for Jeremy, two months for Derek.
This is a complex, production system. When writing any complex, production system, what is the number one biggest risk? No, not technical risk. Requirements risk. Jeremy tried to create a copy of an existing, messy production system. Sure, he had Derek pulling the strings and calling the shots. But this is no guarantee of success, especially in an environment with heavy integration with other messy, chaotic systems.
Communicating requirements is hard enough in a green field situation. It’s nearly impossible when dealing with a real, production piece of code. Jeremy had almost no chance if his goal was to duplicate the original system’s functionality based on Derek’s direction and even assistance.
Derek, on the other hand, wrote the original system. He knows it intimately. If there is some weird, bogus code in one corner, Derek remembers why it’s there, what obscure bug it fixes, or perhaps what bug in some other piece of software’s code it mediates. If something doesn’t need to be there any more, Derek knows it can be dropped and he knows why it ought to go.
Of course Derek succeeded where Jeremy failed. Having Jeremy performing the rewrite with Derek’s assistance created an insurmountable barrier for understanding. Even with Derek trying to assist, the very fact that they were rewriting in Rails created a double whammy: Derek knew the system but had to try to explain its subtleties to Jeremy. Jeremy knew Rails but had to try to explain its subtleties to Derek.
Derek’s two-month rewrite with the hindsight of implementing the system in the first place and then living through the first rewrite failure is easy to understand: one person knew both the system and the implementation technology intimately. No communication barrier. No requirements risk.
simplicity
So, was the problem choosing Rails? Or choosing to bring in an outsider to implement a technology the insider didn’t know intimately? This is a false dichotomy, of course. Failed projects may have many problems.
But when trying to simplify the situation and derive useful conclusions, my heuristic is to look for the simplest explanation, the one with the fewest moving parts. The technology explanation is very specific and with many dangling caveats. It only applies to projects involving rewrites from PHP to Rails, and even then only those projects that are messy and have legacy data models that aren’t particularly CRUD-dy.
The people explanation is much simpler. It explains what we observed here as well as what we observed in many other projects, and it does so with very few caveats and conditions.
My personal heuristic is to go with the simpler explanation that applies to the widest possible set of observations in the wild.
As several people have pointed out here and elsewhere, we are working with anecdotal evidence. And the plural of anecdote is not data. But we must soldier on in our industry. If we waited until we could rigorously “prove” anything about software development before forming conclusions, we wouldn’t have budged from toggling switches on front panels.
Back in January 2005, I announced on the O’Reilly blog that I was going to completely scrap over 100,000 lines of messy PHP code in my existing CD Baby (cdbaby.com) website, and rewrite the entire thing in Rails, from scratch. I hired one of the best Rails programmers in the world (Jeremy Kemper aka bitsweat), and we set off on this huge task with intensity…
Two years (!) later, after various setbacks, we were less than halfway done… I said fuckit, and we abandoned the Rails rewrite… Then in a mere TWO MONTHS, by myself, not even telling anyone I was doing this, using nothing but vi, and no frameworks, I rewrote CD Baby from scratch in PHP. Done! Launched! And it works amazingly well.
There has been a running flamestorm over this, mostly centered on whether Rails is or isn’t the perfect framework for web applications. In other words, there is a prevailing sentiment that this rewrite failed for technical reasons.
I have my own experience with project failure, and I can’t blame any of it for technical problems. This is because, in my experience, the technical problems in projects are not root causes, they are symptoms of people and management problems.
Amazingly, Chad Fowler identified six reasons that big rewrites of production systems fail. Given that opinions are like noses (everybody has one), what’s so amazing about Chad’s list? What’s amazing is that Chad wrote his list a year ago, and yet he thoroughly nailed Derek’s experience.
Expecting a plug for a book about the latest miracle cure for project failure blues? Nope, sometimes the technical whizzies blind us to basic, fundamental wisdom that is as true today as it was twenty or even forty years ago. Don’t believe the hype.
For a solid grounding on how to successfully develop software, start with The Mythical Man-Month: Essays on Software Engineering
. It is one of the most important books ever written about developing software, from the small to the large. Read the book that spawned the expression, “There is no silver bullet.”Two years for Jeremy, two months for Derek.
This is a complex, production system. When writing any complex, production system, what is the number one biggest risk? No, not technical risk. Requirements risk. Jeremy tried to create a copy of an existing, messy production system. Sure, he had Derek pulling the strings and calling the shots. But this is no guarantee of success, especially in an environment with heavy integration with other messy, chaotic systems.
Communicating requirements is hard enough in a green field situation. It’s nearly impossible when dealing with a real, production piece of code. Jeremy had almost no chance if his goal was to duplicate the original system’s functionality based on Derek’s direction and even assistance.
Derek, on the other hand, wrote the original system. He knows it intimately. If there is some weird, bogus code in one corner, Derek remembers why it’s there, what obscure bug it fixes, or perhaps what bug in some other piece of software’s code it mediates. If something doesn’t need to be there any more, Derek knows it can be dropped and he knows why it ought to go.
Of course Derek succeeded where Jeremy failed. Having Jeremy performing the rewrite with Derek’s assistance created an insurmountable barrier for understanding. Even with Derek trying to assist, the very fact that they were rewriting in Rails created a double whammy: Derek knew the system but had to try to explain its subtleties to Jeremy. Jeremy knew Rails but had to try to explain its subtleties to Derek.
Derek’s two-month rewrite with the hindsight of implementing the system in the first place and then living through the first rewrite failure is easy to understand: one person knew both the system and the implementation technology intimately. No communication barrier. No requirements risk.
If there is one lesson to draw here it is that “There is always more than one way to look at any issue.”
simplicity
So, was the problem choosing Rails? Or choosing to bring in an outsider to implement a technology the insider didn’t know intimately? This is a false dichotomy, of course. Failed projects may have many problems.
But when trying to simplify the situation and derive useful conclusions, my heuristic is to look for the simplest explanation, the one with the fewest moving parts. The technology explanation is very specific and with many dangling caveats. It only applies to projects involving rewrites from PHP to Rails, and even then only those projects that are messy and have legacy data models that aren’t particularly CRUD-dy.
The people explanation is much simpler. It explains what we observed here as well as what we observed in many other projects, and it does so with very few caveats and conditions.
My personal heuristic is to go with the simpler explanation that applies to the widest possible set of observations in the wild.
As several people have pointed out here and elsewhere, we are working with anecdotal evidence. And the plural of anecdote is not data. But we must soldier on in our industry. If we waited until we could rigorously “prove” anything about software development before forming conclusions, we wouldn’t have budged from toggling switches on front panels.
Thursday, September 20, 2007
You suck
There’s a childish thing bloggers do. They get angry about something that pisses them off, and they vent. They know, deep in their hearts, that whining about stuff when they could be out there making positive change is not constructive. And they especially know that lashing out in public is not constructive criticism, it’s just throwing a digital temper tantrum.
But the primitive, reptilian part of their brain—the one that was in charge when they were two years old—takes control of the keyboard and off they go. After a few paragraphs of pointing out how arrogant Apple has become, or how much Vista sucks tbng qvpx, they calm down and realize how childish the post is.
But do they round file their post? No, in a fit of hubris they try to dress it up in serious clothing by inserting a few absolutely ridiculous suggestions like “Use one field for entering a name,” or “Apple should license PlaysForSure.”
That way, they can pass their rant off as some kind of wise observation from someone who “gets it.” Well, I’m a dad with a two-year old, and believe me, I get the point of these posts. It’s just plain people pissed providing a paucity of pertinent points. They’re mad as hell, but you and I both know that they are going to take it some more.
None of this, of course, stops me from doing exactly the same thing. But a little self-awareness goes a long way: I’m not going to waste your time pretending to be a nice guy trying to help someone correct their mistakes, or suggest that I’m a smart guy who knows better, or even that I’m trying to share some knowledge with you so that you can be a better programmer.
Nope. This is just a rant. Unadulterated bile.
You suck
You suck. Yes, you, Mister Web Application Engineer or whatever puffery is printed on your business card in lieu of “Whipping Boy.” If I was in a good mood, I might say that you’re a fine human being, and it’s just your work that sucks. And that you can’t help it, there are deadlines and bad managers and clients who buy lemons and all sorts of excuse for the crap you ship. But I’m not in a good mood.
I’m not in a good mood because I should be in New York right now. Do you know why I’m not in New York right now? Because the company you work for—a travel agency—didn’t email me my e-ticket in time for me to get on my flight. Why not? Well, it seems I made the mistake of giving you a valid but unusual email address,
Now, we both know that it is very hard to validate email addresses properly. Had you thought it was invalid and not let me enter it on the web in the first place, you would still suck, but I would be telling you that you suck from NYC. But instead, you let me enter it. You even sent a confirmation email telling me that you were processing my order to that email address! But I guess you have different systems, with different logic, and the system that was supposed to actually send my e-ticket mangled things and emailed it to
Well, my situation sucks, but at least I don’t suck. You do. This email mangling isn’t a bug. It’s a place where you thought you knew what a valid email was, and you added extra code to block “invalid” characters. Had you simply schlepped strings around like they did in the days of COBOL, all would be well. But that wasn’t good enough for you, you had to actually burn your employer’s money making your software worse.
I’ve seen your work before. My legal surname for many years was “Braithwaite-Lee.” Note the hyphen. In your infinite wisdom, you have built many web systems that told me that “-” is an illegal character in a name field. You are an idiot, what makes you think you know anything at all about what kinds of characters people are going to want to put in their names?
A name is the most personal thing people are going to give you, and here you are “validating” it. I would point out the irony of a medium invented by Tim Berners-Lee rejecting surnames with hyphens, but I know for a fact you just got the job because you aren’t qualified to do anything else, so you have no knowledge whatsoever of our industry’s history.
I find this “validation” especially irritating when ordering something online and trying to pay with my credit card. What excuse, other than the fact that you suck, can you give for telling me that the name “REGINALD BRAITHWAITE-LEE” was an invalid credit card name, when that’s exactly what was printed on my credit card? I mean, besides the fact that you’re wrong, why were you trying to guess that someone else’s computer accepts or rejects? Just ask them, oaf. The bank will tell you if the name is invalid.
This is a basic tenet of your suckage. You are not lazy in any enlightened, useful way: you make work for yourself under the guise of making things easier or of strutting around your office bragging about the latest shiny enterprise bauble. Most of the problems you have to solve arose because you made choices that suck.
Your credit card name validation sucks. Why? because it tries to save a round trip to the bank when a customer mis-types what is written on their own credit card. Does it always do so? No, of course not, I can merrily put my name down as “STUPID OAF,” and you don’t care. Your little check just takes care of one corner case, gets it wrong, and encumbers your code with broken dreck, just like the email crapfest.
And that’s why you suck.
But the primitive, reptilian part of their brain—the one that was in charge when they were two years old—takes control of the keyboard and off they go. After a few paragraphs of pointing out how arrogant Apple has become, or how much Vista sucks tbng qvpx, they calm down and realize how childish the post is.
But do they round file their post? No, in a fit of hubris they try to dress it up in serious clothing by inserting a few absolutely ridiculous suggestions like “Use one field for entering a name,” or “Apple should license PlaysForSure.”
That way, they can pass their rant off as some kind of wise observation from someone who “gets it.” Well, I’m a dad with a two-year old, and believe me, I get the point of these posts. It’s just plain people pissed providing a paucity of pertinent points. They’re mad as hell, but you and I both know that they are going to take it some more.
None of this, of course, stops me from doing exactly the same thing. But a little self-awareness goes a long way: I’m not going to waste your time pretending to be a nice guy trying to help someone correct their mistakes, or suggest that I’m a smart guy who knows better, or even that I’m trying to share some knowledge with you so that you can be a better programmer.
Nope. This is just a rant. Unadulterated bile.
You suck
You suck. Yes, you, Mister Web Application Engineer or whatever puffery is printed on your business card in lieu of “Whipping Boy.” If I was in a good mood, I might say that you’re a fine human being, and it’s just your work that sucks. And that you can’t help it, there are deadlines and bad managers and clients who buy lemons and all sorts of excuse for the crap you ship. But I’m not in a good mood.
I’m not in a good mood because I should be in New York right now. Do you know why I’m not in New York right now? Because the company you work for—a travel agency—didn’t email me my e-ticket in time for me to get on my flight. Why not? Well, it seems I made the mistake of giving you a valid but unusual email address,
invective+travel@gmail.com, and your software did something stupid.Now, we both know that it is very hard to validate email addresses properly. Had you thought it was invalid and not let me enter it on the web in the first place, you would still suck, but I would be telling you that you suck from NYC. But instead, you let me enter it. You even sent a confirmation email telling me that you were processing my order to that email address! But I guess you have different systems, with different logic, and the system that was supposed to actually send my e-ticket mangled things and emailed it to
invectivetravel@gmail.com instead. No +. So nobody even knew anything was amiss! No error, nothing, just sending it to the wrong place. And it probably bounced, but you didn’t tell any of your customer service people, so nobody knew there was a problem until it was too late.Well, my situation sucks, but at least I don’t suck. You do. This email mangling isn’t a bug. It’s a place where you thought you knew what a valid email was, and you added extra code to block “invalid” characters. Had you simply schlepped strings around like they did in the days of COBOL, all would be well. But that wasn’t good enough for you, you had to actually burn your employer’s money making your software worse.
I’ve seen your work before. My legal surname for many years was “Braithwaite-Lee.” Note the hyphen. In your infinite wisdom, you have built many web systems that told me that “-” is an illegal character in a name field. You are an idiot, what makes you think you know anything at all about what kinds of characters people are going to want to put in their names?
A name is the most personal thing people are going to give you, and here you are “validating” it. I would point out the irony of a medium invented by Tim Berners-Lee rejecting surnames with hyphens, but I know for a fact you just got the job because you aren’t qualified to do anything else, so you have no knowledge whatsoever of our industry’s history.
I find this “validation” especially irritating when ordering something online and trying to pay with my credit card. What excuse, other than the fact that you suck, can you give for telling me that the name “REGINALD BRAITHWAITE-LEE” was an invalid credit card name, when that’s exactly what was printed on my credit card? I mean, besides the fact that you’re wrong, why were you trying to guess that someone else’s computer accepts or rejects? Just ask them, oaf. The bank will tell you if the name is invalid.
This is a basic tenet of your suckage. You are not lazy in any enlightened, useful way: you make work for yourself under the guise of making things easier or of strutting around your office bragging about the latest shiny enterprise bauble. Most of the problems you have to solve arose because you made choices that suck.
Your credit card name validation sucks. Why? because it tries to save a round trip to the bank when a customer mis-types what is written on their own credit card. Does it always do so? No, of course not, I can merrily put my name down as “STUPID OAF,” and you don’t care. Your little check just takes care of one corner case, gets it wrong, and encumbers your code with broken dreck, just like the email crapfest.
And that’s why you suck.
Eloquently Said
I can see Apple saying, “Well, you see, the record companies would have been upset with us if we hadn’t charged anything for ringtones.” Yah, well, that’s the price you get for engaging. The price for owning the distribution of the content and the hardware and the software is that you end up making compromises in the hardware and software in order to protect the content.—Will Shipley
These are EXACTLY the compromises Sony has been making for years — and because Sony’s music and movie arms have been telling the Sony hardware arm to never do anything new or interesting without building in a ton of customer-unfriendly restrictions, Sony is now completely in the toilet. They have gone from an incredibly respected brand to a complete joke. Every time they introduce some new, crippled standard the industry kind of looks away in embarrassment, like Sony is the oafish guy at the party who is parked in front of the meatballs tray eating directly from the dish.
The rumour flew around that something new was in the works combining all the power of Daddy and all the elegance of Mummy. We couldn’t wait. This will be the Big One, we thought, the justification and apotheosis of UIQ.—Stephen Fry (yes, “Jeeves”)
Mine arrived at the beginning of this week. What a crushing, lowering, fury-inducing disappointment. Just how dumb are the software engineers, designers and marketeers at Sony E? Believe me, I so wanted this to be good. Instead, it is nothing more than a gesture, an under-considered, badly implemented nod at the market.
It’s an M600i running Symbian v 9.1 and UIQ v 3.0 equipped with a camera and WiFi.. That’s it. No attempt has been made to alter the UI or the OS. The result: the clumsiest, most asinine method of internet connection ever devised (yes it has a wizard to download your network’s APN etc., but that’s not enough) comes unaltered, the bugginess and the slowness too have all have been inherited, and the short battery life.
Did they really think slinging on a 3.2MP camera and WiFi would make a desirable device, let alone an iPhone killer? I could issue forth quires of intemperate fury on the subject of how bad internet account configuration is on the UIQ Sony Ericssons. It’s utterly pointless.
Is there not one person at either Sony E or Symbian who themselves uses the phone and says “hang on, we could do this better”? That’s all it takes. Just one person to point at the Emperor and shout “nudie!” That’s why Apple is Apple, they have people there (and of course it comes from the top) who say - “woah, not good enough, not cool enough, not simple enough, not fun enough, not sexy enough, not clever enough, not useful enough”.
The P1i is what happens when “oh, that’ll do” becomes the corporate motto.
As for the notion expressed by some commenters that kids could never figure this thing [OLPC] out, and would never be able to figure out how to code software… um? What world do you live in? The one where young people are the last to figure out a new technology? The one in which grandpa has to show little Bobby how to program the VCR? The one in which only grownups are texting each other on their cell phones and building Facebook apps? Children love computers, in no small part because they love learning.—Michael Harrison
Java has a compiler. Ruby does not. That's great! Fuck compilers and their false sense of security. Too often is bad code checked in or even deployed to production, simply because it compiled. No such luxury in the Ruby world.—Obie Fernandez
Sunday, September 16, 2007
Breaking News: Write a Ruby function. Win a $100 Bounty!
I just spotted this on the Toronto Ruby on Rails mailing list:
/me thinks it’s too quiet here. Time for a Sunday afternoon ruby
challenge!
$100 for the best implementation, good until 6pm tonight (September 16, 2007).
THE PROBLEM
Marcel’s Amazon S3 gem presents files stored in a bucket as an object
which exposes a key attribute that conceptually map to the idea of a
file in a filesystem. You can fake a folder hierarchy by uploading 0
byte files with a key ending in a / (eg. folder1/ )
The Ruby Way is the perfect second Ruby book for serious programmers. The Ruby Way contains more than four hundred examples explaining how to do everything from distribute Ruby with Rinda to dynamic programming techniques just like these.
Your mission is to convert the objects array of an S3 bucket to a
Hash, so that we can present a tree view to the user. It should
support an arbitrary depth, and make good use of Ruby best practices.
THE TEST DATA
Let’s assume you have a bunch of items in a bucket, and if you iterate
through the item keys, you’ll get this list:
This covers all cases; a hierarchy of files in folders, including
files in the root and empty folders.
THE SOLUTION
In other words, for each item in the hash, the name is the key without
any preceding path, and the value is the AWS::S3::S3Object that the
key points to. (I just pasted the same object in the example.)
And… go!
Pete Forde, unspace.ca
Do you want to win the $100? Pete told me that your solution is eligible to win provided you post it to the TorROR mailing list by 6PM, September 16th, 2007 (EST). For more details, see the TorROR Google Group.
/me thinks it’s too quiet here. Time for a Sunday afternoon ruby
challenge!
$100 for the best implementation, good until 6pm tonight (September 16, 2007).
THE PROBLEM
Marcel’s Amazon S3 gem presents files stored in a bucket as an object
which exposes a key attribute that conceptually map to the idea of a
file in a filesystem. You can fake a folder hierarchy by uploading 0
byte files with a key ending in a / (eg. folder1/ )
The Ruby Way
is the perfect second Ruby book for serious programmers. The Ruby Way contains more than four hundred examples explaining how to do everything from distribute Ruby with Rinda to dynamic programming techniques just like these.Hash, so that we can present a tree view to the user. It should
support an arbitrary depth, and make good use of Ruby best practices.
THE TEST DATA
Let’s assume you have a bunch of items in a bucket, and if you iterate
through the item keys, you’ll get this list:
folder1/
folder2/
folder2/folder4/
folder2/folder5/
folder2/folder5/temp6.txt
folder2/temp3.txt
folder2/temp4.txt
folder2/temp5.txt
folder3/
folder3/temp7.txt
temp1.txt
temp2.txt
This covers all cases; a hierarchy of files in folders, including
files in the root and empty folders.
THE SOLUTION
results = {
"temp1.txt" => #<AWS::S3::S3Object:0x31ab7bc>,
"temp2.txt" => #<AWS::S3::S3Object:0x31ab7bc>,
"folder1" => {},
"folder2" => {
"temp3.txt" => #<AWS::S3::S3Object:0x31ab7bc>,
"temp4.txt" => #<AWS::S3::S3Object:0x31ab7bc>,
"temp5.txt" => #<AWS::S3::S3Object:0x31ab7bc>,
"folder4" => {},
"folder5" => {
"temp6.txt" => #<AWS::S3::S3Object:0x31ab7bc>
},
},
"folder3" => {
"temp7.txt" => #<AWS::S3::S3Object:0x31ab7bc>
}
}
In other words, for each item in the hash, the name is the key without
any preceding path, and the value is the AWS::S3::S3Object that the
key points to. (I just pasted the same object in the example.)
And… go!
Pete Forde, unspace.ca
Do you want to win the $100? Pete told me that your solution is eligible to win provided you post it to the TorROR mailing list by 6PM, September 16th, 2007 (EST). For more details, see the TorROR Google Group.
Labels: ruby
Thursday, September 13, 2007
Code/data separation and Encapsulation are diametrically opposed ideas
Think about this, hard, the next time you are considering the virtues of putting everything in a Relational Database. Code/data separation means that the applications of the future can operate on the data of today. Fine.
But then you decide that all applications should access the database through stored procedures, encapsulating the data schema. You just reversed yourself, you might as well have built middleware in a real programming language and exposed the data through web servcies or REST.
Either approach is fine. But just recognize that separating code and data works towards the goal of reusability in a manner that is diametrically opposed to building an encapsulation layer.
In fact, if you insist on code/data separation and you’re an advocate of OOP, then you’re talking out of both sides of your mouth. If your gut reaction to having log entries know how to transform or process themselves is “woah, that’s just wrong”, think again: you’re imposing a world-view on the problem that’s not consistent with your notions of data encapsulation and active objects.
Think about this, hard, the next time you are considering the virtues of putting everything in a Relational Database. Code/data separation means that the applications of the future can operate on the data of today. Fine.
But then you decide that all applications should access the database through stored procedures, encapsulating the data schema. You just reversed yourself, you might as well have built middleware in a real programming language and exposed the data through web servcies or REST.
Either approach is fine. But just recognize that separating code and data works towards the goal of reusability in a manner that is diametrically opposed to building an encapsulation layer.
Intellectual Property is a confusing term
I am careful not to use [the confusing term Intellectual Property] in my thoughts, because it does not refer to a coherent thing, although it misleadingly appears to. The term lumps together laws that raise totally different issues, as if they were one subject.
Copyrights exist, and I have opinions about copyright law. Patents also exist, but patent law is almost completely different from copyright law. My opinions about patent law are also completely different from my opinions about copyright law. Trademark law exists too and it has nothing at all in common with copyright law or patent law. If you want to think clearly about any of these laws, the first step is firmly insisting on treating them as three different subjects.
Wednesday, September 12, 2007
We have lost control of the apparatus
I am writing to you as a fellow programmer and software developer. I write in friendship and brotherhood. My heart is heavy, and the news I impart is not good: We have lost control of the apparatus.
I know, the IT department soldiers on grimly. They lost a great battle to the PCs more than twenty years ago, and it took years of struggle with NT Domain Controllers and web proxies before control could be wrestled back from the users. In some places I hear battles are still being waged over USB ports and Bluetooth. IT was lucky to find a new ally against the users in MSFT just when their ancient supporter IBM’s star was fading.
But we programmers have lost and we must be realistic about things. The fact of the matter is this: people own their own computers, and our applications are no longer the primary way they learn how computers ought to work.
I know, I know, they stare at our work for eight, ten, or twelve hours a day. So you would think that we would set the standard for how computers ought to be. But the Good Old Days when most of users had never seen a computer before work have gone. Some of our users, fresh out of school, have already been using computers for ten years!
As if that wasn’t enough, the really bad news is, when our users go home they have this thing called the Internet. I know, IT locked that down in the office. But we can’t stop them from getting on it at home, on their mobiles, and now even on those insidious Apple iPods
! And when people use the Internet, they are actually using other people’s applications.
I’m not kidding. Our users are being exposed to applications we don’t control. And it messes things up. You see, the users get exposed to other ways of doing things, ways that are more convenient for users, ways that make them more productive, and they incorrectly think we ought to do things that way for them.
computers
This business of users buying their own computers is really troublesome. For one thing, they can buy a computer in the store for a few hundred dollars that is twice as good as the warmed-up left-over IT put on their desk. Until recently, we could shrug our shoulders. We weren’t the ones that had to explain that to get an up-to-date model, they needed to fill out a twenty-seven-b-stroke-six. Which needed approval. Against budget. And then IT would order it from DELL. Who don’t have the CPUs in stock.
Blatant plug: Pre-order your Apple 16 GB iPod Touch with this affiliate link. You’ll get the most revolutionary device ever made and you’ll support ragawald, a worthy a pretty-good ok, a drivellous weblog but at least it’s entertaining. Please. And thank you, I really do appreciate the clicks!
And meanwhile, the very same users could walk across the street and buy themselves a much better PC for less money than we pay and take it home the same day. And until now, we didn’t worry about it. We’re the programmers.
But now it’s a problem. Here’s the thing: those PCs they buy at home? The ones that are two, three, or even five times better than the ones on their desk? With huge drives, and lots of memory? The thing is, they run much richer applications than the warmed-over TTY stuff we’ve been feeding them under the guise of “being hip to the Internet revolution.”
For example, my Mother uses Skype to talk to her friends. She thinks it’s normal to see all of your voice mail messages in a list on the screen. If I tried to give her a CRM application for managing contacts, the very first question she would ask would be, “Why can’t I listen to all of the voice mails from that contact in the application?”
Do you think she would have patience for my explanation that the company’s phone systems are complex and proprietary and that we can’t install Asterix just for her? She would grab me by the ear and drag me to my desk to get cracking on it!
You laugh, but users are used to a lot more functionality than a web page with a form on it these days, and if we don’t give it to them, the noise from all the whining is going to drive us insane.
Here’s another thing. How many monitors do your users have? One, right? There’s no point in giving them more, because we build our applications with session management that basically goes insane if they try to open two windows at once, right? Well guess what? Users have multiple monitors at home for games, and they want them at work.
And when they have them at work and you explain that no, they can’t be in the middle of doing something for XYZCorp in one window, and open a new window when a call comes in from ABCLimited, because that screws up the session, they are going to bitch and moan, because they can do two things at once in their mail application and their social network and their game. Sucks to be us.
And don’t get me started about had drives. Would you believe that users now expect—as if anyone gave them permission to have expectations—what was I saying? Oh yes, users now expect that we should store everything and anything. That’s right, they think we should be able to handle arbitrarily large text fields, with styling, and pictures, and even sound or video, all stashed away where they can find it again. They want to be able to store everything to do with an account or a customer or a project or whatever right in our applications.
I tried telling them that databases were not designed for multi-megabyte Word files and PowerPoint presentations, and they just goggle at me like I’m a circus freak and ask me why I’m using a database if it doesn’t do what they want for them? I try to tell them that we don’t have a budget for buying bigger drives, and the poor, deluded fools pull out their credit cards and offer to buy a terabyte drive over the Internet for less money than our vendors charge us per phone call.
I tell you, users refuse to sit and be trained like puppies. And the bottom line is this: we can’t keep putting HTML lipstick on a 1960s pig forever. We have to get out of the office and look at what a modern PC looks like—drive, speed, RAM, monitors, everything—and write applications that can take advantage of it.
fields
You know how all of our applications have a
Please, stop laughing. I had the same reaction. How could that possibly work? But the rogues who build that kind of heresy put in a lot of clever little rules and things so that the single field can handle case like
When I told one of our users, a business analyst, that using just one field for the name meant a huge amount of work for programmers, she actually asked me what our job was, if not to do the work that makes users productive. I’m very much afraid that things are out of hand. I tried to explain how our database schema works, and so on, but she impatiently insisted that it was our job to make things work.
She then started lecturing me—lecturing ME!—about copy and paste, of all things. She said that it should be convenient to copy and paste between our application and other applications like Word, Excel, and even Outlook. With separate fields, you need to do multiple steps to copy a name between our applications and a letter.
I felt betrayed by Microsoft. Whatever happened to the days when people used just one application, and if they needed another we would give them an export routine? Now she wants to be able to copy a name out of an email and paste it into our application without carefully selecting the last name, first name, and honorific separately.
When I left her office, she was mumbling something about SaaS or some such. I don’t remember what she meant, but “sass” just about sums up her attitude.
If she was just one lone uppity user, I could handle it. But they’re popping up like toadstools. Just the other day another user was asking why he couldn’t paste an address as one field, including zip code. I told him I didn’t have time to explain how database columns worked, but again he muttered something disrespectful and later I saw him hefting his swingline rather menacingly while looking at our application on his screen.
Brothers and sisters, I know this is hard to take, but we’re losing this war. Our DBA cousins have brainwashed Corporate into believing that they are the custodians of the data, and of the sacred Stored Procedure that Controlleth Access. We have very little choice about how things work.
But still, the users expect us to make applications every bit as useful for them as the applications they use on the Internet, and I fear that they will rise up and revolt very soon if we don’t find a way to make the database invisible and make user applications conform to these horribly user-centric heresies.
I know, I see the pitchforks in your hands, and your desire to maul, hang, and burn the messenger is understandable. But that won’t fix things, so please put them down, ok?
stories
And don’t give me that “User Stories” flim-flam, please. I practically invented bamboozling users into doing what we want by pretending to put them in charge of an Agile Process. Agile Process indeed, anybody ought to know that if it’s a Process, it sure as heck can’t be Agile.
So you think you can do what we’ve always done, hunh? When they complain about copy and paste, write it up as a story, put it in the backlog, and then—look at that—there’s always a higher priority story to do. There’s always some new functionality that offers a greater ROI than polishing an old feature.
Well, sister, where that goes wrong is that this isn’t polish: it’s what our users expect as basic functionality. You might think it is new and improved and doesn’t add value, but what our users think is that our applications are old and broken and waste their time.
So while on paper a new feature is more important than making paste work, in practice it looks like we build software that slows the organization down.
So save your breath and stop using Agile as an excuse for slapping the crudest crap together and putting fast in front of finished.
search
You would things couldn’t get any worse. But they are worse, much worse. I’ll just say one word. Google. Those bastards are practically the home page of the Internet. Which means, to a close approximation, they are the most popular application in the world.
The authors of Prototype and Scriptaculous in Action are the people who brought you the incredible Prototype and script.aculo.us Javascript libraries. This book explains how to use them to build reusable, literate Javascript, how to build dynamic, Web 2.0 applications, and best of all, how to write web applications without tearing your hair out in frustration with Javascript.
With this book and these libraries, you’ll learn how to write better Javascript in a Lisp-like functional style, and as a bonus you’ll also learn how to write better Javascript in a conventional OO style.
And what have they taught our users? Full-text search wins. Please, don’t lecture me, we had this discussion way back when we talked about fields. Users know how to use Google. If you give them a search page with a field for searching the account number and a field for searching the SSN and a field for searching the zip code and a field for searching the phone number, they want to know why they can’t just type
I have tried explaining that there’s an ambiguity if an account number is also
They don’t even get that search results should always show stuff from the same table. Would you believe, if they type a phone number, they want us to search
We can use tools like Nutch and what-not for full-text search. But users want to search everything, everywhere, just like Google. And try as we might to get them to use Sharepoint, they just deride it as a heap of junk. We are going to wind up ceding control of our data to Google sooner or later. I hate to be the one to tell you this, but you might as well hear it from a friend:
You need to start coding your applications so that an external search engine can search them. That’s right, you need to work with a desktop search tool and a network search tool so that people can type
It’s the future. A miserable, groveling future where our applications work for the users instead of the users working for our applications, but it’s our future.
Suck it up and roll with it.
Psst! Are you Smart? Do you Get Things Done? Do you want to work in New York City using Rails and Java? Mobile Commons is hiring developers!
I know, the IT department soldiers on grimly. They lost a great battle to the PCs more than twenty years ago, and it took years of struggle with NT Domain Controllers and web proxies before control could be wrestled back from the users. In some places I hear battles are still being waged over USB ports and Bluetooth. IT was lucky to find a new ally against the users in MSFT just when their ancient supporter IBM’s star was fading.
We’ve taken care of everything
The words you hear the songs you sing
The pictures that give pleasure to your eyes
It’s one for all and all for one
We work together common sons
Never need to wonder how or why
But we programmers have lost and we must be realistic about things. The fact of the matter is this: people own their own computers, and our applications are no longer the primary way they learn how computers ought to work.
I know, I know, they stare at our work for eight, ten, or twelve hours a day. So you would think that we would set the standard for how computers ought to be. But the Good Old Days when most of users had never seen a computer before work have gone. Some of our users, fresh out of school, have already been using computers for ten years!
As if that wasn’t enough, the really bad news is, when our users go home they have this thing called the Internet. I know, IT locked that down in the office. But we can’t stop them from getting on it at home, on their mobiles, and now even on those insidious Apple iPods
! And when people use the Internet, they are actually using other people’s applications.I’m not kidding. Our users are being exposed to applications we don’t control. And it messes things up. You see, the users get exposed to other ways of doing things, ways that are more convenient for users, ways that make them more productive, and they incorrectly think we ought to do things that way for them.
computers
This business of users buying their own computers is really troublesome. For one thing, they can buy a computer in the store for a few hundred dollars that is twice as good as the warmed-up left-over IT put on their desk. Until recently, we could shrug our shoulders. We weren’t the ones that had to explain that to get an up-to-date model, they needed to fill out a twenty-seven-b-stroke-six. Which needed approval. Against budget. And then IT would order it from DELL. Who don’t have the CPUs in stock.
Blatant plug: Pre-order your Apple 16 GB iPod Touch
with this affiliate link. You’ll get the most revolutionary device ever made and you’ll support ragawald, But now it’s a problem. Here’s the thing: those PCs they buy at home? The ones that are two, three, or even five times better than the ones on their desk? With huge drives, and lots of memory? The thing is, they run much richer applications than the warmed-over TTY stuff we’ve been feeding them under the guise of “being hip to the Internet revolution.”
For example, my Mother uses Skype to talk to her friends. She thinks it’s normal to see all of your voice mail messages in a list on the screen. If I tried to give her a CRM application for managing contacts, the very first question she would ask would be, “Why can’t I listen to all of the voice mails from that contact in the application?”
Do you think she would have patience for my explanation that the company’s phone systems are complex and proprietary and that we can’t install Asterix just for her? She would grab me by the ear and drag me to my desk to get cracking on it!
You laugh, but users are used to a lot more functionality than a web page with a form on it these days, and if we don’t give it to them, the noise from all the whining is going to drive us insane.
I tried telling them that databases were not designed for multi-megabyte Word files and PowerPoint presentations, and they just goggle at me like I’m a circus freak and ask me why I’m using a database if it doesn’t do what they want for them?
Here’s another thing. How many monitors do your users have? One, right? There’s no point in giving them more, because we build our applications with session management that basically goes insane if they try to open two windows at once, right? Well guess what? Users have multiple monitors at home for games, and they want them at work.
And when they have them at work and you explain that no, they can’t be in the middle of doing something for XYZCorp in one window, and open a new window when a call comes in from ABCLimited, because that screws up the session, they are going to bitch and moan, because they can do two things at once in their mail application and their social network and their game. Sucks to be us.
And don’t get me started about had drives. Would you believe that users now expect—as if anyone gave them permission to have expectations—what was I saying? Oh yes, users now expect that we should store everything and anything. That’s right, they think we should be able to handle arbitrarily large text fields, with styling, and pictures, and even sound or video, all stashed away where they can find it again. They want to be able to store everything to do with an account or a customer or a project or whatever right in our applications.
I tried telling them that databases were not designed for multi-megabyte Word files and PowerPoint presentations, and they just goggle at me like I’m a circus freak and ask me why I’m using a database if it doesn’t do what they want for them? I try to tell them that we don’t have a budget for buying bigger drives, and the poor, deluded fools pull out their credit cards and offer to buy a terabyte drive over the Internet for less money than our vendors charge us per phone call.
I tell you, users refuse to sit and be trained like puppies. And the bottom line is this: we can’t keep putting HTML lipstick on a 1960s pig forever. We have to get out of the office and look at what a modern PC looks like—drive, speed, RAM, monitors, everything—and write applications that can take advantage of it.
fields
You know how all of our applications have a
first-name and a last-name? This has worked for decades, you would think people would understand the value of standards, of consistency. But out there in the Internet, where there is no Adult Supervision, some of those applications have just one field for a name. You put spaces in it to separate first and last, just like writing a letter, I guess.When I told one of our users, a business analyst, that using just one field for the name meant a huge amount of work for programmers, she actually asked me what our job was, if not to do the work that makes users productive.
Please, stop laughing. I had the same reaction. How could that possibly work? But the rogues who build that kind of heresy put in a lot of clever little rules and things so that the single field can handle case like
Braithwaite, Reginald or Geroge Smithers, Esq. or even Doctor Wu properly.When I told one of our users, a business analyst, that using just one field for the name meant a huge amount of work for programmers, she actually asked me what our job was, if not to do the work that makes users productive. I’m very much afraid that things are out of hand. I tried to explain how our database schema works, and so on, but she impatiently insisted that it was our job to make things work.
She then started lecturing me—lecturing ME!—about copy and paste, of all things. She said that it should be convenient to copy and paste between our application and other applications like Word, Excel, and even Outlook. With separate fields, you need to do multiple steps to copy a name between our applications and a letter.
I felt betrayed by Microsoft. Whatever happened to the days when people used just one application, and if they needed another we would give them an export routine? Now she wants to be able to copy a name out of an email and paste it into our application without carefully selecting the last name, first name, and honorific separately.
When I left her office, she was mumbling something about SaaS or some such. I don’t remember what she meant, but “sass” just about sums up her attitude.
If she was just one lone uppity user, I could handle it. But they’re popping up like toadstools. Just the other day another user was asking why he couldn’t paste an address as one field, including zip code. I told him I didn’t have time to explain how database columns worked, but again he muttered something disrespectful and later I saw him hefting his swingline rather menacingly while looking at our application on his screen.
Brothers and sisters, I know this is hard to take, but we’re losing this war. Our DBA cousins have brainwashed Corporate into believing that they are the custodians of the data, and of the sacred Stored Procedure that Controlleth Access. We have very little choice about how things work.
But still, the users expect us to make applications every bit as useful for them as the applications they use on the Internet, and I fear that they will rise up and revolt very soon if we don’t find a way to make the database invisible and make user applications conform to these horribly user-centric heresies.
I know, I see the pitchforks in your hands, and your desire to maul, hang, and burn the messenger is understandable. But that won’t fix things, so please put them down, ok?
stories
And don’t give me that “User Stories” flim-flam, please. I practically invented bamboozling users into doing what we want by pretending to put them in charge of an Agile Process. Agile Process indeed, anybody ought to know that if it’s a Process, it sure as heck can’t be Agile.
So you think you can do what we’ve always done, hunh? When they complain about copy and paste, write it up as a story, put it in the backlog, and then—look at that—there’s always a higher priority story to do. There’s always some new functionality that offers a greater ROI than polishing an old feature.
Well, sister, where that goes wrong is that this isn’t polish: it’s what our users expect as basic functionality. You might think it is new and improved and doesn’t add value, but what our users think is that our applications are old and broken and waste their time.
So while on paper a new feature is more important than making paste work, in practice it looks like we build software that slows the organization down.
So save your breath and stop using Agile as an excuse for slapping the crudest crap together and putting fast in front of finished.
search
You would things couldn’t get any worse. But they are worse, much worse. I’ll just say one word. Google. Those bastards are practically the home page of the Internet. Which means, to a close approximation, they are the most popular application in the world.
The authors of Prototype and Scriptaculous in Action
are the people who brought you the incredible Prototype and script.aculo.us Javascript libraries. This book explains how to use them to build reusable, literate Javascript, how to build dynamic, Web 2.0 applications, and best of all, how to write web applications without tearing your hair out in frustration with Javascript.With this book and these libraries, you’ll learn how to write better Javascript in a Lisp-like functional style, and as a bonus you’ll also learn how to write better Javascript in a conventional OO style.
4165558734 and find Reg by phone number? (And right after we make that work for them, those greedy and ungrateful sods’ll want to type (416) 555-8734 and have it work too. Bastards.)I have tried explaining that there’s an ambiguity if an account number is also
4165558734. But those damn users just give me that “Boy, you are stupid” look that made Samuel Jackson famous. They think we should just show them what we find and let them sort it out. They’re idiots, obviously, but they’re our idiots and I’m pretty sure that if we fire them all we’ll have to clean our own desks out the following day.They don’t even get that search results should always show stuff from the same table. Would you believe, if they type a phone number, they want us to search
companies and persons. They have no respect for our careful husbanding of hardware resources. The profligate spendthrifts think that just because they have a two gigahertz PC at home that can search their entire hard drive for a phone number as fast as they can type it—thanks again, Google—we should make search as fast and as easy to use in our applications.We can use tools like Nutch and what-not for full-text search. But users want to search everything, everywhere, just like Google. And try as we might to get them to use Sharepoint, they just deride it as a heap of junk. We are going to wind up ceding control of our data to Google sooner or later. I hate to be the one to tell you this, but you might as well hear it from a friend:
You need to start coding your applications so that an external search engine can search them. That’s right, you need to work with a desktop search tool and a network search tool so that people can type
4165558734 and see everything, mail, word docs, and records in your database, in one place.It’s the future. A miserable, groveling future where our applications work for the users instead of the users working for our applications, but it’s our future.
Suck it up and roll with it.
Psst! Are you Smart? Do you Get Things Done? Do you want to work in New York City using Rails and Java? Mobile Commons is hiring developers!
Labels: popular
Thursday, September 06, 2007
Pro Forma
Assaf pointed me to Microsoft touts cost savings of Vista over XP, an article wherein InfoWorld reveals the secret of MSFT’s ability to sell into the Enterprise: their deep knowledge of how to calculate corporate finance quantities like Cost of Ownership and Return on Investment:
This is why I do not want to work for The Borg or their minions. Why bother actually making software that will save people money when you can go ahead and make up whatever savings you need to close the deal? Instead, I prefer to work for companies that are forced to actually make stuff people can use. Companies that have to compete on value. Such companies often have to make hard choices about what to ship, by when. But they rarely have the luxury of shipping complete dog- aw, you finish the sentence.
This is my “bottom line,” as they say in Finance. Different companies have different strategies for success. The important thing is to make sure that the things you value in your career and business are aligned with the strategies your employers, partners, and/or customers pursue.
When they aren’t, you do not have a fit and need to reëvaluate your participation. But should you be fortunate enough to work with people whose strategies depend heavily on your values, you are going to be happy.
Pax, and I thank The Borg for yet another lesson in life’s little truths.
Peculiarly, the study actually was based on XP usage and extrapolations based on Vista capabilities because there was not a substantial base of Vista clients in use yet when the study was done early in 2007.In summary, they paid someone to do a quickie telephone survey, then report how much money people might theoretically save if they theoretically switched from XP to Vista, and simultaneously switched from whatever they were doing at that time to the theoretical “Vista best practices.” Instead of—how quaint—actually measuring how much money people did or did not save. So without any control groups or study parameters or other bothersome restrictions on what they could print, the survey company just made the numbers up, Enron-style. When I studied Finance, we were told that when we made stuff up, we were to use the Latin words Pro Forma to tip people off that we were engaging in creative accounting.
This is why I do not want to work for The Borg or their minions. Why bother actually making software that will save people money when you can go ahead and make up whatever savings you need to close the deal? Instead, I prefer to work for companies that are forced to actually make stuff people can use. Companies that have to compete on value. Such companies often have to make hard choices about what to ship, by when. But they rarely have the luxury of shipping complete dog- aw, you finish the sentence.
This is my “bottom line,” as they say in Finance. Different companies have different strategies for success. The important thing is to make sure that the things you value in your career and business are aligned with the strategies your employers, partners, and/or customers pursue.
When they aren’t, you do not have a fit and need to reëvaluate your participation. But should you be fortunate enough to work with people whose strategies depend heavily on your values, you are going to be happy.
Pax, and I thank The Borg for yet another lesson in life’s little truths.
Sunday, September 02, 2007
Does Apple get 22 year old college students laid?
When Jamie Zawinski speaks:
Fake Steve Jobs listens:
Your “use case” should be, there’s a 22 year old college student living in the dorms. How will this software get him laid?
That got me a look like I had just sprouted a third head, but bear with me, because I think that it’s not only crude but insightful. “How will this software get my users laid” should be on the minds of anyone writing social software (and these days, almost all software is social software).
“Social software” is about making it easy for people to do other things that make them happy: meeting, communicating, and hooking up.
Fake Steve Jobs listens:
With the young kids the hook we’ve got into them is the iTunes store and the iPod. Pretty obvious strategy really. With kids the hook is always music. That’s why the whole iPod thing was such a brilliant maneuver. Because it brought us across the generational divide. The iPods get the kids into the store. Once inside they can look at those beautiful sleek expensive iMacs and lust after them.
Remember, geezers, when you were in high school and college and the biggest purchases in your life involved vinyl LPs and stereo gear? Remember when you would spend hours in record shops? Remember how much you cared about some new album? Remember standing in the hi-fi shop, lusting after the Linn LP12 turntable or the Quad speakers and telling yourself if you ever got some money you were going to buy a set-up like that? Same today for these kids. Our stuff is what they aspire to own.
So we bring them in with free rock concerts and we prime the pump with 10 free iTunes downloads to get them using our system. They start out with an Apple iPodand then they save their pennies and buy a Apple Mac mini
or an Apple iMac
. Or an iPhone. We’re their record store, and their hi-fi store, and their TV store, and their phone store.
The biggest things in a teenager’s life — other than cars and dope — they can get from us. Not a bad business to be in. Yeah, we don’t get the enterprise market. We don’t get to sell to IT departments who beat us up on price and squeeze our margins to zip and choose their servers based on which company (HP, Sun, IBM, Dell) is giving away the most freebies this week to win business. Boo hoo. We’ll deal with it.
