Saturday, February 6, 2016

ZEN Programming and Building In-House Frameworks (aka YAGNI)

ZEN - Zero Extra Nuts. ZEN code is minimalist. It is relentlessly focused on solving exactly the requirements and nothing more. (3)
Write only what you need. It’s a profound concept. Engineers can’t help but overbuild things. For some reason this is inherent to being an engineer. In physical engineering, overbuilding is mostly an issue of up-front cost in terms of extra time and material. In software, there is also a substantial ongoing expense. The maintenance cost of code is related to its total size (1).


ZEN implicitly includes DRY (don't-repeat-yourself). Code repetition is one of the most pernicious forms of "Extra Nuts." Learn more about the subtleties of code repetition here.

ZEN and Frameworks

Minimizing the size of the code-base is an important goal. Using standard abstractions like functions and classes can reduce the total codebase size. This isn’t the same as building a framework.

What is a Framework?

A framework is a module. At their heart, modules are about encapsulation. Modules have an external interface and internal implementation. Better modules have simpler interfaces and more-isolated implementations.

Frameworks are different from other modules because they are designed to be used across multiple applications. Frameworks must be the best possible modules. In order to work across multiple applications, a framework must have the simplest possible interface and the most isolated implementation. Frameworks should also have their own codebase and be packaged for easy reuse.

Why Do We Build Frameworks?

If ZEN were the only value, we would never build frameworks. By the time we’ve built a solution to the required specs, we ship. End of story. That’s what ZEN tells us to do. If we only followed ZEN, our applications would include operating systems, drivers, database, compilers and every other part of our dev and runtime stack. In other words, each new application would be enormous and have a fraction of the capabilities we enjoy today.

I said above that the maintenance cost of code is related to its total size. When we measure the size of code in an app we do not include frameworks. This is for good reason. The complexity a module adds to an app is proportional to its interface size and leakiness of its implementation. Frameworks are the best of modules. Their leakiness is minimal and their interface refined. A framework with millions of source-tokens may only add a few thousand tokens worth of complexity to a project using it. 

Are In-house Frameworks Worthwhile?

Clearly using other people’s frameworks is a big win. You get 100x or more leverage in terms of complexity. You only have to maintain your application’s code base and you get all the framework’s capabilities for a very modest price. Building a framework in-house at first doesn’t seem like a good idea. The total code-size you have to maintain will increase when you take an application and factor it into an in-house framework plus the rest of the app.

We talked about how application code-size is properly measured, but we haven’t talked about how that value relates to maintenance. Maintenance costs are proportional to complexity, and complexity’s relationship to code-size is non-linear. If you double the code-size, you will more than double its complexity (2).

Realizing that code-complexity is non-linear in code-size reveals why it makes sense to write frameworks even if they only have one app using them. If the application’s code-size is N-tokens before we factor out the framework, and let's assume that we can cut the application code in half by factoring out the framework. There is always some overhead in writing a framework due to interface and abstraction code. We’ll assume that overhead is 10%.

After the split, both the framework and app will have (1.1 * N/2) tokens, or (1.1 * N) total. For simplicity, our final assumption is a complexity-to-size factor of O(N2):

  • Complexity before split: N2
  • Complexity after split: 0.6 * N2
    • App: (1.1 * N/2)2
    • Framework: (1.1 * N/2)2
    • Total: 2 * (1.1 / 2)2  * N2

That’s a 40% savings! Granted, I made the favorable assumptions, but clearly it is possible to have large savings. Further, you don’t have to limit yourself to making just one framework. There are diminishing returns, but in my experience I've still found improvements with over 10 in-house frameworks.

Once you have a good framework, it is possible to re-use it in other apps. Then the savings really start to compound. If we assume just two apps, using the example above, the complexity savings increase to 55%. You also get code-size savings as well - about 18%.

When to use 3rd Party Frameworks

Obviously you should use an existing framework, if one exists, instead of writing your own. Right? Well, when evaluating the merits of a 3rd-party framework, there are a lot of things to consider. 

Let's start with technical aspects:

  • Does it do what you need it to do?
  • Does it meet your performance goals?
  • Is the source open?
    • Can you look at the source code? No matter how good the documentation is, there are always questions it doesn’t answer. If the source is open, you can get definitive answers. If not, you will be flying blind.
  • Is it OpenSource?
    • Can you contribute improvements back to the project?
    • How clear are the maintainers about what sort of contributions are acceptable?
    • Can you fork the project? This is only a last resort, but it is nice to have as an option. If you expect to fork early, you will be mostly maintaining your own, in-house framework. The problem with this is it is a codebase no-one in your organization knows well. Seriously consider writing your own in-house framework from the start.
  • How difficult will it be to switch frameworks later? 
    • How much of your code will directly interact with the framework?
    • If you are picking a UI framework, most of your code will be tied to that framework. Changing frameworks later probably means rewriting the app from scratch.
    • If you are using an encryption framework, like, say, md5, only a line or two of your app will use it. Changing that framework later is usually trivial.

There are also important non-technical aspects to evaluate:

  • Momentum. Usually there are multiple options for the same type of framework. Eventually, some die out and some thrive. It’s a good idea to use a tool like Google-Trends to determine which projects are thriving and which are dieing. If a framework dies, you may need to fork it to maintain it, and then you are back to maintaining an in-house framework.
  • Direction. 3rd party frameworks evolve outside your control. It is important to not only assess the current technical merits of the framework, but also, where is the framework going? What values and goals does the controlling team have? What values and goals does their organization/funding have? If your use-case is not squarely in their target use-cases, seriously consider looking elsewhere.

When to Write an In-House Framework

There are two main questions to ask each time you consider building a framework:

  • Is it the best of modules?
    • Is the interface simple?
    • Will the implementation be well isolated and minimally leaky?
  • Is there a reasonable chance you’ll reuse the framework on other projects? ZEN argues you should be cautions making assumptions here, but if you think there is a > 90% chance you’ll reuse it even once, this can be a big factor.

If you haven’t written a line of code yet, should you even consider writing a framework yet? You should never write something unless you know for certain you will use it. Don’t build more than you immediately need for current requirements. In this, you should always follow ZEN.

However, when looking at current requirements, it is reasonable to ask how you are going to meet them. As you do, you will be considering how to modularize your implementation. If you are doing an agile approach, this design work will happen in code as you go. If not, you may be doing some up-front design. Either way, there will be a point where you have modules.

As soon as you start to form modules, you should start thinking about if the modules make sense as a frameworks. If the answer is “yes” to both questions above, then package up the module immediately, put it in its own code-base, and declare it a framework. The sooner you do it, the sooner you can reap the simplification rewards. Once you do, keep following ZEN. Continue to only add functionality as you need it.

Frameworks Clarify Thinking

Frameworks have another benefit beyond reducing complexity. Once you have isolated part of your code in a framework it takes on a life of its own. It has purpose beyond just serving the current app (though it should still be driven by that app's requirements ala ZEN). A framework begs for clarity in its purpose. By drawing a line between your app and your framework you have to start thinking clearly about what belongs where. 

Don't expect to nail the framework's "purpose" in the first pass. Your framework will evolve as ZEN drives it. Over time, though, clarity will emerge and you will have a new, powerful tool, codified in your framework, but also in your mental toolbox for solving and thinking about programming problems.

Writing Frameworks is Hard - and Worthwhile

I don't want to make this seem easy. Writing the best of all possible modules is hard! However, it is a learnable skill. You are only going to learn a skill be practicing it - a lot.

And what about ZEN? Writing frameworks and ZEN are not in conflict. You can write frameworks while observing ZEN. After all, DHH, one of the strongest proponents of ZEN, wrote Ruby on Rails.


  1. I measure codebase size in parse tokens rather than lines of code. Though still only an approximate measure, they are much better than LOC. They are the smallest meaningful unit in code. LOC measures several aspects of code which are ignored by the compiler including comments and whitespace.
  2. Codebase complexity can be understood in terms of graph-theory. Complexity comes from the number of possible interactions within the code. In the worst case, if you have N bits of code (tokens), you can have as many as N * (N - 1) or roughly N2 possible interactions. In practice the relationship between code-size and code-complexity is somewhere between O(Nk>1) < CodeComplexity(N) < O(N2).
    Modular design is all about reducing the number of interactions a chunk of code has with the rest of the code-base. This is how modules help reduce complexity.
  3. ZEN is roughly the same concept as YAGNI, but unlike the latter, both the word 'zen' and the expansion, 'zero extra nuts' convey meaning. We can say some code needs to be more 'zen,' and others will understand. To say code needs to be more 'yagni' holds no meaning for most people.


  1. Thank you for posting a great guide on frameworks and this is really needed by the people of many engineers and this is a really informative post.

  2. Your house is a direct reflection of who you are. If you don't like your home, it may lead to greater frustration in your life. Make the best use you possibly can of the spaces within your home.
    bling home decor

  3. In any case, regardless of whether you don't have any plans of moving out of your home, you can even now proceed with a washroom renovation plan as it will add magnificence to your home just as a calming consolation in your way of life.check this website

  4. This comment has been removed by the author.

  5. First of all, A+ as we mentioned before is a descendent of the "A" programming language, it was created by Arthur Whitney in 1988 at Morgan Stanley.list of IDE for PHP

  6. Thanks for posting this info. I just want to let you know that I just check out your site and I find it very interesting and informative. I can't wait to read lots of your posts. best trim paint brand

  7. A good renovation project offers you the opportunity to add more beauty and value to your home, but it will be even more successful if you're able to use that project to lower your energy bills and reduce your carbon footprint.SubZero, Viking Refrigerator Repair Manhattan Beach

  8. Your website is really cool and this is a great inspiring article. residential painters

  9. I really enjoy simply reading all of your weblogs. Simply wanted to inform you that you have people like me who appreciate your work. Definitely a great post. Hats off to you! The information that you have provided is very helpful. layout design of house

  10. Really nice and interesting post. I was looking for this kind of information and enjoyed reading this one. Keep posting. Thanks for sharing. 3D elevation of house

  11. Really impressed! Everything is very open and very clear clarification of issues. It contains truly facts. Your website is very valuable. Thanks for sharing. layout design of house

  12. They don't frequently have sufficient yield for extensive vitality recharging, however can be utilized to softly charge a battery bank. Installateur zonnepanelen

  13. The appealing fragrance of fresh wood endows the cabin with a natural comfort befitting a vacation home. No car air freshener or scented candle can compare to the alluring aroma of natural wood.Land for sale near Clinton Missouri

  14. Thanks for sharing this valuable and meaningful blog with us. Visit OGEN Infosystem for responsive website design and SEO Services at affordable price.
    SEO Services in Delhi

  15. Point out smoke alarms and remind the sitter that the local group of fire-fighters ought to be called if an indicator goes into alert. 911 ought to be utilized for this call. Babysitters

  16. Excellent post. I don't know well if it work for me.

    Neeti Mohan Songs Lyrics

  17. While there are a huge number of programming languages, many of them have a lot of similarities; this means that once you learn one language quite well, in most cases you will be able to pick up a new one far ergonomic chair

  18. This blog is a punchy piece of writing, as it has a strong effect.

  19. Thanks for taking the time to discuss that, I feel strongly about this and so really like getting to know more on this kind of field. Do you mind updating your blog post with additional insight? It should be really useful for all of us. instagram likes purchase

  20. Hold the rise of celebrity chefs responsible for this one. Kitchens with every appliance imaginable and too much space can be off-putting to perspective home buyers who do not engage in serious entertaining. ajax townhomes for sale

  21. It is unimaginable to expect to define impeccable framework architecture the same number of the parameters involved in forming that architecture will change over the lifecycle of the framework.rome italy

  22. Thanks for this valuable information sharing with us. Visit Kalakutir Pvt Ltd for Epoxy Paint Flooring & Coating and Food Truck Branding services.
    Epoxy Paint Flooring & Coating

  23. One-North Gateway Residences by TID. Hotline 61009266. Get Discounts, Direct Developer Price, Brochure, Floor Plan, Price List & More. New Condo @ One-North. One-North Gateway

  24. When using a home builder, one can research candidates through the National Association of Home Builders, roommate finder USA U.S. Green Building Council, Better Business Bureau and of course via online blogs and forums.

  25. Amazing Blog, thanks for sharing with us. Enjoy Everest Base Camp with Gokyo Ri and Everest Base Camp Three Passes Trek with full guide and safety at Protrek Adventure.
    Everest Base Camp with Gokyo Ri

  26. This gives the WordPress module engineers and topic planners an opportunity to test their work with the new form and to discharge another rendition if necessary, which you can move up to simultaneously. error establishing a database connection

  27. nice

  28. An actual handyman is the only person that can simply aids you in home based developments plus a number of other movements. There are several handyman services that you can easily receive from the handyman, like, drywall restoration, front door maintenance, home window maintenance, skylight installation/repair, devices maintenance, gardening, floors repair, Commercial Slatwall & Shopfitting, and even more. You can visit here our website and get more information about Handyman Services.

  29. I have recently started a blog, the info you provide on this site has helped me greatly. Thanks for all of your time & work. הסכם קבלן שלד

  30. you should recollect that numerous projects have taken entire groups of master engineers a long time to make. excel vba training london