Frameworks, What Are They?

Here is an example of a framework.

You (on the left) want to reach your users (on the right), across a great chasm. The scaffold at the middle is your starting base framework. It's the System.out.println of Java. It's the Cocoa framework that iOS provides. It's Node.js for your backend servers. It's the Elastic Load Balancer on your AWS stack.

So when using this framework to complete the chasm, there are two methods. You can either,

1. Use it, or
2. Build on top of it.

Using the framework looks something like this:

You have accomplished your goal of reaching your users. But it's obvious that any extra stress on this structure will collapse. See my post on why managing stress and scale is essential to growing your product and company.

It's appropriate to use a framework for

• hackathons, and
• prototypes or proof-of-concepts.

Honestly that's the only two valid reasons I can think of for straightforward use of a framework.

"But what about agile development of MVP (Minimum Viable Product)," you ask?

I'll explain more when discussing building on top of frameworks, which looks something like this:

Notice that when you build on top of a framework, you're using the same pattern of structure that the base framework is composed of. In fact, you are extending the base framework, and building a framework of your own. 

You've added a little bit of compound interest to the world of software. If you do it right, this can be used by other people for similar chasm crossing type of problems. In fact notice the simple bridge that finally spans the chasm. If someone with a similar problem, but a wider chasm, they can copy the bridge but extend it further.

Also notice that this structure is more stable. It can bear load without breaking. It can scale without having to be torn down and re-built if the chasm were to increase, or the cliff become higher. Which will happen if you are expecting to be successful.

What about MVP? 

As the product owner, how can you expect your developers to spend all their time and energy building these structures? You need to move FAST, you don't have time for these shenanigans. 

The fallacy you're making is that it takes more time to build these structures. 

Remember that you're re-using already existing patterns from the base framework. So developers don't have to think about new ideas and new solutions, which will come with new problems and new corner cases. A developer experienced in frameworks and common design patterns can build one of these just as fast as the developer who just uses the framework.

In fact, I will attest with experience that building on top of a framework is FASTER because you will save time in the future from de-bugging and re-building when situations change.

Common framework mistakes

You have heard of the term over-engineering, Here is a depiction of what over engineering may look like:

If just using a framework is too cold, and building on top is just right, then over-engineering is too hot for Goldilocks to handle.

Some reasons that lead to over-engineering are egotism and impatience.

When I was a young developer, it was boooring to use the old tried-and-tested methods. Even as an experienced developer, the ego creeps up, and I think "I could integrate this common library to solve this problem that's been around since the beginning of time... OR I can build my own! Wouldn't that be fun??" And the answer is usually NO. Usually though, taking these detours is a great source of expanding my skills and knowledge as an engineer. But still, for the sake of your business, limit these meanderings.

Sometimes, I just don't want to spend time reading documentations and blogs on a topic. I'm ignorant of being ignorant. So I'm just going start doing something without researching if there's a solution already out there.

There's also a lack of appreciation for simplicity. It's an ego boost to be able to create something complex, something hard to understand for anybody else without my "great" mental aptitude. Who else would have thought to solve that particular problem with a frigging catapult?? The answer is no one who's experienced.

Compound interest and the Information Revolution

There's a well known urban legend about Einstein saying that compound interest is the most powerful force in the universe. Even if he might not have said it, I think he probably did appreciate the power of incremental growth. There are other common phrases like "standing on the shoulders of giants" that illustrate the same point.

Frameworks are the compound interest of programming.

A framework is a vague term in the software industry. So is a library, API, module, node, package, and so forth. They're all either related, or they all mean the same thing. It depends on who's talking and how they're using the terms.

The general idea is that a framework is something used to solve your problem, and most likely you didn't build it. For programmers, it's a relief to not have to build something, not because we're lazy, but because we know we'll just mess it up the first time. There are frameworks/libraries/packages out there that are old and reliable, all the bugs have been hashed out with use.

Frameworks are the reason why software has become such a world shifting power. In the past half century, electrical and software engineers have been incrementally growing the seeds of ideas such as Unix, HTML, Javascript and hundreds of other components. Now some of these have matured and offer tremendous leverage, allowing one person now to do the work of 100 people ten years ago, and the pace of growth is also speeding up.