I am in Darwin for Christmas. This is where I grew up, went to University and came back to work for a very short time in 2010 while trying to work out whether I wanted to stay and face the challenges of my profession.
It was very a short stay because this place is like many small Australian cities - there is a need for IT but it is satisfied by a small pond populated by a lot of medium-sized fish acting like sharks. After a very short time, that gets old.
My career is about focussing on building software that people want to use, not flexing my under-developed biceps and splashing wildly in a muddy pond. So while I was here, I did my best to learn something from the situation and not cause too many ripples. Yeah, me... the ripple maker.
As I walked in to different clients, developers on the client-sites kept asking me what frameworks I had brought with me. At first, I smiled and said .NET but then I realised they meant bespoke frameworks that I had created. They wanted to know what I carried in a swag on my portable hard drive that helped me build systems. In their case, this was for small systems of simple client-sever apps. And every dev had their own framework.
You're probably wondering what I mean by a small system. In the context of software, it is a system that services a small number of concurrent users and does not require capabilities like scalability and robustness under load. Yes, yes, you may argue all systems do but for more affordable systems with simple requirements that change infrequently, this can seem like over-kill. The developers who build these know that they are coding write-once applications. So the bits they do find themselves repeating on the next project, they build reusable frameworks for. These frameworks can then be used over and over again as they build the same designs over and over again. Reuse. Good, right? University told us reuse is good.
This is not that different to what I have seen in a lot of medium to large organisations though. It seems more common in groups that build small systems but it does cross all worlds and all demands. The difference is that the big places don't ask for my custom framework. They instead tell me about theirs.
The Problem With Your Custom Framework
Every piece of software you implement. Every line of code you write. Every ounce of effort you exert in making the machine grind should be traced back to a requirement that a user needs in order to achieve their goal while using the software.
If you've worked with me then you still have my voice in your head droning on about the importance of requirements traceability. For the rest, expect a blog post in the very near future.
Custom frameworks are not an exception to this rule. In fact, they are the one part of any system that should be justified to kingdom come. If you can't find a business reason to build it then don't. I have very few to no exceptions to this rule.
Now, the reason this is important is because software has to be maintained. It must be extensible, robust, reusable, testable and above all else relevant. The software should never be held back by the tools and materials used to build it. They are not important. The end-user software is.
If the requirement of your job is to build software that other software uses to satisfies its requirements then framework away. If not, then you will spend a lot of upfront effort and infinite future work maintaining your framework just to keep it relevant to the systems it consumes.
People like Microsoft have many teams of many elite developers building many generic frameworks for you to build your castles upon. Unlike the sand that yours will be built of, theirs are backwards compatible, constantly updated and relevant. All you have to do is recompile or re-consume their changes and keep focussing on your business needs. You focussing on supporting multiple systems and stalling natural evolution and progression is more detrimental than helpful.
In most cases, there are two reasons developers insist on building their own frameworks. The first is that they took what they were told at university about reusability to mean that they must reuse code or they have failed. The truth is that design patterns are more reusable than code in a lot of circumstances. If you do need code reuse for one system, it will not often translate to another system unless great care is taken in the first place to design it that way and the agreement to maintain it is consciously agreed to by all parties including business.
The second reason is that developers like to build stuff that they can point at and say they built. I think this is sad and verging on the point of needy. As far as I am concerned, I should be able to look at a code base and have no idea at all what each developer wrote. Code is not about a developer tagging the mountain of obfuscated code that represents their prowess to others. It is about making something that can exist long after your are gone.
Let the nicest thing anyone said about you be that your code was clean, correct and easy to understand.
How To Know Your Framework Is Holding You Back
If you spend time justifying why systems dependent on your framework can't be advanced to later versions of general software (like newer version of .NET) then your framework is not helping.
If you write a new system with exactly the same design as the last system then you must ask yourself if you are solving the problem domain or complying with the saying that if all you have is a hammer then everything looks like a nail.
So You're Saying My Framework Should Be Thrown Away?!
Most frameworks are built to satisfy a need that an underlying framework (like .NET) does not yet satisfy. As soon as that general framework does, you should deprecate your compensation.
Stop wasting your time working out the best way to forge steel and instead buy it from the great steel works and then go about constructing great structures.
I'd much rather build the Empire State Building upon the shoulders of others than a half good piece of metal alloy that may or may not support a bridge tomorrow.