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.
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.
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.
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".
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.
Thanks Cliff - good to know I'm not alone!
Sometime I see these things, and I think "this is madness" then I think "surely nobody else could..." or "Am I really seeing this?" So there risk in saying this publicly
I have found similar issues frustrating as well. Often when I see it, it's when several people at the table are embedded in the business so they are already "bought and paid for." But developers are kept out of the loop because their involvement (from the technical side, thus a different funding source) means that they are charging for their service, usualy by the hour. It is a constant exercise to bring programming knowledge to the table at the right time, but not have that be a slow, long running expense. Having coding expertise on the wider project team would certainly help.
I can create similar scenarios in the classroom, I wrote a blog about this recently with some data I'd recorded from teams - Estimation, planning, teams and money, some data