Page 3 of 12



No Silver Bullet

Jun 2, 2019

Frederick Brooks's article "No Silver Bullet: Essence and Accidents of Software Engineering" argues that compared to hardware, software industry hasn't experienced massive leaps in productivity nor will it ever do. While our hardware can double in performance every year, our software projects cost pretty much the same year to year. This article from 1987 is a classic that hasn't lost its relevance with modern software developers.

One of the reasons behind the "slow" progress is complexity. Often software applications deal with many more possible states compared to hardware, and unlike physicists, software engineers have to deal with inherent complexity that cannot be solved by discovering underlying theories and principles. Software is unvisualizable: we cannot simply draw out a software program, hand it over separately to two software teams, and expect the teams to ship the exact same application. Software problems are not only technical problems but also management problems.

And yet, we often find ourselves discussing ideas such as object-oriented and functional programming, micro services, or sprints as the thing that will solve everything that's wrong with software. We can create new layers of abstractions but no level of abstraction is going to make software visualizable or non-complex. No one will ever publish a book that provides a process or manual for managing software projects without quality problems and usability issues.

However, none of this means that we shouldn't try our best to keep making things better.

You can learn to accept the complexity and messiness of our industry. First, keep trying to find those small improvements that others have missed. Software is terrain where you navigate best by iterating on your tools and practices.

Last, remember the value of people. According to Brooks, "each software organization must determine and proclaim that great [software] designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded." If you agree with Brooks that software development is a creative process, you might also agree that the difference between an okay and a great software developer can be a significant one. After all, we can see the same phenomenon in other creative fields where people have to deal with rapid change and complexity.

There is no silver bullet: no best process, no best programming language or style. But there is also no end to your learning. Your journey can continue to be as exciting as it has been so far.

Reduce Expected Opportunity Loss with Build, Measure, and Learn

May 26, 2019

Information has economic value that correlates with its ability to reduce expected opportunity loss. Opportunity loss is the cost you will incur when you greenlight a doomed project, or the profit you will miss out on when you decide to pass on an opportunity. When you multiply this opportunity loss by the probability of it happening, you get the expected opportunity loss of a project.

Project cancellation is a high opportunity loss situation: we incur some costs while never receiving any of the benefits. Therefore, information concerning the possibility of project cancellation is the most valuable information for you as a decision maker. Since the opportunity loss is usually higher for lost benefits than estimated costs, the next most valuable information relates to validating the expected benefits. In other words, when it comes to calculating return on investment, we should focus more on the return and less on the investment.

In reality, cost estimation work gets more resources compared to work that focuses on forecasting benefits and the probability of project cancellation. This is partly caused by the fact that estimating costs with detailed technical specifications and spreadsheet software is easier and more straightforward work. But when it comes to estimating the risk of project cancellation and actual benefits, it can be hard for us to know where to start.

You need to get creative with the actual tools and practices for your analysis, but the build-measure-learn feedback loop can be one of the most valuable components of your work. First, you build and ship something small and concrete. After that, you measure the effect of the thing you built. Finally, you adjust your understanding based on what you learned.

Remember that there are two variables that make up the expected opportunity loss: the cost of being wrong and the chance of being wrong. In the context of benefits and expected opportunity loss, market analysis is required for calculating the cost of being wrong. If you're estimating the possible revenue for a new product, you count the number of potential clients and their annual spending in your product category. If your analysis is for an internal automation project, you count the number of possible work hours saved.

But none of this analysis tells you how many of the potential clients will actually buy your product, or how usable and efficient your new internal software actually is in terms of automating some of the manual processes. The chance of being wrong is either the same or reduced only slightly.

Compare this to doing initial sales before building the product or building something small and ugly, but still useful, for a subset of your employees. You won't be much wiser when it comes to estimating the cost of being wrong. But you are able to have an effect on the chances of being wrong.

Since you're building things, it might feel like you're already doing product development. However, it's not product development if the project hasn't been greenlighted. It's research and analysis that yields returns higher than the work your organization uses to calcluate the cost of different initiatives.

Build-measure-learn feedback loop is not the only way to decrease the chance of being wrong. Because of real life work experience, some of us are better at forecasting and our chance of being wrong with a specific opportunity can be lower by default. We might have been observing market behavior in sales (or in providing support for sales) or lived through other, similar projects in the past. There is also design thinking that takes a more strategic approach for reducing the likelihood of being wrong about an opportunity.

We know the build-measure-learn feedback loop mainly because of the lean startup methodology. But the loop is not just for startups or established companies who want to add a Silicon Valley vibe to their office. Build-measure-learn feedback loop is not startup culture. It's rational economic behavior.

Paradox of the IT Cost-Benefit Analysis

May 19, 2019

Inside your organization there's an initiative for a new software project. You are asked to prepare a cost-benefit analysis for it. Your organization needs to be sure that it's allocating its limited resources for the right projects. People calling the shots (decision makers and managers) want to see a calculated return on investment. While they have appreciation for the qualitative aspects of different initiatives, it's hard for them to compare different projects without valid quantitative measures.

How will you start? What will you turn your attention towards? Which part of your analysis will be the most sound?

It's very likely that the bulk of your effort will go towards estimating the development costs. It's what most of us focus on. It's what most of our managers and clients want to know. But cost analysis is not the most valuable information for decision making.

Douglas Hubbard (author and consultant in decision sciences) uses the term "IT measurement inversion" to describe this paradox. According to Hubbard, "most organizations spend a lot of time estimating initial development costs but not so much estimating benefits, how fast people will start using the system or the chance the project will never be finished." However, the probability of project cancellation and the utilization of a system being developed are the most important unknowns organizations should try to research.

This doesn't mean that you shouldn't estimate development costs. What it means is that you should instead rethink how you prioritize different variables in your cost-benefit analysis. The idea is to allocate the majority of your research time for figuring out whether the project will get terminated or not. Second biggest chunk of your time should go towards estimating system usage and how fast that usage will grow (i.e. how quickly you'll get people to use the system).

Information has value which is calculated by multiplying the chance of being wrong with the cost of being wrong. If you decide to invest into a software project but the project fails, your cost of being wrong are the development costs. If you decide not to invest, your cost of being wrong are the missed benefits.

The mathematics of information value explain why project cancellation is such a critical unknown. When a project is cancelled, you miss all the benefits and incur considerable costs. A chilling example of a terminated project is LIDL's decision to cancel its switch to SAP after spending seven years and €500 million on it.

System usage is the second most important unknown because benefits are generally assumed to be larger than costs. If the costs were initially assumed to be larger than the benefits, the project wouldn't even be considered as a viable initiative inside your organization.

Remember the formula for information value: chance of being wrong × cost of being wrong. When we are able to decrease the chance of being wrong about the likelihood of project termination and benefits, we achieve greater gains compared to decreasing the chance of being wrong about the development costs. When it comes to development costs, the cost of being wrong is outweighed by the cost of being wrong about possible benefits and project cancellation.

We automatically direct our focus on development costs because our minds are trained for that. First of all, we, as humans, suffer from loss aversion (we prefer to avoid losing $5 than finding $5), and at the end of the day, organizations and committees consist of people like us who carry different cognitive biases.

Secondly, since we are so often asked about costs in terms of money and time (e.g. story points), it's easy to start assuming that costs are somehow more important than benefits. However, it's very likely that our organizations are already giving enough attention to cost calculations. It's time to start developing our skills in calculating the benefits.

Getting to a No

May 12, 2019

To foster intimacy with your fears can be a path to courage. Instead of running away from your fears, you can listen to them. And when you keep your ears open and listen carefully, you'll realize that often you are afraid of the no. You're afraid that people will say "no" when you ask them for something. You're afraid that people will say "no" to your idea or the work you put your hear and soul into.

But what would happen if you would actually try to get a no out of people instead of a yes? What would happen if you make the no your goal instead of your absolute worst outcome?

Try to a write something bad instead of something good. The saying "practice makes perfect" means that the vast majority of your early work is going to suck. It means that there is this mountain of bad work that you have to climb over to get to the good work. Focus on the climb instead of letting those obligatory imperfections stop you.

Track noes instead of yesses. This is a trick some sales people use when they have to go through a long list of sales leads. Instead of telling themselves that today they have to make five sales, they tell themselves that today they have to get fifty noes. If you're trying to create change inside your organization, try to get ten people say no to your idea instead of trying to find that one person who is ready to support you.

Try to get a stranger say no to you. If approaching ten people with your ask gives you overwhelming jitters despite the mind tricks you're playing on yourself, you might benefit from practicing the art of asking and approaching people in general. Here's a fun game for that: approach a stranger at a social event or bar and try to get a no out of them with any kind of question. It's surprisingly hard and it will build up your social improv skills.

Being Intimate with Fear

May 5, 2019

Are you intimate with your fear? Do you have a name for it, or do you try to deny its existence?

Do you know the difference between hard and scary? Learning a new programming language is hard. Writing is hard. Waking up at 5 AM is hard. But none of these activities are necessarily scary by themselves.

You deal with the hard with self-discipline and wit by working harder or working smarter. But when it comes to fear, you often feel helpless. You tell yourself to "just do it." But your feet are refusing to take a step forward.

It's sometimes hard for me to write these weekly posts. There have been times when the words have not come to me. There have been times when I finished my weekly post at 2 AM–a time of night when I would much rather be catching Z's instead of editing my sentences.

However, none of this has been scary. I'm not scared of my computer. I'm not scared of my writing software. I'm not scared of typing.

What has been scary is to share my posts. It has been scary to send a link to my friends and say here's something I've written and believe in. It has been scary to share posts at my workplace. It has been scary to tweet at the people who have inspired my writing.

This same fear repeats itself in other areas of my personal and professional life. I get scared whenever I put myself out there for other people to judge, or whenever I need to ask other people for their time, attention, money, or social capital. I get scared when I risk myself being seen as someone who is reaching, or as someone who is desperate, unaccomplished, and incompetent.

This is social anxiety, fear of rejection, impostor syndrome, etc. In The War of Art, Steven Pressfield calls it simply resistance. We all have it.

And because of resistance, we sometimes isolate ourselves. It can be more comfortable to work on things by yourself instead of dealing with the expectations and unpredictability of others. If you work solo and you don't ship until your work is perfect, you don't have to be vulnerable. You don't have to prepare for criticism because your work won't have rough edges.

Of course, you know by now that perfect takes forever. You know that build, ship, learn, and repeat is the fastest, albeit also the toughest, path to success. You probably have also learned that meaningful work divides opinions.

The Abortion by Richard Brautigan describes a fictional library that collects only unpublished books written by ordinary people. Every single book is accepted. But none of the books get checked out. Nobody ever reads them.

While the writers put in long hours to produce their manuscripts, do they actually create work that's risky? Instead of facing their fears, do they escape it? While bringing your manuscript to the library can give you a sense of accomplishment, deep down you are not able to tell yourself that you shipped like a real artist. There is no social risk. There will be no commentary. Since your work remains undiscovered, public failure is not possible.

So how do you crush your anxieties and live a fearless life? You can see how your fear stunts your potential. You can see how your sensitive ego is sometimes the greatest enemy of your work.

Pema Chödrön (writer and Buddhist) asked once a teacher of hers how does he deal with fear. The teacher replied "I agree with it."

There is no war against your fear that you can win. Therefore, maybe it's time for you to come to terms with the fact that you will live with your fears for the rest of your life. Instead of running away from fear, try getting intimate with it. The next time you get scared, listen to what your fear is telling you. It's saying you're making yourself vulnerable. It's saying you're doing something crazy. It's saying you're about to live life to the fullest.

Page 3 of 12