Beware the programming guru

Never try to code complex software with no scope, no requirements, and no project plan

Ten years ago I took a job with a large, privately owned plastics manufacturer. The firm’s president had decided to update the proprietary systems that had been running the business for more than a decade with more efficient versions. The company had experienced rapid growth, and the old systems were creaking under the load.

The president had hired a well-known programming guru I’ll call “Wiley” to lead development. I think the plan was to groom this guy as an in-house management consultant whose services could be marketed to other companies, along with the software I would be developing.

Wiley had a reputation for being on top of the very latest trends in IT. I was looking forward to working with him. But on my first day at the job, I discovered we were deep in the doo-doo. The president was talking about a fairly complex system -- one that would handle sales, warehousing, project management, customer access to production progress, even vacation scheduling -- and nothing was documented. I mean there was no scope, no requirements, no project plan, nothing.

To make matters worse, Wiley insisted on our doing software development in an obscure 3GL he had helped create a few years earlier -- one that I’d heard was moderately unstable. And although we were several years away from going live, Wiley had already spent a fortune on several refrigerator-size  computers and storage arrays to run the system. Meanwhile, were there platforms for development? Servers we could use for testing and production? Of course not.

When I expressed my concern about the lack of requirements, Wiley assured me he had always been successful working this way. Being able to change requirements during development, he explained, would ultimately save lots of time and produce better code than attempting to define all requirements at the beginning. And of course Wiley himself would be providing all the initial requirements.

We started on the warehouse management system. Wiley had already built and installed a component of this system at the warehouse site, something involving scanners and RF receivers, and I decided to drive out and see how it was working. When I introduced myself, I encountered a wave of hostility aimed directly at me. Everyone I spoke to, from secretaries to the warehouse manager, told me that the new system was a disaster. Wiley’s scanner technology was frequently off-line, and even when it worked, it was far less efficient than the paper-based system they’d been using before.

I didn’t mention that as far as I knew, just this small piece of the system had taken more than six months and millions of dollars to build.

When I returned to the office I requested a meeting with Wiley, and as gently as I could, I shared what I had learned: The users were unhappy; the system was not meeting their needs; it didn’t reflect where the business needed to go. I respectfully suggested it was time to start asking the users what they needed.

Wiley’s face grew dark. He leaned forward in his seat, and through clenched teeth he said, “I don’t need to talk to users about what they need. I tell users what they need.”

There wasn’t much left to talk about after that, and several weeks later I departed from the company. Shortly thereafter, from what I understand, Wiley left too -- not necessarily of his own volition.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies