Better is Better, not More
In this day and age, we are used to having more and more shoved in our faces. We go to a coffee shop and we have to figure out how caffeinated, flavored, and masked over we want our coffee. Because of all the crap that they put in your $5 cup of coffee you can’t tell if the beans are burnt, replaced with dirt, or if the coffee is actually good. The overwhelming choice is there to make the coffee user feel empowered over their addiction. I happen to like my coffee, but the exorbitant prices and crappy coffee keep me from going to places like $tarbucks.
The same thing has made its way into the world of photography. People behind the counter at your local camera shop have the audacity to say that digital makes you a better photographer because it’s easier to take a butt-load of shots ! I don’t know about you, but something like that smells bad in my mind. A butt-load of shots with no thought put into them are just as bad as only 36 shots with no thought put into them. Yet they tell you these things because they need to move these $1000 cameras off their shelves, and people buy them thinking this magic bullet will suddenly make them better. The cameras come equipped with all this auto-focus, auto-exposure, auto-forget-about-thinking stuff and people think that if the camera takes care of everything they will be good. If you want a camera that does everything for you, save some money and buy a point and shoot camera. They do everything the big boys do and cost hundreds less.
But the point is not about the rant on cameras. It’s the rant on a false sense of security , and the “silver bullet” mentality we tend to get ourselves into. When it comes to the designer’s view of the world, there is a very difficult balance between enabling your users to be better and turning your users into brainless idiots. Take for instance the View camera. That’s the camera pictured in this post. It’s a large format camera, which means that it is slow to set up a shot, expensive to take a picture, and requires a lot more thinking in advance. So why have one? Photographers who learn how to use these properly become better with all their cameras because they are forced to think more about what they are doing before they do it. It’s the thought that makes the users better, not the camera or the fact that it is slow and expensive to operate. Those are side-effects of providing all kinds of operations that normal cameras just can’t do. You can have a several thousand dollar Hassleblad with a tilt-shift lens, and you won’t be able to match what you can do with a view camera. They are different beasts altogether. Granted, you probably won’t be able to tell the difference when the pictures are small. But when you blow your picture up to over four feet tall you’ll be able to tell.
Too much automation is just as damaging as not having enough automation. The balance we need to strive for is to help the user think about their job and not the tool . Its about finding the right options and the right level of automation for the task at hand. Sometimes the point and shoot is the right tool for the job. Sometimes you really need to take your time and craft things perfectly. Sometimes, removing all automation is the right thing to do.
If we start with the premise that everything can be done manually, we start creating the libraries with that in mind. That’s how picocontainer was conceived. If we want to add automated plumbing, we do that on top of the core. Scripted wiring of your components? That’s built on top of the fully manual core. Even though I don’t use that project, its mere existence forced me to rethink some things about automatic plumbing some time ago. The same thought processes went into the Java ActionPack library (Yes, I know I need to put more of a web presence up for that project).
So what about automating the parts that are annoying to do each and every time? Absolutely. We shouldn’t be forced to think about things we don’t want to think about. The more we get the machine to do things like creating a build, branch, etc. the more we can get them to be done consistently. However, some things can’t be done automatically, nor should they. When you evolve your code’s design you should be thinking about what you are doing. However, if you want to do simple things like rename a method, it helps to have your editor find every instance where the method is used and change your code for you. That’s not something you want to spend time thinking about.
