"The dirty little secret of many acts of IT heroism is that the hero hacked the solution," says Innovator's Lowe. Instead of doing it by the book, this hero plugs a patch into the code to get it working right now.
Lowe recently consulted with a company whose dev team inherited a 100-line script to control document display. The script was a hack from day one, but fixing it was never a priority. "Every time a new machine came online, its IP address got hard-coded into the script," he says, "so the script gradually grew to over 800 lines. It's unmaintainable and will have to be redone eventually."
Production systems are particularly susceptible to this sort of hacking, Lowe says, because when the software fails, productivity stops, which costs the company money by the minute.
"That script is now 800 lines of special cases and hard coding with no comments," he says. "It's unmaintainable and has to be redone."
The danger with this kind of hero is that the technical debt you build up via short-term fixes eventually catches up to you, Lowe says.
"In some environments you spend every day putting out fires," he says. "You try to reach a point of stability but it never comes, because the fire you put out last month is causing a new fire this month."
It doesn't always take extraordinary intuition or superhuman dedication to make an IT hero. Sometimes the circumstances demand you rise to the occasion.
In 2006, independent IT consultant Jason Wisdom took a consulting gig with the insurance division of a large bank that needed to update its legacy mainframe accounting package to generate new types of reports. Naturally, the bank's CFO wanted the solution done as cheaply and quickly as possible.
Prior to hiring Wisdom, the bank's tech team dove in and started coding. After a couple of months, they hit an impasse. Meeting after meeting passed and nothing got done. Even after they brought Wisdom on board to help come up with a strategy, the team argued for weeks about whether to scrap everything and start over.
"Sitting in those meetings was starting to give me a headache," Wisdom says. "So I finally said, 'Give me a day, let me see what I can do,' and I left to work on the problem. That afternoon they were still talking, but I had the solution."
Donning his "calculus hat," Wisdom reverse-engineered several formulas from the mainframe system, then tested them with sample data to make sure they gave the correct results.
"It was the perfect combination of pressure to get things done quickly, the freedom to do what I wanted to do, and four or five people really hoping I would come through because it was more than just my job on the line," he adds.
The problem? The company wanted the solution to be cheap and fast, but still expected it to be good. Eventually it was good, says Wisdom, but at that point it was neither cheap nor fast.
Here is where an IT department rife with Icemen can turn overconfidence into projects all too often overbudget.
"The amount of rework required drove the total cost of the project far higher than it would have been had they done things properly from the start," he says. "What they should have done is hire a business analyst, technical lead, another developer, and a database administrator. Instead they wanted one person who could do all that. They were being cheap."