(noun) When the costs of reverting to a previous state or switching to a different path become prohibitively high, even in the face of better solutions.
The company’s reliance on Progress 4GL illustrates path dependence—despite newer technologies being available, decades of ABL development make switching platforms economically unfeasible.
I’ve heard these referred to as one-way doors.
Some path dependence is unintentional. Think QWERTY Keyboards, internal combustion engines, employer sponsored group healthcare policy.
Some is entirely deliberate: phones, CRM, ERP, office suites, operating systems, databases, clouds. Hell, even American car-dependence was orchestrated by auto manufacturers leveraging monopoly power to shut down municipal street cars!
Strategies for Managing Path Dependence #
Solution Late #
During discovery, resist the temptation to immediately start building solutions. Solicit input from outside your bubble. Hire a trusted consultant.
There is no best technology without context. Cost, interop, cadence, risk, regulatory compliance, training - these things matter too!
If you want to see early solutioning at work, invite an eager junior developer to a strategy session. Count the minutes before they propose an idea. Odds are it will be a language, database, framework, or platform. It might be a trending architectural style (looking at you, microservices). It will be about technological superiority (it scales! it’s functional! it’ll look great on my resume!), not fitness for purpose.
Understand Tradeoffs #
I want to be humble enough to realistically assess the pain-points of preferred solutions, not just point out the pain-points of alternative or existing solutions. Write ADRs.
I think it helps to build and cultivate a wide network of practitioners. Swap war stories. Be on the scene without making one.
Embrace the Current Path #
I want to understand how we got here. I really don’t want to swim upstream.
I am familiar with AWS, and I think it commoditizes many problems. But if my client is on Azure, it’s an asshole move for me to start building in AWS and expect them to adapt.
For the consultant or prospective employee: if the client has a solution in mind (“we need you to build a postgres database to do xyz”), they might be looking for a contributor, not an advisor. I treat these an opportunity to stay sharp and be a craftsman.
Open Standards and Ubiquity #
I won’t belabor this one. It’s SQL. HTML. Linux. It’s the JVM and the .NET runtime. It’s avoiding syntactic sugar and extensions. It’s being able to run locally, it’s portability, it’s being able to hire.
Long Arc Thinking #
Maintenance programmers cost money, too. It’s not a value-add to have to upgrade platforms and frameworks every six months just to stay ahead of CVEs and interface changes.
I worked for a state government agency around 2015. They were storing code in CVS and hand-deploying WAR files to hand-configured Tomcat instances. You must use pipelines, I insisted. Jenkins! Automation! Unit tests! You will be free of the horrible burden of typing and clicking, instead you must type and click in this other more “modern” system. The irony, of course, is that I created shadow infrastructure for my team’s precious Jenkins server, which only I understood, without regard for the environment around me. You do not want your government to “move fast” or “break things.” None of this helped the constituency, and it definitely didn’t help the IT workers who inherited my jank.
I am leery of fast release cadences and short EOL’s. I’ll take a stable platform over new language features. In the scope of even a small business, very few people care if the programmers have coroutines as language primitives, no matter how cool that is.
A Short Rubrik #
- What’s the time horizon for what we’re building?
- If it’s a commodity, does it adhere to common standards?
- How will it affect our talent pool?