As a software developer I hold a number of professional certifications, so each year I need to undertake some form of professional development to maintain these accreditations. Given the difficulties caused by Covid restrictions the learning would have to be online. I found edX to be a great resource for online courses and programs from a number of different institutions. The courses are free, all though time limited, if you choose to "Audit this Course". But if you like, you can pay to "Follow the Verified Track" where you will receive unlimited course access, graded assignments and a certificate of achievement.

Pareto Principal

Something really stuck with me from one of the courses, Sprint Planning for Faster Delivery, which introduces the Exponential Pareto principle:

The Pareto principle states that for many outcomes, roughly 80% of consequences come from 20% of the causes (the “vital few”).[1] Other names for this principle are the 80/20 rule, the law of the vital few, or the principle of factor sparsity.

In computer science the Pareto principle has been evident for some time, it was shown by Microsoft that fixing the top 20% of bugs fixed 80% of the errors. It also discovered that in general 80% of a given system could be written in 20% of the allocated time, then of course the last 20% of the system takes 80% of the time to develop. Also, that people use 20% of software features 80% of the time. So given that in general 80% of the features of a system can be developed in 20% of the time allocated, if you apply the principal again to those 80% of features, it could be possible to develop 64% of the features in 4% of the time allocated. Then, of course the principal can again be applied.

Keep It Small and Simple

This then leads on nicely to a principal also discussed on the course, KISS, but not in the old US Navy design principle of Keep It Simple, Stupid. But a variation with the notion of Keeping It Small and Simple. One of the goals of developing software using agile principals is to deliver value to the business as soon and as often as possible. It also aims to manage scope creep and deal with emerging requirements as soon as they become evident. Typically in an agile project, a product backlog would have been created made up of the business requirement broken down into features. It is tempting to fill the backlog with technical requirements and scaffolding. Applying the Exponential 80/20 rule to the backlog, could help to identify features that provide the most value to the business with the smallest development effort. Providing a focus on what should really be in the "Minimum Viable Product" and would also help to keep things small and simple.

I hope you enjoy this post.