Last week I was on the shooting range learning how to shoot clay pigeons with the shotgun. When our trainers explained the process I was a bit irritated at first. They explained to us how to raise the weapon to get into firing position, what to do with our eyes, and how to move the weapon for a moving target. But they didn’t talk much about the hitting itself, they just gave us feedback about the technique and if we shot too low or too high.
They didn’t care about hitting the clay pigeons. Instead, they focused on the proper technique up to the point where we pulled the trigger, lowered the weapon, and secured the weapon. For them, the hitting of the clay pigeon was a mere side effect that followed proper technique.
When driving race cars it is similar. You ensure proper footwork for the pedals, shift gears at the right moment and take turns at the right angle, the rest will follow. Speed in the end is a side effect and follows the correct technique.
In the software world, I think it is the same. Great software is a by-product. If you have clear requirements (what), defined the technologies and the architecture (how), have a great team that knows its craft (who), and defined a time frame (when), then there is the possibility that the result will be a great piece of software. But if one of them is missing or unclear it is impossible to create great software.
We as software engineers are often very short-sighted in this regard. Sometimes we focus on one aspect and neglect the others. Sometimes we only focus on the end result and forget the technique and the process altogether.
In this regard, I sympathize with the software craftsman movement. We as software engineers need to be professionals, do the best we can, educate ourselves, work on our technique, and follow proven processes that fit our teams and the rest will follow.