Navigate resistance to change in the Enterprise Software industry

1) Identify the technical experts.

2) Ask these technical experts what the major design flaws of their current system are, and what their remediation plan would be.

3) Ask these technical experts which modern technologies and techniques they have considered and discounted. The discussion will identify creative problem solvers who are your natural allies when it comes to change.

"I don't get no respect." -Rodney Dangerfield

You've been involved in software development your whole career. Does that make you an expert? It certainly qualifies you implement your set of skills, and your design paradigm. It also makes you resistant to change.

As an experienced software developer I know twenty different outdated and inefficient ways to develop software. So I'm an expert, right? Don't I deserve respect? People should obey my recommendations, right?

Every year, new software methods come along. The current experts find it easy to point out the problems in the new methods, but may miss the point about the problems the new methods solve. Are you an expert or a dinosaur?

For me, every development project is a fresh start: New techniques; new software; new paradigm. If I'm relying on something I "know" from 5 years ago, it is probably wrong. Software development isn't what you know, it's about devising the best technical solution from all of options.

Everyone can agree that re-working legacy code is a costly nightmare, so when your technical lead asks the question, "Is what we getting out of this change, worth the time and effect?" There is a tendency to limp along with the old system.

If the new leadership pushes for a tech stack changes, the long time developers, experts, may think to themselves, "You'll never get this done without my technical expertise and system knowledge." I've seen developers quit over these massive changes. New management thinks "how hard could it be?" or "the benefits will outweigh the pain in the long run," or "no dead-end nerd is going to set the direction for my organization, I'm the CIO."

My rule of thumb for system rewrites is: "It will take twice as long as you expect, it will be twice as much work and will cost twice as much." Management will hear this and think, "Oh, so twice as hard as we expect." Of course I am thinking, "It will be at LEAST 8 times as hard as you expect."

I personally love working on failed development recoveries and major rewrites because they present the greatest challenge as a developer. The secret sauce is to find and address crippling design flaws in the current system. Once you fix those design flaws, you can reuse 80%-90% of your code.

What? Our system doesn't have crippling design flaws! Reality check: By definition, if your organization is considering doing a major rewrite, your system is critically flawed. If you are the system expert, that flaw is in your blindspot. As system expert, your responsibility is to be on top of those design flaws, with a remediation plan ready to go.

If an outsider comes in harping on the system design flaws that are in the system expert's blind spot, resistance will be strong.

TV Guide Example

I was hired by TV Guide in the late 90's to work a failed system development project for the Prism system. The Prism system had been in development by 4 developers for 18 months on a 12 month delivery schedule. At the end of those 18 months all 4 developers quit, leaving the new system in an unusable state. The Prism system was PowerBuilder with a SQL Server backend. It connected to the Apollo system which had details of 10 million TV episodes and movies on Oracle. The design was to use Oracle transparent gateway so the the SQL Server could query the Oracle data as if it were a linked server. The business logic for Prism was in massive SQL Server stored procedures.

I brought in 3 PowerBuilder developers from my company with a promise to have Prism up in production, with all major bugs cleared within 6 weeks. Our team we were up with all major bugs cleared in 4 weeks. Phase 2 enhancements and quality of life bugs were cleared and deployed by the end of the 6 weeks.

I was fired in a most heated way at the end of the six weeks. Like Rodney Dangerfield, no respect.

The disagreements came from the change control board who also acted in the role of system architect. At the end of the first week, I met with the change control board (face to face) to explain the 10 system design flaws we had identified that must be remediated. Top of the list was that Oracle transparent gateway did not function with 10 million Oracle rows with multiple long-running SQL procedures. Oracle support confirmed there was no fix. Additionally, some program functions were unusably slow in a stored procedure, while using PowerBuilder to connect directly to Oracle made those queries run instantly.

The board said "You cannot make any design changes to the system."

I said "We must make design changes to finish. How am I wrong about this? What is my alternative?"

The board said, "You figure it out, that's your job."

The good news was that I had already figured out the fixes, so we implemented them. I spoke with each of the board members in private, but none had any real understanding of the technical issues, much less suggestions.

Another bit of good news was that the original developers had done a superb job. Once we resolved database connectivity and performance issues, the code snapped into place and flew through QA.

The memory of this project still stings because I completely failed to meet the expectations of the board.

Since then, I only promise to do my best to build reliable performant systems. When an IT executive asks me push through the latest vanity project with unreasonable restrictions, I'm hesitant. If those restrictions are rigid, I'm out.

When someone asks me, "How long will this development take?" I answer:

"It will take as long is it takes. It will be exactly right when it is done."

I love it when I'm asked, "What about impossible tasks?"

I answer, "Impossible tasks take twice as long. Sometimes you have to get all the way to the end of a development to find out exactly what you need, then you start over and get it right. No sensible user asks for the impossible, they just want their thing."

Life was a lot easier when I could promise, "I'll have your system up and running in six weeks," and mean it.