There is more than one way to skin a cat, as a morbid expression goes. And, less morbidly, there is more than one way to bring software into existence. Today, I’d like to talk about that in sort of a linguistic, descriptive sense. If that sounds weird, what I mean to say is that I’m not going to talk about how you can use different languages, software development methodologies, etc., but rather I’m going to talk about different attitudes toward the construction of software.
I once worked at a place that made heavy machinery controlled by software. The control software needed to have extremely precise timings and, for a GUI… well, it didn’t need much in that department. Just enough that it could be operated by technicians. As such, the approach to this software wasn’t really one of craftsmanship but one of utilitarian construction since the core business of the company was selling hardware. At this company, we wrangled and hacked software together.
I’ve worked at a place that was process-heavy. It was oh-so process heavy. And, when too much process hamstrung productivity, more process was added to make the unproductive process more productive. Design decisions were usually made by committee. Having a class implement an interface was not a decision to be taken lightly — the council of elders had to discuss it a length. Not a whole lot of software was written, truth be told, with some programmers not assigned any programming work for entire releases. At this company, we tentatively nudged the existing software after much deliberation.
Another experience I had was working in an environment where the goal was to get the software done as quickly as possible, in the interests of besting competition and, in some cases, improving margins. The marching orders were to do the best to make software of decent quality, but to get it done as quickly and efficiently as possible. At this company, we cranked out software.
These days, almost everything I do, software-wise, is iterative and agile, and I’d assign a different verb to describe what happens. We improve software. When you really get down to what a lot of the craftsmanship principles and agile practices are about, they drive you toward steady, incremental progress and improvement — shaping the software into the best solution to your users’ problem. But doesn’t “improve” imply that you’re not actually created it, but changing it?
Yes, absolutely! If you have a two week sprint, the only time you create software is during sprint one. At the end of sprint one, you deliver software to the user, and from there forward, you’re changing it rather than creating it. And, hopefully, you’re changing it for the better, which is why I pick “improve.”
So what does your organization do when it comes to software? Do you crank it out? Hack it together? Do you happily craft it? Angrily dump it? Grudgingly fork it over? I think this is a good exercise to engage in to tell you a bit about your organization and your perception thereof. And if you don’t like what you do, what can you do to change it? Can you change it? And, if not, and you want to go somewhere else, this exercise may help you in your search for a place you can be happy. Maybe you even ask this in an interview and see what they say. “So how do you make software?” If they don’t look at you funny and think that you’re crazy, you might just have an interesting discussion.