Thinking about Zipf's law when coding

The inspiration

This article started when I watched The Zipf Mystery on YouTube. Michael (aka VSauce) explains Zipf's law in details there. In summary this is just showing that many things naturally follow a logarithmic rate of occurrence. This gives rise to the Pareto Principle aka 80/20 rule which has several impacts within computing code.

My thoughts

As I was thinking about all of this and how it impacts the code that my team commonly writes it struck me where we experience this 80/20 rule everyday. Writing application code is really writing the 80% of the application that is only 20% of the execution.

For Example: If you write a business application using ASP.NET and MVC, what you are doing is adding 80% of the code needed which accomplishes the business goals. That 80% of the code though only accounts for 20% of the application execution.

Now think about the ASP.NET MVC code that our code is built "over". That code is only 20% of the code, but accounts for 80% of the execution - it's executed on every request, not just when the specific function is requested.

Here we can see just how the first 20% accounts for about 80% of the execution. Whereas our 80% is only executed 20% of the time, but it provides the width of functionality that accomplishes the specific business goals.

Take-Away

My take away is that the bulk of developers spend most of our time focusing on the wide business needs. This is very different from creating code that establishes a very effective framework. For some of us that's great - but I think we should all challenge ourselves to dig into the hard stuff and write some framework-capable code. Doing so opens us up to thinking about execution differently.

Why it's hard

1. It requires starting from zero. This is a different kind of thinking. From blank you must come up with the M-V-C interaction. You must "own" the methodology. Coming up with and reasoning this out is not natural for many of us. We want a framework to work within. Writing a framework requires one to frame the generic problem (e.g. M-V-C = data-presentation-logic separation). Maybe there are still better ways to frame things? Maybe data and logic should not be separated, isn't that the DDD approach? Why does DDD still hide behind M-V-C in Web App development?

2. You must think about someone else's code. How do you make things work well for them? How can you keep things flexible? How will they think about their problem within your framing?

3. Documenting your code is very critical. Intellisense comments are critical for the consumer to be able to quickly understand what happens. For example, consider a Car class with a Start() method. Without intellisense, your caller must assume whether you mean Start Moving or just Engine started. If this used only in 1 part of an application that's one thing. But if you're writing framework code, we must assume everyone will need this method, and must understand it's purpose clearly.

4. Testing absolutely critical. When you write code that will be called so much, you must test into all the edge cases, and capture more as your work progresses. If not, your bugs will account for 80% of the bugs.

Why we should all do this

Writing code and thinking along these lines pushes us to different limits. While I realize this isn't for everyone I do believe everyone can learn from this exercise. If nothing else, it will help us to examine our own coding, testing, and documentation.