Manufacturing Code: Resources & Scarcity

How much effort should we put into a task or feature? What decisions can we make to improve our productivity with limited time?

April 18, 2018

Many times working as an engineer I have found myself in a situation where I must make a decision about how much effort I should put into a task or project. The ideal state of course is to, "do it right" and put in as much effort as is required. Unfortunately we live in non ideal world and this answer is not only unrealistic but sometimes can be harmful to productivity.

In my mind it is fundamentally a question of economics, particularly the concept of scarcity:

In economics, scarcity is defined as a condition of limited resources, where society does not have sufficient resources to produce enough to fulfill subjective wants.

- The New Palgrave Dictionary of Economics

From the mechanical & chemical side of engineering these resources can be a wide variety of items. Raw material, labor, transportation, equipment, parts and many more. From the software engineering side this primarily reduces down to one very important resource: time. Our time. Computers, keyboards, whiteboards and coffee are all relatively cheap compared to the time of software engineer. In fact one of the eye opening things when I first started software development was how unlimited the possibilities were as long as I was able and motivated. Compared to working as a process engineer where there are many more limiting factors on a project or experiment.

So to the original question, how much effort or time should we put into some arbitrary piece of work? Lets look at some factors that may influence our decision.

Size and complexity

This is the most obvious factor that is intuitive to understand. A larger and more complex feature will take more time to complete and should have more resources allocated to it. The real challenge here is actually defining "size" and "complexity" of any given feature which could be an article unto itself.

Scope of influence

Perhaps a more subtle but still important factor. How many people/devices/machines/other things will this feature affect? For example feature A affects the efficiency of one machine running a specialized chemical process. Feature B affects the efficiency of 100 machines running more generalized processes. Feature B seems like a better candidate for additional resources.

Business value

I had a professor that once said something that I've held onto: "The difference between an engineer and a scientist is that an engineer must produce business results". Business value seems to be something engineers tend to not think important or maybe even outright ignore. It is perhaps not "pure" to engineering, but ultimately pays our salaries and allows us to do some pretty cool work.

Lets take the previous example and add some values to it. Feature A's specialized process makes the company $100. Each of the feature B processes make $1.02, for a total of $102. So we maybe we should still stick with allocating more resources to feature B.

Now lets add another scenario. We estimate that the size, complexity and scope of both features are the same, but Feature B is a bland, un-interesting and possibly tedious problem. However feature A is an amazing, cool, fun project we're all very excited about. Can we stay objective enough to realize that feature B still adds more value? I've had personal experience where I had to be pulled back and convinced of this, or had to do the same to colleagues. Passion and enthusiasm is great, but sometimes it needs to be tempered with expectations of the job at hand.

Risk

In manufacturing this is an ever-present and looming factor. Failures to account for risks and the consequences of those failures can have serious repercussions including catastrophic failure, injury or in extreme cases fatality. A team at another facility did not account for all the risks of starting up a process in an unconventional way. The result was the destruction of a million dollar machine and over a month in downtime that disrupted half of the companies workflow. I didn't account for the risk of only a small somewhat routine failure in a process that my hand was near and have a scar on my hand to show for it.

In software development risk is also ever-present. In some scenarios where you are working with PLCs that control real world equipment or maybe even serious systems that have personal or financial data this seems obvious. On less critical applications this become a much more subtle problem. Risks may not be as serious as injury or financial fraud, but they should still be analyzed and decisions made off of that analysis.

What is the risk of 30 minutes of downtime in a very popular application? How much business value are we losing because of it? What is the risk that when a user clicks this button and it fails, they will give up and now buy our product? Both of those seem very concerning but how much resources to allocate to testing and making sure they don't happen is ultimately a business decision.


Their is no easy science in determining how much each factor should influence your decision. Most of the time this should be a decision amongst you and your team. Worst case if you are working on your own these factors should be something to keep in mind as you are managing your own work. Just remember that you are yourself are a limited resource. Allocate your time where it matters most.