Project Teams Need to Overcome Their Fear of Coding

There should be a term for it: maybe programmophobia. Or instead of a fear of coding, it may actually be a fear of developers themselves, or a fear of technology, rooted in a lack of understanding.

Whatever the cause, many organizations appear to suffer anxiety at the thought of programming. There seems to be no limits to the diversionary activities people can engage in before letting anyone write code. And when code is being written, they want it to happen as far away as possible.

Earlier this year I sat in a meeting room at a legacy banking company to discuss the initial user stories for an agile project. There were about a dozen participants amounting to a mixture of project and program managers, business analysts, a surprising number of architects, and a couple of representatives from the outsourcer. The probable coders were safely on the other side of the world.

The meeting aimed to agree on an initial set of user stories to pass to the outsourcer for estimation. The supplier's bid would use the estimates, and a business case would be built on top.

But the longer the meeting went on, the more I became convinced that few people in the room actually knew how these stories would work together, what the technology was capable of, or what coding these stories actually involved. Sure, the analysts could talk about the need, the architects could talk about the existing systems, the outsourcer could ask fiendish questions, and the managers could remind everyone that this was "a minimum viable product and only must-have requirements should be considered," but I don't think they actually understood much about what it would take to create the product.

At some point a question came up that related to OAuth 2.0 user authentication. Now, I know a little about this. I've written a couple such interfaces, and I'm certain nobody else in the room had. Their comments and questions demonstrated that even the architects knew little of how OAuth worked.

The more they talked, the more the scope of the story grew, and the more options and edge cases were added. As the resident agile consultant, I kept my mouth shut, but I knew I could code this up in less than a day.

The OAuth discussion—indeed, the whole meeting—was a microcosm of the entire software project. Nobody really knew what needed to be done, but everyone had an opinion. One thing was certain: Cost would be decided before anyone got near a keyboard, let alone a compiler or web server.

I lasted two hours. For the others, the meeting was but one in a long series.

And this banking company isn't alone. Again and again I run across organizations that are just plain scared of programming and programmers. They want to cross all the T’s and dot all the I’s before a programmer is allowed in the building. Undoubtedly there is a question of trust underlying much of the discussion—I’m sure some felt that everything needed to be explicitly pinned down before getting anyone else involved. But to my mind, more discussion was self-defeating, as each detail provided another opportunity for misunderstanding and further loss of trust.

Crossing T’s and dotting I’s takes time and money. Not only do you need to pay those figuring out the details, but by delaying the start of coding, the end is also delayed.

These firms seem to think that if they can just nail down every single detail—most of the price of the project—then some coding monkeys can simply turn their words into JavaScript. Most of them also believe that the monkeys know nothing and that the ability to code isn’t complicated.

An extreme example of this occurs in companies using big enterprise resource planning systems. These systems promise to "do everything." All the buyer needs to do is customize them, and this can be done by consultants, with no need for programmers. But these systems are useless out of the box. You can't just click on “SAPInstall.exe” and start work ten minutes later. There is a lot of configuration to do, and it isn't a case of selecting some checkboxes under Tools/Options. It is composing database schemas, creating process flows, and writing XML.

The consultants are instructing the computer what to do. Most of us call "telling the computer what to do" programming, and the people who do it programmers. But not in the ERP world.

Once upon a time it might have made sense to avoid programmers or keep them on a short leash. Once upon a time CPU cycles and memory were expensive. Getting the 8-bit Z80 microprocessor to do anything was a minor miracle! Maybe it did make sense to analyze the work to the minute beforehand.

But today, CPU cycles and memory are cheap. The quickest way to know how to do something, see how two systems interact, or understand the implications of a change is to just do it and see what happens. Analysis may be more valuable when applied with the understanding that comes from a working model. Showing a customer a product and asking if they want it has never carried so little risk.

Programming tools today are much more powerful than ten years ago. Companies that continue to exhibit programmophobia are doing themselves a disservice. A few hours of programmer experimentation will generate far more understanding than days of debate by architects and analysts.