Stories about Software


Surviving The Dreaded Company Framework

This week, I’m making it two in a row with a reader question.  Today’s question is about an internal company framework and how to survive it.  Well, it’s actually about how to work effectively with it, but the options there are sort of limited to “get in there and fix it yourself” and “other” when the first option is not valid (which it often is not).

How does one work effectively with a medium to large sized company-internal framework? The framework has one or two killer features, but overall is poorly abstracted and [released] with little QA.

I think the best way for me to tackle this question is first to complain a little about Comcast, my erstwhile cable company, and then come around to the point.  They recently explained, in response to one of my occasional Comcast rage-tweets, “[The] promotional pricing is intended to offer you the services at a reduced rate, in the hopes that you enjoy them enough to keep them.”

This is, in a nutshell, the Comcast business model — it was an honest, and forthright tweet (unlike the nature of the business model itself).  What Comcast does is reminiscent of what grocery stores do when they flood the local shopping magazines with coupons: differential pricing.  Differential pricing is a tactic where in you charge different rates for the same product to different customers, generally on the basis of charging more when people are non-price averse.

The trouble is that outright differential pricing is usually illegal, so companies have to get creative.  With the grocery store, you can pay full price if you’re generally too busy for coupons, but if you load up with serious couponing, you can get that same grocery trip for half the price or less.  They can’t say, “you look rich so that’ll be $10.00 instead of $5.00” but they can make the thing $10.00 and serially discount it to $5.00 for people willing to jump through hoops.

Comcast does this same thing, but in a sneakier way.  They advertise “promotions” and “bundles” to such an extent that these appear to be the normal prices for things, which encourages people to sign up.  Then, after some time you’ll never keep track of and never be reminded of, the “regular” price kicks in.  For me, recently, this turned out to be the comical price of $139 per month for 24 Mbps of internet.


When you call them to ask why your most recent bill was for $10,928 instead of $59.99, they’ll say “oh noes, too bad, it looks like your bundle expired!”  And this is where things take a turn for the farcical.  You can ask them for another bundle, and they’ll offer to knock your monthly bill down to $10,925.  If you want to secure the real savings, you have to pretend for a while to be canceling your service, get transferred over to the “retentions department,” and then and only then will you be offered to have your service returned to a price that isn’t absolutely insane.  I suspect that Comcast makes a lot of hey on the month or two that you get billed before you call up and do that again, because the ‘normal’ prices are equal parts prohibitive and laughable.

Why am I mentioning all this?  Well, it’s because when the time came for my most recent annual Comcast gouge ‘n’ threaten, things got a little philosophical.  I wound up on the phone with an agent to whom I confessed I was sick of this stupid charade.  Instead of arguing with me, he said something along the lines of, “yeah, it’s pretty ridiculous.  Before I started working here, I used to hate calling up and threatening them every year, but the thing is, all of the other companies do it too.”  This was either a guy being refreshingly honest, or a really shrewd customer service tactic or, perhaps, both.

But the interesting message came through loud and clear.  In my area, if you want TV and internet, it’s Comcast or it’s AT&T.  And if both of them behave this way, it goes to show you the power of a monopoly (or a nominally competing cartel).  Their motto is, in essence, “Comcast: it’s not like you have a choice.”

Internal Frameworks: They’re Comcastic!

I’ve experienced the internal corporate framework before.  It’s always presented to newbies with a curious mix of pride and chin-jutted challenge, leaving you to wonder if the presenter wasn’t sneering ever so slightly and thinking, “do you know how long I’ve been working here — come at me, bro!”  I remember starting a job years ago where a politically unsavvy fellow trainee wrote his quick company exit in part by starting to question The Framework right from day one.  Poor guy.

I’m far from alone.  The reader’s company has a Framework.  The Daily WTF archives are littered with them.  (I’m actually half convinced that the Daily WTF couldn’t exist without internal frameworks).  I’m sure most of you reading are shuddering and remembering some stop along your corporate journey where you were forced to use the architect’s horrific pet framework.


In my experience, there are two universal properties of these internal frameworks: (1) the company that holds them wildly, comically overvalues them and (2) the amount of effort expended browbeating people into using them is significant.  In other words, no one working there ever says, “wow this 30 parameter HandleLoggingAndExceptionsAndOtherStuff() method that I have to call every third line of code is the best!”  They just start doing it by rote, eventually, after getting enough angry emails or admonishments at code review time.

If you decoupled all of this from any organizational politics, you’d notice something revealing.  If the company could somehow be persuaded to run an experiment and open source or sell this framework as a software product, it is a veritable certainty that not a single person would ever use or buy it.  People don’t use it because it improves their lives.  As with the Comcast business model, they use it because for all intents and purposes, they have no choice.

Surviving the Framework

The fact that the framework from the question has a “killer feature” puts it above most that I’ve seen, quite frankly.  But however killer those one or two features, I can say with near certainty, sight unseen, that the thing does more harm than good.  These types of frameworks are almost invariably technical debt factories, riddling client code with bugs and forcing awkward, inefficient practices on clients, such as massive amounts of code generation or weird runtime binding schemes. The question of “how do I work effectively with it” is thus best re-framed as “how do I minimize interaction with it.”

A first, if extreme, option is to go work somewhere else.  This could be at another company (though word to the wise during your next round of interviews, keep your ears peeled for proud mention of “Our Proprietary Framework” as a red flag), but it could simply be another group or another project not forced to deal with the thing.  In my experience, the prevalence of a framework like this correlates heavily with quixotic attempts to turn programming into a low skill, paint-by-numbers exercise, so there are probably other not-awesome things happening there as well.

If you’re not ready to rock the boat quite that much, it might be worth attempting to exert some influence of the composition of the framework.  The politics of this are going to vary quite widely by organization, and you’re most likely entering the main lair of your company’s expert beginners, but there may be hope here.  If the guardians of the thing are receptive to it (or absent), chip away at some of the issues with it in your downtime.  Treat it not as the thing everyone’s forced to use, but as a product you’re trying to breathe some life into and sell to your coworkers.  Ideally, if you make it helpful to them, people will actually start to engage with it, invest in its quality, and request features of it.

Assuming you can’t run from it and you can’t make many inroads in improving it, I’d suggest building a facade for it.  This will insulate you from some of its problems and make the boundary between issues in your code and in the framework a lot more obvious.  But, there’s another, subtle play here.  Approach the facade the same way I suggested in the previous paragraph — make it a handy, pleasant to use wrapper that your coworkers prefer to using the actual framework.  This will start to earn you some cred and some clout that you can parlay into starting to wrangle the actual beast itself at a later date.

The last and (to me, anyway) least desirable option is simply to wait it out.  Sooner or later some green field rewrite will come along and the framework in all its glory will be retired.  It’s possible (even likely) that they’ll try to rebuild it, better and stronger than ever, in the new tech stack.  But at least when that happens you’ll be on more even footing to have input into how it goes (and, in general, into how common code should be reused).

Wait, They Can’t All Be Bad

Now, for the broader audience here, I imagine some of you are thinking that I’m painting with too broad of a brush.  Just because there are a lot of bad internal frameworks out there doesn’t mean that any given one is, in fact, bad.  And, that’s fair enough — I’ve no doubt some of you could chime in with an anecdote of a decent one you’ve encountered in the past.

But what I will say in closing is that I think an internal framework fundamentally misses the point and is increasingly a relic of a poor approach.  Whenever I serve in a role that could be called “architect” or help a team with utility code, I treat them as my customers and try to make things that cause them to say, “ooh, how I do I get that — I want to use it.”  If, instead, their response were “meh,” or, worse, “ugh, do I have to,” I would consider this to by my failure and not theirs.

To extrapolate that thinking fundamentally alters the construct of the internal framework.  A framework tends to be an all-encompassing, opinionated way to write software.  ASP MVC, Spring, WPF, etc, are all frameworks made by professionals (or at least by people whose principal business in this context is making frameworks) for developers to use.  They require you to do a lot of things their way, and the payoff is not needing to re-solve a lot of problems.  But to get this payoff and extend this trust, you expect framework authors to be good at making frameworks.

If you work for widget company Acme Inc, your business is widget software — not software frameworks.  What you ought to be doing is abstracting common, reusable code into libraries as you might with your own internal Nuget, npm, Nexus, etc.  This allows you to avoid reinventing wheels without forcing all sorts of design baggage on developers.

The absolute key here, though, is the idea that you should always be building software, even internally, for customer satisfaction.  If you do that, you’ll be producing valuable internal work product.  If not, you’re just Comcast telling them it’s not like they have a choice.


newest oldest most voted
Notify of
Patrick Tingen
Before I started at my current employer (over 20 years ago) they went through some rough economic times. During that time, the developers actually had little to do and started to build a framework, just to pass the time. Actually, the framework turned out to be quite useful and good and was later even used by other companies. I dare to say that is was actually a very good piece of software. But that was in the early nineties. Later management decided that building and maintaining a framework is a huge task in itself, which should not be taken lightly.… Read more »
Erik Dietrich

That’s a pretty interesting development. Did the company consider spinning off a subsidiary business that offered the framework as its product?

It sounds like the framework was probably good because it was the team’s primary charter for a while and because it actually had customers. Whether it made sense for that business or not, I think that is the proper recipe for having an actual, worthwhile offering.

That’d be hard to say: usually the proof of goodness is in someone else’s genuine, unforced interest in using that, success in doing that. So it is difficult to really gauge actual fitness before releasing it to neutral external observers. In-house it may be possible to get some of that by first building it, using (doogfooding) within a team or group, and getting some other team(s), groups to try it out — but without coaxing or pressuring, and genuinely listening, observing how it fares. Biggest challenge that I have seen is that authors of the framework get attached early and… Read more »
Jose Gonzalez

This point hits home like a raging bull.

Although I’m glad to hear I’m not the only one in this situation, it’s dishearten hear this is a common “practice”.

Thank you for your practical tips on surviving this. I’ll def keep my ear open for “proprietary /internal framework” buzzwords on my current job hunt.

“Fool me once, shame on you.
Fool me twice, shame on me.”

Erik Dietrich

Glad if it resonated with you. And, for what it’s worth, I like so many others learned the hard way to listen for “we have a proprietary internal framework” as a red flag.


I have absolutely witnessed this phenomenon, multiple times, at companies of varying size, and am glad this is surfaced. “Inner platform” (https://en.wikipedia.org/wiki/Inner-platform_effect) is a related thing, and quite well-known.

Elias Zamaria
Erik Dietrich

I think I actually first heard the term “inner platform effect” at the Daily WTF website, in an odd bit of symmetry here.

David Westerveld
Good advice going beyond just bad frameworks. There are any number of dysfunctional practices at companies that can fundamentally be addressed in the same way you are suggesting. Either switch companies (carefully, b/c problems are people problems and every company has people), or build up credibility while chipping away at it or mitigating it so that you can hope to have more influence when the problem finally gets bad enough to fix. Of course, that all presupposes you are good enough at what you do, to be able to make it better when it is your turn to do so.… Read more »
Erik Dietrich

I hadn’t thought about it, but you’re absolutely right. The framework I offered for mitigation could be applied to a lot of issues people have with their jobs beyond just internal frameworks. Good point.