Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For a company that makes the same type of software over and over again, a custom MVP/MVC-like framework has been built. The obvious advantage is that it enables them to create their software faster, easier and cheaper.

However, what worries me is that such framework ( and this in particular ) hides a lot for the developers who use this framework but not actively develop it. Those developers:

  1. do not learn the itty gritties of the framework behind it ( ASP.NET MVC/WPF/Silverlight/... )
  2. cannot transfer this knowledge to other companies, which might cause devs who have become less motivated to stay anyway

So, my question: do the benefits of a corporate framework outweigh the disadvantages for your developers in the long run? Are there yet other things that must be considered?

EDIT (for clarity)

The key difference here is

  • frameworks that are industry standards, if only a little bit (.NET, Ruby, assembler, C#, ...)
  • frameworks that are not, ie: limited to a single corporation, proprietary, non-OSS, ...

I'm talking specifically about the latter.

share|improve this question

closed as primarily opinion-based by durron597, MichaelT, Snowman, Dan Pichelman, GlenH7 Jul 24 '15 at 21:22

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Similar arguments can be made for many frameworks / libraries. It is part of the way the industry works. – Jaydee May 4 '12 at 13:00
if you're talking about frameworks like WPF/Ruby/jQuery/..., those skills are kinda universal in the industry, and can be taken with you. – koenmetsu May 4 '12 at 13:05
I was thinking of a couple of libraries (VideoGrabber, ZylGPSRec) I used in Delphi. Or the proprietary framework used by our old website. – Jaydee May 4 '12 at 13:51
this same arguments could be made about learning ASP.NET over assembly. part of programming is increasing productivity by abstracting away the 'itty gritties' – GSto May 4 '12 at 14:01
@GSto with the difference that both ASP.NET and assembly are standards inside their industry. The key point is that a corporate framework is NEVER an industry standard – koenmetsu May 4 '12 at 14:11

Benefits outweigh disadvantages. My reasoning is below:


  • A lot less plumbing code allows developers to concentrate on writing business logic. At the end of the day it's a business and not a technical experiment, therefore developers should be writing business logic and re-using existing code, rather than spending hours on repetitive plumbing code.

  • Your framework will have to be maintained and extended, therefore you will always need people with very thorough understanding of your framework.

  • Normally enterprise systems require different kind of expertise related to performance, scalability and security. As your developers are no longer writing plumbing code, they can give their full attention to new challenges.


  • Developers will have to keep up-to-date with latest technology in their spare time or by working on smaller projects. This is assuming they want to change their job eventually.


I'd call this a platform, rather than a corporate framework. You build platforms on top of frameworks such as .NET

share|improve this answer
I'm not so sure about your second bullet point: will it be maintained and extended, or will it just stagnate? My experience points to the latter. – David Thornley May 4 '12 at 21:29
We constantly extend our platform and improve its performance so it never stagnates – CodeART May 4 '12 at 23:38

Software built only for in-house use has traditionally been the most common software constructed. The open-source movement may be changing that, and indeed a lot of tech companies today are releasing their non-proprietary frameworks to the world. So the firm you speak of could possibly make their framework available to the outside, though I will admit that it's still rare outside of the tech industry.

As for knowledge transfer, that's an issue even with open-source software. A programmer who used BSD, Thrift, and Nginx at one employer may be forced to learn Linux, Protocol Buffers, and Apache at another. Fortunately, most good software follows a set of common practices, which means that programmers can simply learn the quirks and nuances of a new platform while retaining their insight from previous experience. That's true even of in-house software.

And as for benefits, an in-house framework might meet requirements that simply aren't available from open-source components, like connections to legacy systems. The legacy interfaces is precisely why a company might want their own platform to begin with.

share|improve this answer
It's inevitable that abstrations will bleed. How much depends on how flexible the framework is. Apache, for instance, is a classical case of why you don't just make everything configurable. I find it easier to create a http server in python using built-in libraries than trying to configure Apache without making any mistakes. – Evan Plaice May 4 '12 at 18:32

"Programming Is Hard, Let's Go Shopping!" by Jeff Atwood covers this topic:

Being a "professional" developer, if there really is such a thing -- I still have my doubts -- doesn't mean choosing third-party libraries for every possible programming task you encounter. Nor does it mean blindly writing everything yourself out of a misguided sense of duty or the perception that's what gonzo, hardcore programming types do. Rather, experienced developers learn what their core business functions are and write whatever software they deem necessary to perform those functions extraordinarily well.


Programming is hard. But that doesn't mean you should always go shopping for third party libraries instead of writing code. If it's a core business function, write that code yourself, no matter what. If other programmers don't understand why it's so critically important that you sit down and write that bit of code -- well, that's their problem.

share|improve this answer

This arguement could be made about working on any existing code base to a certain extent. Developers with less experience who just learn how to fix bugs and copy and paste existing code to build new features are not better off.

Using a framework is a basic skill a beginning developer should learn. Even if you are using standard frameworks, there's no guarantee they're going to be used forever or at your next job.

Good programmers will take the opportunity to examine the code for the custom framework. Even if they don't get to do any hands-on production coding, they can create their own sandbox for learning. If it is built well, I think it can be a great training tool.

share|improve this answer

However, what worries me is that such framework...hides a lot for the developers who use this framework but not actively develop it.

That's a good thing! It's one of the big reasons that such a framework helps you develop better, faster, and cheaper.

do not learn the itty gritties of the framework behind it

Sure, but that means that those same developers get to spend more time making their applications work better. Instead of having to know the entire soup-to-nuts set of systems that the company uses, they can focus on just part of that problem. They get to work with their users to build applications that really make the company perform better instead of wrestling with making disparate databases work together seamlessly.

And it works in the other direction, too. The people who build the framework don't have to know anything about the applications that use the framework. They get to spend a lot of time making the framework work better. Also, if they decide to replace one (or all!) of the systems to which the framework provides access, they can do it without breaking any of the applications that use the framework.

cannot transfer this knowledge to other companies

Surely, from the company's point of view, this is nothing but good.

which might cause devs who have become less motivated to stay anyway

Is this really a problem? Are you experiencing an exodus of developers who are unhappy that they don't get to write user interfaces and do low-level systems integration in the same month?

Case Study: Amazon

I think it's pretty well known that at Amazon, they use web services for everything. They have a zillion different groups which all do different jobs: determining the prices for all their stuff, updating product information, producing product pages, producing the page you see, ordering stuff, accepting payment, shipping stuff, figuring out what things you might want to buy, and so on. It's probably safe to say that nobody in the entire company really understands exactly what every one of those groups does or how they do it. All those different groups share what they do with each other via web services. Want to know what something costs? There's a service for that. Want to submit an order to the fulfillment group for picking, packing, and shipping? There's surely a service for that. And so on.

Now, this collection of web services might not qualify as a "framework" in the same sense that we often use the term (that is, like a collection of shared libraries), but it certainly fills the same role as the corporate framework that this question addresses. Both the corporate framework and Amazon's collection of internal web services provide an abstraction, a way to use a service without having to know all about how it works internally. Clearly, such an abstraction has huge benefits, and I think it'd be hard to make the case that the existence of such a thing would by itself cause good developers to leave.

share|improve this answer
sorry, should be "which might cause devs who have become less motivated to stay anyway". Edited in question – koenmetsu May 4 '12 at 14:57
@KoMet Thanks for pointing that out -- I've updated the answer too. – Caleb May 4 '12 at 15:16
"cannot transfer this knowledge to other companies" - and, now, this provides an incentive for the more competent developers to jump ship faster. I saw a company that did this, with something more than a 50% annual turnover rate, and the ones that stayed didn't exactly strike me as the best and brightest. – David Thornley May 4 '12 at 21:31
@DavidThornley I'm not sure I understand that incentive... Many businesses consider both the structure and the content of their internal systems as highly sensitive. Further, being able to change that structure without breaking existing software could be a real competitive advantage. For both reasons, it seems pretty reasonable to expect application developers to access those systems through a well-defined API instead of accessing them directly. I don't see why any sensible developer would mind this at all. – Caleb May 4 '12 at 21:42
+1 for the first part. I see your point about amazon services, but I don't see how that answers the question. – CodeART May 4 '12 at 23:47

Speaking from experience, the company I currently work for was born from a need to provide programming services (back then, you wrote custom programs at the client rather than distribute same software everywhere) for a very old IBM mainframe which was common for business back in those days.

I was hired long after the birth of my company, though I've noticed an emerging trend. There are programmers which have the continual burden of having to maintain old code on the old systems and then there are programmers which merely have to interface with old systems rather than be built on them. I think to myself, if any one of these older programmers got fired, they'd have great difficulty finding a new position somewhere else, but not because they know no new programming languages but because they can't think like a modern programmer (encapsulation, inheritance, OOP, MVC, etc.).

Ultimately my conclusion is that the ability of a programmer is only as good as the way he thinks rather than which technologies he knows. Often the two are coupled, since learning new technologies often means thinking in a way which allows the learning of similar technology in a much faster manner.

I don't think anyone can be expected to know all the technologies of a new company in and out.

share|improve this answer

In my experience, the team developing The Framework (tm) is the one having all the fun. The team using The Framework is usually just gluing together XMLs (or whatever) and not really learning anything interesting.

Add to this that (again, in my experience) companies developing internal projects such as The Framework usually fail to understand the advantages of industry practices. I'm thinking of every company that ever tried to implement its own ORM or persistence framework.

Usually, unless you want to get stuck being the end user of a poorly designed corporate framework which won't help you hone your development skills, it's best to start looking for another job.

Life is too short to waste on a job you don't find interesting.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.