Taking Her Slow
There are several ways to approach making good software, and you have to balance that with what works for you. I’ll pull from my experience with photography to pull an illustration. You can take hundreds of rapid-fire pictures with the hope that maybe a dozen are worth keeping, or you can carefully craft each picture so that almost every picture is a keeper. If I left it just at that you might get the impression that every project should be carefully crafted and architected. However, if you don’t know how to take it slow, you’re rapid fire might be nothing but misses or just OK shots.
A view camera has several kinds of adjustments that allow you to align the film and lens perfectly for sharp pictures. By aligning the film plane so that it is parallel with the side of a building you can make that face perfectly square. The verticals are vertical and the horizontals are horizontal. Then all you have to do is adjust the lens board so that the picture is in focus. Add some vertical and horizontal shift and you can ensure the picture is just right. There’s even more you can do in the darkroom to ensure that the end product is what you envisioned when you started. The nice thing about a view camera is that the film and the viewing port are the size of your proofs. 4×5 for the smaller view cameras and up to 8×10 (and 11×14 if you have a ridiculous amount of spending money) film sizes. It’s as close to WYSIWYG photography as you can get.
The process is very slow and deliberate, but the camera is used for things that don’t move much like landscapes, products, and architecture. You can use them for portraiture if the person you are taking a picture of doesn’t mind sitting and waiting while you fiddle with all the settings. Some photographers might have someone stand in while they get the settings and then bring in the real person so as not to waste time.
An SLR is much simpler to use in comparison, particularly when there is a small computer in there to ensure your exposure is correct based on the light coming in the lens. In fact, some SLRs can take 6 to 10 pictures per second. While not movie camera speeds, it increases the chance of capturing that “critical moment” with subjects that move rapidly. For example, the situations in basketball are constantly changing and capturing the drive to the basket, or a player juking the defense requires capturing that “critical moment” when you can tell in the picture what is going on without seeing the other pictures before and after it. The critical moment when everything comes together and the picture just takes your breath away.
The process is very quick, and you do have to rely on some of the assistive technologies in the camera to help you focus on the part that is important. SLRs are best suited for rapidly changing environments where the subject is always in motion. That doesn’t mean that you can’t get very nice pictures of what view cameras are best suited for. However, your options are limited in what you can do, and even the $1000+ tilt/shift lens doesn’t give you the ability to perfectly align everything like a good view camera. The pictures from and SLR are much smaller in comparison, so tiny imperfections are magnified to make pictures you can actually see and use.
I bet you are thinking I’m tying the analogy to software process aren’t you? Well, you’re wrong! Ha! I threw you for a loop. I’m talking about the design of your software, working with tools, and when you should take it slow versus going high speed. The truth is, very few software projects have a fairly static set of requirements. Unless you are creating command and control software, assembly line automation, or focusing on implementing a new search algorithm, the requirements tend to keep moving. They may move as fast as a basketball game, or they may move as slow as a game of tiddlywinks, but they are constantly changing. That’s why we reach for our favorite assistive technologies like frameworks, object/relational database mapping tools, logging, etc. Anything to make our jobs easier.
However, you owe it to yourself to take it slow every once in a while. Create your own framework for once. Solve that issue that’s been bugging you where your tool is almost good enough, but not quite. Take a fresh perspective, and start playing with looking at the problem differently. There’s always a little downtime between projects, and there’s always something stuck in your craw because things didn’t work out quite right. If you never shift your perspective, everything you do will look like what everyone else is doing. In a world with 20 competing projects that all do something similar, looking like the competition is death. Unless there is something to set you apart from the rest, why would anyone bother using your software? Instead of always following others, lead for once.
One of the things that separates successful photographers from people who take family snapshots is the ability to visualize the end product before you press the shutter release. Whether you are working with a big view camera or a small SLR, you need to have an idea what you are after. There will be happy mistakes, and there will be times where the vision changes as you are in the situation. Without a vision or a goal to aim for, you will end up with a bunch of crap. It might be OK to share with your buddies or your family, but you wouldn’t expect anybody to pay money for it.
It’s the same with software. I subscribe to the continuous design mindset for software, particularly as you get feedback you can adjust the outcome to better match what you are trying to do. That does not mean that you should be completely devoid of any idea of what the software should look like or do. The vision in your mind has to deal with whatever is the most important thing you are trying to do. Are you trying to make it easier for people to do work? Does the current user interface look like a kindergarten art project? Yes, allow the vision to change and be refined through the process, but have one at the beginning.
