Downfalls of a Framework

In the world of big software projects, frameworks are common place. Frameworks attempt to make common activities easier to do. They promote code reuse and try to reduce the time it takes to write software. But what are you giving up when electing to use a framework? Let's take a look at a few of the disadvantages of using a framework and some things to consider when choosing a framework.

Downfalls

Architecture

In creating a framework, there are necessary architectural decisions to make in regards to how the framework will operate and how it will interact with other frameworks and libraries that may be used in conjunction with it. Because the framework is designed to solve specific problems, it may limit the architectural patterns you'll be able to use if you elect to use the given framework.

Design Patterns

Similar to architectural limitations, the framework designers also chose a certain set of design patterns to implement. In so doing, this will occasionally limit the design patterns you as a framework user can implement in your project. While in some cases this is rarely an issue, it quickly becomes a large obstacle if you encouter it. Trying to get a framework to use a design pattern it doesn't support is no easy task and often ends up with some ugly code.

Domain Specific Language

When learning a framework, some have added so much to the language they're based on that you're not really using that language anymore. The framework has become a Domain Specific Language on top of the underlying language. For example, when learning Angular, it could be argued that you're really learning Angular and you're not learning JavaScript or TypeScript. Similar things could be said for Spring or any number of other frameworks regardless of language choice.

Learning Curve

Another downfall is that the learning curve for the framework is often fairly steep. One reason for this is the topic we just discussed: they're often a Domain Specific Language. Another reason is that you might not be familiar with the problems the framework is trying to solve in the first place. If you don't know what problems you're solving, it can be hard to learn the solutions to them.

Playing Nice

One other issue that I've personally run into on a number of occasions is that frameworks don't tend to integrate well with parts of the system that aren't written in that framework. For example, if you have something outside of Angular that wants to execute a function within Angular, it's nearly impossible to do it. There are ways, but they're usually discouraged, hacky, and overly complicated. Similar things can be said for most other frameworks regardless of language or environment. Most frameworks have their "way" to do things and that "way" might not be easy to do from outside of the framework. This aspect doesn't affect new projects, but it can be a major issue when dealing with legacy systems.

Framework Considerations

So, with all these disadvantages, what's one to do? How do they choose a framework? Well, if you've decided that a framework really could clean up your project and make it easier to use, here are some questions to consider when evaluating your options:
  • What problems are you trying to solve? Does the framework address those?
  • What architectural constraints are you working with? Does the framework easily work within those?
  • What design patters would you like to use to solve the problems you're anticipating in the system? Does the framework allow you to use those?
  • Am I willing to accept the learning curve? Do I fully understand the impact that will have on the delivery team(s)?
Ideally you'll have done enough research, prototyping, or actual coding to know the issues your system has or will have. Once you have a good idea of the problems you're trying to solve, you can start narrowing your search for a framework that addresses those issues. Working the other way around can often lead to messy code bases that would have been better off if no framework were used at all.

Next time you're wanting to use a framework, keep in mind what you're giving up. Also be aware of the needs of your system before blindly choosing a framework. Your development teams will be much more efficient if the frameworks are carefully selected.

Comments

Post a Comment

Popular posts from this blog

A Common Technical Lead Pitfall

"That item is nearly done. I just need to run it past the team lead to make sure it's good to go." Have you ever heard a phrase like that? What about something like this? "So, I had that finished and then I ran it by the team lead and he made some great suggestions to make this more reusable. Unfortunately I'll basically have to rewrite the entire thing, but it should make it easier in the future." Do you see anything wrong with either of these scenarios? What about this one? "The team lead is out of town, so that item will have to wait until she gets back so she can look it over." Situations like these come up every so often in development. There are some simple solutions to each of these. With the last one, the team lead should have designated someone to act in her stead while she was out. In the second one, the poor junior developer should have worked closer with the team lead from the start. The first one, though, isn't really an
Keep reading

Maze Generation in JavaScript

Image
This article will outline the algorithm for random maze generation with backtracking and show code examples of the steps of the process. This algorithm is obviously useful for random maze generation, but the concepts can also be applied to other areas where random input or path generation is needed. The basics of this algorithm are as follows Initialize an object to track nodes that are visited Generate the nodes in the maze. Generally you'll want to track the node's edges. You may also want to give the node an ID of some sort. If you want to cut down on recursive calls, you'll also want to track its possible edges (aka all its neighbors). You'll also want to store this as an object instead of an array as it speeds up lookup times. Choose a starting point in the maze Mark the node as visited while there are potential neighbors to visit Randomly select a possible edge to visit Add that node to the edges for the current node Add the current node as an edge on the selected
Keep reading

Leadership Experiment Update 2

This week was a bit of a slower week. A number of people that usually participate in the channel were out of town. Even still, we had some decent thoughts on these two articles: Every Day We Must Sweep and  From Engineer to Manager: keeping your technical skills . I'd like to share one observation I made: Be Vulnerable Often times as leaders we think we need to appear invincible. For some reason we think in order to lead, we can't show weaknesses. While that may be a good mindset to have towards an opposing force in war, it doesn't work well towards those you lead. If you want those you lead to follow you, you need to be vulnerable at times. You need to show them your weaknesses and how you overcame them or how you're overcoming them. This doesn't mean you need to be publicizing your weaknesses, but it could mean recognizing them when they come up naturally or sharing stories about them while mentoring and coaching those you lead. Why Be Vulnerable?
Keep reading