- “Be careful there, Mr. Hunter. It's all I've got to rely on, being a simple-minded son of a bitch. Rickover gave me my command, a checklist, a target and a button to push. All I gotta know is how to push it, they tell me when. They seem to want you to know why.”
- “I would hope they'd want us all to know why, sir.”
As a teenager, the movie "Crimson Tide" appealed to me in all its macho-ness. Seriously though, with Denzel Washington and Gene Hackman crammed into a nuclear submarine, what’s not to like?
Even though this quote may be both dated and corny, I find it to have a lot of bearing on us software developers. Very few of us enjoy just being told what button to push and when; we want to know why.
'Why' directs creativity
As a developer, I've been presented with a lot of different tasks. Too often, the tasks have been in the shape of a ready-made solution, essentially a prose version of the code I'm supposed to write. In these instances, I find myself in the role of an interpreter, simply translating written text into code, and start picturing myself with a long beard, stressing to have my punch cards finished just in time for the 3 o’clock daily compile. Okay, that might be drifting away a bit, but you get the picture. These tasks bring me little joy and give me no sense of real value.
So, what do we do with these tasks? We’re all creative people and need an outlet for all that energy, so we’ll create. But without any context or background to the business case we're supporting, we fall back into the domain we all know – the code domain.
In these instances, I'll start refactoring some legacy code I run into, probably unrelated to the problem at hand and completely unnecessary. I’ll create generic, super-reusable micro frameworks for what I think are common scenarios. But since I don’t know the business around them, I’ll create something that's technically brilliant, yet practically non-reusable. In the end, I’ll create a sense of value and accomplishment around a not-so-exciting task. I filled the void. I wanted to contribute to a better solution and I did it in the only way I know how, by providing myself with the "why" that I didn’t have.
So, why do we often end up with tasks like this? I think it's a matter of resources, planning and misconceptions. Business people might think that we're mostly technical geeks that love code. Maybe they think we don’t have time or interest in the business. But we do, or at least, we should. Even though developers love code and love writing it, the role of a developer is larger than that of a code monkey.
But it's not only a matter of getting other people to let us in. We need to step up. We need to speak up. We need to ask questions and we need to insist on becoming involved and take more room.
'Why' builds a better solution - together
Instead of solving the problem beforehand, including more people in the solution process will give a better result in the end. Bringing more people to the table will add more valuable viewpoints to the problem at hand. Maybe it’s not a problem at all. Maybe it has been solved before. Maybe we shouldn’t really solve this problem, but the root-cause instead.
To leave developers out of the loop when it comes to designing software seems silly. We are, in fact, developing software; software developers would seem pretty handy to consult, wouldn’t they?
From a developer’s point of view, hearing the underlying discussions that leads into a requirement is extremely valuable. A requirement is something very specific and rarely expresses any feeling of the situation that it is meant to remedy. Sitting in on those discussions allow us to get a better view of what value our effort will bring. Words on paper can only express so much, and there's often a lot said between the lines and in less formal conversation.
On the flip side, having non-developers sit in on more technical discussions is also a good idea. Expressing your design idea in less “techie” words really puts it to the test. If you can’t motivate those extra hours needed for something technical, you won’t get any acceptance. People that know the business can keep us developers on track, ensuring that focus is kept on the right things.
On a recent project, I joined forces with the tester and the analyst for a two-day focused testing session. We made ourselves a war-room with a whiteboard, a post-it deck and our laptops. It was a truly a creative, highly effective environment. My sense of accomplishment when something just worked was as great as my disappointment when it didn’t. Not only did it give me a broader understanding of what we built, it also revealed some flaws in our design. Since we were all there, we could make modifications rapidly and get on with the testing. That testing session was, without a doubt, the highlight of the project - at least for me.
It’s all about removing the fences so there are none to throw stuff over later.
'Why' drives commitment
If I feel involved in a project or task, I feel both needed and appreciated for what I do. And when I'm involved with a team of people I become committed to delivering the best solution possible. I go that extra mile to get things done. If I'm present during client meetings, design and testing, my understanding of the core business will grow rapidly.
If I can relate to a problem or put a face on it, I am more likely to take it seriously. In some projects that I've worked on, the end-user has only been an arms-length away. Even though that has some implications, it brings a shared understanding between me and whomever I am doing the work for. I know what their day looks like, the environment they work in and what their biggest obstacles are. I also know what they appreciate, what impresses them and what tasks they enjoy doing. It also gives them an understanding of what I can do and what my situation is like. In the end, software projects aren't a matter of us versus them. We all want the software to be the best solution possible, that’s why we are in this project.
In that aforementioned testing session, we were all set on getting all the test cases to pass. There was no blame-chain going on when things didn’t work, just a common understanding that we were going to make things right in the end. We shared a common ownership of the entire solution; we were in this thing together! That’s what software development is all about – collaborate during the project, celebrate together afterwards.
Genes or Denzels?
So, how do we, as developers, avoid being out of the loop, becoming code monkeys that stay happy by writing endless generic services, managers, etc. with no value?
We get involved!
We insist on sitting in on those design sessions, client meetings and test runs. If it’s not possible on this project, make sure it happens on the next one. We make an effort to get to know the business we are developing for and the people in it. We try to gain an understanding of what we are actually doing and why.
On the other end of the table, the business needs to get their developers involved. Start by asking yourself what kind of developers you want. Do you want Genes, strictly following orders and coding by detailed specs, or do you want Denzels that question and contribute to the design, always trying to improve themselves and the business?
If the answer is Genes, well… good luck. Don’t call me, I’ll call you.
For me, the answer is simple: I would also hope you'd want us all to know why.