The Pareto Principle Applied To Software Development
Being a software developer and writing good software is incredibly hard.
As developers we find ourselves in a knowledge economy. He who has the most knowledge is most valued. This problem is not unique to software development, but rather a reflection of the age we live in. Unlike other matured fields of knowledge, software development is truly much younger. Accounting as a field, has it’s origins in ancient Mesopotamia, it’s thousands of years old. In startling contrast, the first programmers can be tracked back to the 1800’s with the Jacquaard loom. An apparatus for making fabric by weaving yarn or thread. The Jacquard loom first demonstrated in 1801 was controlled by a chain of punched cards. That’s 216 years. Software engineering as a practice only started around the 1960’s. The inherent immaturity of this knowledge domain lends itself to uncertainty and untested practices often leading to high costs. We are progressing but compared to other fields we are still babes in the woods.
A side effect of this immaturity is the rate of change we are seeing in the theory and practices of software engineering. As one possible example, consider that since the 1950’s we have seen 43 new programming languages on average every 10 years. That is astonishing. With each new language, comes a new domain of knowledge, tools, libraries and best practices. You only need consider Javascript at the moment, and the rapid software development cycles we are seeing in tooling and libraries (diagram below). Now span this across all the languages. How does the developer keep up? How does he hone his skill and stay current?
The Overwhelming Body of Software Theory
The short answer is you can’t. There is too much knowledge and too much practice for one person to consume and so we narrow the scope. Let’s say we stick to one language like Ruby. But to be any kind of Ruby software engineer, you need to have knowledge of multiple domains. As part of the software engineering field — you need an understanding of software design which is a huge field (design patterns, implementation patterns, architectural patterns). Then there is Automated Testing (BDD, TDD, Integration Tests, Acceptance Tests etc). Then Data Structures. Algorithms, Programming Languages, Tools, Native Libraries, Third Party Libraries, IDE, Text Editors etc. Even beyond that, stepping into other fields, we have huge demand for Mathematics in the Machine Learning space, Network protocols, Infrastructure management, OS Fundamentals, Security, Project Management, Agile etc. Even in a narrow stream the amass of knowledge and information is overwhelming (for me at least). This is the tension I’ve felt over my career, which stirred feelings of anxiety which often led to paralysis.
The First 20 Hours and The Pareto Principle
Recently I found a cure for myself, leading on from the book; The First 20 Hours by Josh Kaufman. Josh Kaufman goes on to describe how anyone can get seriously good at learning anything and be effective in the first 20 hours. Very simplistically the strategy he gave boiled down to:
(1) Plan, Think and Assess what you actually want and why.
(2) Get expert guidance to better guide you and aid your learning
(3) Finally, Learn only the skills you need to accomplish what you actually need
I’ve combined that along with the Pareto Principle.
The Principle States that…
20% of the invested input is responsible for 80% of the results obtained
Combining these concepts, two things became apparent (a) any knowledge domain could be learnt quickly and sufficiently to be effective (not mastery); (b) amidst all the theory and practice that embodies a domain of knowledge, knowing only 20% of that is necessary to deliver 80% of the result.
If a developer was tasked with developing a new Product service in a new programming language (Ruby). The first steps would be to break down the Product service into smaller pieces (smaller problems). Once the developer is clear on the smaller problem spaces, he or she would then tie those small pieces to knowledge areas and what knowledge is needed to meet those areas. So instead of reading a whole book on Ruby, the developer would focus on those constructs and syntax that are relative to what he needs to get done. The learning is singly focused and structured towards specific problems.
Recently, at our workplace we had a mini-revival of Design Patterns, I felt completely overwhelmed because people were discussing so many of them and Imposter Syndrome kicked in. I set out to re-focus my attention on the area of Design Patterns and ramp up. I was prescribed 4 books — Design Patterns In Ruby, POODR, Implementation Patterns by Kent Beck and Enterprise Patterns. It was at this point I realized the Pareto Principle, that in actuality, when I reviewed our various git repos, there were predominantly 4 clear design patterns that were used repeatedly. Stepping back even further, I recognized that though certain people talked about some design patterns, they had never implemented them or rarely used them. I shifted my focus to the 4 design patterns. Mastered them and through time got to read 3 of the 4 prescribed books. Hoping to crack the last one this year.
The pressure to know and that of “not knowing” is high, particularly in the workplace. As such, this strategy has worked rather effectively for me. Perhaps there is something in here that you could mine for yourself.
