OK, I’m exaggerating a little here, company-specific software frameworks aren’t exactly evil as in the true definition of the word but who isn’t fond of the occasional hyperbolic headline?
What I’m trying get across is that most of the times, software frameworks developed within an organization specifically for solving that organization’s business problems in a reusable, maintainable manner do more harm than good.
Everybody who’s been exposed to enterprise software development for longer than a very brief period has come across them in one variety or another: Internal frameworks. These frameworks tend to have grandiloquent (but otherwise meaningless) names – preferably from classical antiquity – such as Osiris or Prometheus. Sometimes, they’re just known as THE Framework and are only spoken about in a hushed voice among fellow developers.
A variation of the Not Invented Here (NIH) syndrome they purportedly help with hiding all the nasty, dirty technical implementation details so the software developers can focus on the nitty-gritty: Implementing business solutions.
While this certainly sounds extremely useful in theory (which probably is what makes the idea so alluring), in practice – at least from my experience – these frameworks often fall short of this goal. They’re prone to exposing leaky abstractions. They become opaque and highly complex surprisingly quickly. They allow for a more or less easy implementation of a limited set of use cases while sometimes making unforeseen or edge cases extremely difficult or impossible to solve, which then either means putting in tremendous effort for adapting the framework or scrapping it altogether and starting from scratch. Apart from the limited amount of use cases they were originally designed for, they usually create more problems than they solve. Even worse, they create distraction and deflect resources from solving the actual problems at hand: “Product release deadline in 2 weeks? Screw it. Let’s create another slew of abstractions and a host of additional funny classes whose purpose nobody will be able to explain in non-abstract terms instead! It feels like work so it can’t be bad, can it?”
While this to some extent is probably true for every framework, no matter if internal or general-purpose, internal frameworks are especially vulnerable to this kind of development, so my personal, opinionated recommendation is: If you feel the urge to create an internal framework for your next project pause for a moment and ask yourself if you really need this framework or if your time isn’t much better spent elsewhere.
Writing a framework and solving business problems are two entirely different disciplines. Not everybody is an architect or a framework programmer and that’s a good thing. There are more business problems out there than there are abstract software architecture problems still in desperate need to be solved. Chances are that the set of abstractions you think you need right now has either already been implemented by somebody else or it isn’t really needed anyway but rather a convenient distraction from the complex, tedious details of implementing a particular business solution you’re working on right now.
Now, I can understand the sentiment: Business solutions tend to be short-lived. Programmers want to create a lasting impression, create something others will happily use and praise the author for. Well, guess what, unleashing yet another company-specific framework on the world might indeed make future developers remember you. It’s quite likely though those won’t exactly be fond memories and your name will be cursed for generations of developers (again with the hyperbole …). So, instead of falling for this fallacy, make sure your solutions are maintainable, readable and comprehensible. This allows others to learn form your examples, build upon and easily modify them as needed. The software business is a fast-paced one, no news here. Things are moving much too quickly for rigid frameworks that are difficult to adapt to use cases the original author didn’t think about half a year ago.
That said I absolutely recommend design patterns and general-purpose practices such as Clean Code. Patterns and best practices allow you to structure your application in a transparent, maintainable fashion with reusable bits of code while staying flexible enough to adapt as needed. Furthermore, patterns not only are useful for structuring code but they’re essential for creating consistent, easy-to-use user interfaces and a delightful user experience. Ready-made UI frameworks such as Bootstrap or Foundation allow you to use tried and tested UI components instead of inventing your own components. Furthermore, design languages like Material Design by Google and methods such as Atomic Design allow you to create a clear, consistent and coherent user experience for your organization. Unlike rigid specific-purpose frameworks these tools and methods can be easily adapted to changing requirements.