Project Teams Need to Overcome Their Fear of Coding

[article]
Summary:
Many organizations appear to suffer anxiety at the thought of programming. They want to get everyone but the programmers in a room to discuss a project down to the minute and the dollar, without a full understanding of the coding required. But a few hours of code experimentation generates far more understanding than days of debate by architects and analysts. Don't be scared of programming.

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.

User Comments

3 comments
John Tyson's picture

If they want everything specified up-front, that's not agile.  It sounds typical of outsourced projects.

Perhaps programmers run away from being burned by not being allowed to "build one to throw away" as Fred Brooks mentions in The Mythical Man Month.  Too many prototypes that were never meant to be production code ended up as production code.

Proof of Concepts are very useful to many parties and should be encouraged.

October 19, 2017 - 9:23pm
Allan Kelly's picture

Thanks John, good point,

I don't think anyone would have called this Agile, my presence was a sign of the organization's asperiration more than anything else. Although, the bank largely defined "agile" to mean "agile delivery within a traditional framework." Which meant this was part of a "scoping" exercise which boxed in the work and prevented flexibiliy

This wasn't about programmers either, as I mentioned, they weren't even in the room. Again this was more an exercise in boxing the programmers in.

Brooks "throw one away" remark is in the first edition of Mythical Man Month but in the 1995 edition he changes his advice: "This I now perceive to be wrong... it implicityly assumes the classical sequential model".

 

October 20, 2017 - 6:45am
Clifford Berg's picture

Yes, I see this _all the time_ too. So many people in IT, making decisions, who don't know anything about programming. This situation is a holdover from the legacy use of waterfall-like methodologies, where there is a huge planning effort, and then "implementation" - this does not work with Agile methods, however, yet in the case you cite, they mentioned a minimum viable product (MVP), yet were approaching it in a waterfall way - showing a real misunderstanding of the intent of MVP.

October 20, 2017 - 8:39am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.