In one of his first ever Simple-talk articles, Phil Factor tells the story of a freelance Sybase programmer who created a reporting system using exquisitely complex dynamically compiled stored procedures, and then promptly departed when he failed to secure a doubling of his contract rate. As Phil struggled to make sense of the code, with the business baying for bug fixes and impossible improvements, he learned a valuable lesson for any IT Manager:

“Never let a programmer do anything that you yourself cannot understand” – Sir Tony Hoare (Computer Language expert, inventor of Algol and the Quicksort algorithm)

At first glance, it would seem an odd sentiment, but Tony Hoare was referring to code that couldn’t be understood even after being explained to a technically-savvy manager. He was warning of the dangers of complexity.

Certainly, there needs to a restraining force that prevents the typical development team’s tendency towards complexity. There is generally a yawning gap between the technologies that an ambitious programmer wants to use and the technologies that best suit a project. A manager needs enough programming nous to help keep the technology as simple and reliable as possible. In the face of their countless managerial, strategic and company political duties, the struggle is to maintain their programming skills to the point where they can spot if a programmer is adopting an unnecessarily complex or unwieldy approach, or championing “unproven” technology, when something duller but more reliable would suffice.

According to Eliot Horowitz, the CTO of MongoDB, the way to do it is for IT managers to spend at minimum 30% of their time programming. If they don’t, he argues, they “encounter a significant degradation in their ability to execute their responsibilities”, and their “connections to the concerns of developers atrophy…decision-making, planning, and leadership suffer”.

Is Horowitz really correct that a failure to do this simply means one becomes an ineffective manager, as well as programmer, over time?

It is only recently that professional people, Doctors, Lawyers, Engineers or Scientists have felt it to be an option to slide into a generic managerial role, to neglect or abandon the professional skills that first enabled them to rise in the profession. A part of their job was to keep up with changes in their profession. Until the 1980s, management skills were acquired as part of career development and it was unthinkable that a generic manager without professional skills could direct professional work.

Maybe technical leadership is undervalued. Recently, some of the most catastrophic IT failures have been precipitated by startling technical shortcomings, rather than general lax management. Would a more technically-savvy management have been able to spot the imminent disaster and prevent it?