As a semi-professional photographer when I’m not being an engineer, I’ve thought often about the similarities between good software development and good photography. It may sound like a stretch at first, but bear with me...
The best photographs I’ve taken have this important first step in common: I knew what I wanted the image to look like before I ever touched the camera. For example, I spent weeks planning to photograph wind turbines. The nearest wind farm is a couple of hours away from me, and I had to have it well planned before I even started on the journey. Sunrises last only a few minutes and I didn’t want to have to make the trip more than once to get the image. I planned how many turbines I wanted in the picture, what the sky would look like, where the rising sun would be placed, even what the position of the blades would be relative to each other (not something I had complete control of, but knowing what I wanted allowed me to watch for the opportunity if it should arise).
Similarly, I’ve found that the cleanest, most reliable software has started with a clear vision – knowing all the details before the editor is launched allows the programmer to understand not only what the code needs to do, but also allows her to watch how the environment unfolds as it’s being created and be immediately aware of any adjustments that need to me made.
Armed with my vision of the image, I can predict what settings I need to make on my camera to get the desired result. For this picture of a railroad spike I wanted the spike itself to be in sharp focus and everything else a bit blurry, so I adjusted the camera to get the desired result. It is possible that I could take the photograph with improper settings and “fix” it later in editing software, but it’s much easier to get it right in the camera. Plus, I know that if someone wants me to reproduce the effect in a future photograph I can approach the task with confidence that I can achieve a quick result. It’s just good practice.
With clear understanding of functionality, structuring the software project so that it is readable and easily maintained is much easier. Poorly written and organized code can be maintained, modified, and fixed later, but the extra effort is much larger than that of getting it right to begin with. Plus, if the developer does not make a practice of structuring the code and the project well, reproducing good results in future projects can become all the more challenging.
With the subject matter of the image in front of me, and having my camera settings such that I will get the result I want, I can put all my attention onto composing the image. No matter how well I have the picture planned in my head, there will always be last minute adjustments in the real world. Perhaps the tripod cannot be physically placed in the exact spot I need it, or – as is often the case – the exact conditions cannot be entirely predicted. This tree is one that I passed every day on my way to work, and I always knew I wanted to capture it in front of a dramatic sunrise, but I just had to bide my time until the moment presented itself. It took months, but when the moment came I was ready for it. Had I waited two minutes either way the entire effect would have been lost.
A programmer often needs to bring flexibility to the task of creating software, creating small – or even large – adjustments to unexpected realities. As a very skilled software architect I know is fond of saying, the problem with modeling the real world is that the real world often doesn’t behave the way we expect it to. But with good vision and structure, those adjustments don’t have to mean the introduction of chaos. It can instead be the opportunity for greatness.
All of the planning, camera adjustments and light modifications I can think of won’t matter at all if the image isn’t in focus. Once I actually get down to the business of taking the shots, 90% of my effort is simply focusing on focus. Overlooking this last critical part of the photographic process can undo all the good things I’ve done up to now. An out of focus image means all the difference between one I can hang on the wall (or sell!) and one that I delete forever.
A software engineer also needs to keep focus on the code development. All of the architecture and design performed up to this point should make the software development task itself easier, but losing focus can undo all of the good that’s been done to now. Bugs can be introduced, faulty memory allocation can be more difficult to track down or even identify, and years of software maintenance can be made so difficult that future engineers are afraid to touch the code. By keeping sharp attention on the real work directly in front of you, a result to be proud of is inevitable.