What’s wrong with software development? If I had a hammer…
Imagine going to work as a carpenter on a house under construction.
How can I get a hammer? you ask Pete, a colleague.
Pete tells you to talk to Joanna. Joanna says you need a requisition form, but she doesn’t know how you get one. You can talk to procurement or maybe that’s the job of the construction supervisor? You file the requisition form, and in a day or two get a response that the request was denied because you didn’t know the correct costing code to input into the form. Meanwhile, you have done zero hammering.
You’d like to understand the reason the request was denied, but, in order to get an explanation, you need to file another form to get it: the one which tells you which costing code you can use. Instead, you call the construction team hotline, and you get Herbert, who doesn’t know what a hammer is but he’d like to help. He lives in Boise, and he’s working from an office of people given a script on what construction workers do, even though he has not worked construction. Herbert has a hard time hearing you because the Boise office is filled with other people handling problems which they don’t fully understand. He doesn’t want to forward your call to the construction team helpline supervisor because that would ding his job performance merits, so he tells you where you can find a screw driver, and he hopes that will help. It doesn’t. You ask for a supervisor again, and Herbert hangs up.
So you talk to the construction supervisor. It’s a hot day, and she’s kind of angry she keeps getting dumb requests like this. After all, her job is to supervise construction, not provision tools. Plus, she wants to know how you’ve been working the past few days if you don’t have a hammer? What exactly have you done to help build the house? But the thing that makes her the angriest is that she doesn’t know, herself, how to get a hammer. She is furious you tried to guess at the correct costing code instead of asking her ahead of time, and warns you that you need to ask her about everything so you don’t make another mistake. That, in itself, would be a mistake, as everything encompasses literally every decision you make on the job, and you can tell she doesn’t want or have time for constant interruptions, nor do you want to work under those condition.
Going back to procurement, procurement knows you need a requisition form, but can’t tell you how to fill it out correctly or what was wrong with the one you filled out — they don’t know how to get costing codes for employees!
After bugging them in person, during a lunch break, someone slides you a hammer under the table and tells you that you need to keep it a secret that they gave you the hammer.
And that’s how everyone gets a hammer.
What I’m talking about above is onboarding. I know. I know. DevOps can buy a tool which provisions software in a bespoke manner for each individual user based on his or her role and profile in the organization so that the user is fully set up on day one. Yet, for many organizations, they will have this when every employee arrives at work on a hoverboard. A self-driving hoverboard.
The same applies to knowledge transfer. Knowledge hoarding does untold damage to organizations. Its cost is measured in burnout, loss of productivity, redundant questions, and fly-by-the-seat-of-your-pants presentations.
What I’m talking about is communication and collaboration, two things I find shockingly absent from project budgets and individual assessments at end-of-year reviews.
I assert: Information technology shops need a better way to get a hammer.
Let’s talk about how much it costs to have a senior developer trying to find out what access and tools he or she needs, then trying to figure out the methods to get that access and those tools. Let’s have an ongoing conversation about how senseless it is when every engineer needs to find the right person to help him or her get access or a particular tool. Let’s talk about the impact to organizations and employees if they arrive on the job with tools assigned to them based on roles and with access assigned to them based on those same roles. Let’s formally assert that knowing the right person is not the right way to get a tool or a particular form of access. Let’s require, if not automatic provisioning tools, at least inventories of tools, access, and information a new employee needs, along with clear, step-by-step, updated instruction on how to obtain each.
Let’s continue to have these discussions until we as an industry get it right. Our craft depends on it.
Abuse of these principles is eroding our utility to companies and is costing those companies untold dollars.
Thanks for reading! When I see applause for a piece of mine, I want to write more pieces! Please applaud if you appreciate people writing about topics like this.
If you enjoyed this piece, you might consider reading some of the other stories I wrote for this series. Thanks!
Disclaimer: I am a senior software professional with experience as project lead, team lead, and lead engineer in the greater Boston area. I am actively seeking a job while currently fully employed. The world of software development can be an ugly place, and I hope to expose some of the more bewildering and uncomfortable corners in the hopes of improving the industry and the craft. Out of respect for current and former employers, I will keep the names of employers and/or clients scrubbed and anonymized as best as possible in these reports.