pareto be my guide

Saturday May 13th 2023 by SocraticDev

it requires a lot of thought to stay on top of what actions will produce the best value

I was bantering online about Pareto principle and how intentional a technology professional ought to be about this legendary 20% of effort.

The Pareto principle states that for many outcomes, roughly 80% of consequences come from 20% of causes (the "vital few") [...] In computer science the Pareto principle can be applied to optimization efforts. For example, Microsoft noted that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated. Lowell Arthur expressed that "20% of the code has 80% of the errors. Find them, fix them!" It was also discovered that, in general, 80% of a piece of software can be written in 20% of the total allocated time. Conversely, the hardest 20% of the code takes 80% of the time. This factor is usually a part of COCOMO estimating for software coding

A toughtful tech executive replied to my banter: "it requires a lot of thought to stay on top of what actions will produce the best value".

First and foremost I agree that no "careful analysis and planning" could pin point what crucial effort (the 20%) would yield 80% of the value.

heuristics and principles

Long-winded planning and careful analysis in technology don't guarantee success.

However, a technology professional can rely on heuristics to guide his activities; to provide the best value for his clients and avoid spending energy on low-value work.

A heuristic (/hjʊˈrɪstɪk/; from Ancient Greek εὑρίσκω (heurískō) 'to find, discover'), or heuristic technique, is any approach to problem solving or self-discovery that employs a practical method that is not guaranteed to be optimal, perfect, or rational, but is nevertheless sufficient for reaching an immediate, short-term goal or approximation. Where finding an optimal solution is impossible or impractical, heuristic methods can be used to speed up the process of finding a satisfactory solution. Heuristics can be mental shortcuts that ease the cognitive load of making a decision.

reducing work-in-progress

Work-in-progress (wip) is the measure of partially completed work items. In software and IT, we notice wip piling up when a developer starts a new task while waiting for a pull request approval, a meeting with a product manager, or for security access being granted to proceed with current task. Usually, every new task entails its set of blockers therefore the wip can accumulate at an exponential rate.

In that case, every effort to reduce work-in-progress in your daily routine will accelerate value delivery.

Lean philosophy got this counter-intuitive motto: "Stop starting and start finishing". For a dev, it means that they should raise their hand as soon as their current task is blocked. They need to seek prompt assistance from teammates instead of starting a new task while hoping the previous one gets magically unblocked.

producing quality work

Producing quality work is essential.

When a tech professional tackles an issue we want the issue to be put in context and its details understood. For example, during a transition as a consultant, I was told "We expect you to become the team expert in this technology when current consultant leaves at the end of their contract". It meant that knowing this technology was the principal way I would provide value to my new client.

A similar mindset should guide a developer tackling a bug or developing a new feature. They should become the "expert" of this bug or feature. They are able to explain why the bug happened or why this feature is getting developed. They are able to explain in details how they intend to fix the issue or produce a working feature. Finally, they should have minimally tested out their contribution to make sure it works as intended.

Producing quality work usually takes more time but it is well worth it:

  • fixing a defect gets more expensive at every step of the software lifecycle;
  • increases value delivery since building on top of low quality works is hard;
  • delivering quality just makes you more credible as a technology professionnal; people will love working with you.

take pride in your work!

do not reinvent the wheel

"Am I the first person to be having this problem to solve?"

Before starting digging too hard to solve a problem, ask yourself the above question. Most likely, other people had had this problem before you and there are commonly accepted solutions to it.

Work smarter, not harder

Take the time to search online or talk to colleagues to figure out how others professionnals might have solved a similar problem in their organization.

be transparent, ask for feedback on your work

Seventeenth century, French philosopher René Descartes famously recommended to always walk in a straight line if you get lost in the forest.

This advice might only be valid to small european forests...

Nowadays, we are more connected than ever. There is no shortage of people who will be delighted to criticize your work. Take advantage of it!

I think the worse mistake to do is keeping to yourself to avoid criticism. Worse than that is actively discouraging peers to give you the time of the day. You might not even realize you are doing it, but these are sure ways to make others stop helping you improve thru advices and criticism:

  • put forward your work and actively ask for feedback;
  • accept advices, follow up with the person and show them the improved work;
  • separate your self-worth from the work you produce; it is the work produced that is getting criticized not yourself;
  • thank the person that gives you feedback.

The days when a lone programmer could build a valuable problem from A to Z are long gone. You work with intelligent and competent people. You'd be a fool not to take advantage of this situation. Take the wager to accept criticism because it will help your organization build better products and it will help you improve your skills.

conclusion

I usually don't write conclusions to my blog posts.

I'll write one for those who haven't figure out yet what I was blagging about here.

The conclusion is that a successful technology professionnal can safely rest on Pareto principle. Although it is near impossible to plan ahead of time what actions (the 20%) will create the most value, there are sound principles and heuristics one should adopt to work smarter, not harder.

sources