Software Artisan

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.

You may associate these words with the types of things that they create. In our minds, we might associate engineers with creating system integration projects and mission critical systems. Craftsmen would be the kind of folk who create kitschy programs that serve no purpose other than entertainment. Finally an artisan would be someone who creates something that is both useful and beautiful. But that really isn‘t true. The difference doesn‘t lie in what these people create, but in how they work.

An engineer is concerned with metric proofs and solid evidence. They decide which approach to take based on tests, and typically choose the approach based on tests that show program efficiency. These are the guys that might color by numbers, so the approaches tend to be sterile, cookie cutter approaches. Nothing new is ventured as long as all the existing approaches fit the numbers they are looking for. Management likes this kind of person because they fit nicely into the corporate mold. Nevertheless, if something works, they don’t see if they can make it work better . That is the major problem.

A craftsman cares about the little things. They like elegance even in the code. They don‘t mind spending extra time on the areas that matter most to them. A craftsman is also quite adventurous, and will try new things just because they can. If it works out, they‘ll probably try it on a bigger scale. As a result of all the extra attention and experimentation, they are willing to gamble a lot more. Sometimes this pans out, other times not. Management doesn‘t like this kind of person because they are hard to control, and worse, hard to predict. Artistic things matter to them, and numbers do not.

An artisan is somewhere between the craftsman and the engineer. They perform all kinds of tests to know their tools and their materials. They still have an eye for elegance, but it is always balanced against the whole project. After all, what good is having one good part in the midst of mediocre parts? It looks Frankenstein like. They are fond of experimentation, but it is always within the larger confines of their vision. Management can respect these people, because they are predictable, and they do bring issues to light that can‘t be measured accurately, but have a profound impact on the project. Aesthetics matter, but not to the exclusion of function.

Of the three, it is the artisan that can produce higher quality apprentices who can themselves become artisans. Engineers are too machine-like for their own good. Now, there are people who call themselves engineers but behave like artisans. There are also people who are engineers to the bone and scorn any artistic influence at all — particularly on code, like that can do any good. Artisans are very pragmatic and knowledgeable people. They do realize the importance of elegant, understandable code that performs its task without half trying.

So, which one are you?