Progress is not merely a measure of outcomes

A number of recent experiences have driven me to this post. I must add that at least one of these experiences are based on my own expectations as I am attempting to achieve something completely new to me - writing a book.

I hope to achieve a number of things with this article:

1. encourage myself (and hopefully others) to accept that progress is still being made
2. draw attention to the value in the hidden work
3. vent some frustration

Let’s take a look at what led me to this point:

Experience 1

As I mentioned I am in the process of writing a book (and finding all excuse to do other things just like this). I have found that during this process I have been beating myself up over the fact that I am not increasing the page count despite sitting at my desk working hard on the project.

Experience 2

During a recent role consulting with a development team I was told and I quote:

you can have progress or stability but not both

I have a lot of issues with that statement! Let me be clear though, I am not advocating against practices like Rapid Application Development, I have been involved in successful projects where these have been used. There was always a consideration to the consequences of any change being introduced and I believe that is the key.

Having explored the origins of this statement further I have discovered a culture of continually adding change to a product in the pursuit of “progress” without giving thoughts to the impact they cause or even whether they are a good fit.

My thoughts

I have spent some time thinking about this and my thoughts may likely change as my experience grows but for now here they are:

I base a lot of this on my experience as a developer but if I compare it to a completely different industry; my wife the cake baker - she bakes bespoke cakes. Looking at the process she follows to bake a single cake:

1. gather requirements from the client
2. decipher requirements into something she can work with
3. research options whether inspiration from others or imagery related to the theme
4. detail the design to the client so that they can agree it
5. once agreement has been made a date is scheduled for it to be produced
6. cake is produced and outcome is delivered

If you are familiar with software development cycles then this should look pretty familiar. What I have found during my experiences mentioned earlier is that items 1 through to 5 are deemed as unproductive and only slow down the ‘development phase’.

I am not saying that all developers fit this mold but there needs to be at least one person willingly involved to take on the mantle of handling parts of the process that others are not able to or comfortable doing. Falling in to this trap of constantly having to build something typically results in either a steaming hot pile of mess and/or something completely unfinished and never will be.

This leads me to:

“Progress is not merely a measure of outcomes”

_{Shaun Lawrence}

To continue along with that statement, progress can be:

• simply making a note of something to investigate
• researching something
• taking time to consider what is required
• doodling an idea
• discussing an idea with a friend
• doing nothing - in fact coming to the decision that nothing needs to be done is still valuable
• contributing to a list of things that can be considered progress (this blog is open to PRs -> https://github.com/bijington/blog)
• acknowledging the progress that others are making
• asking for help

This list is mainly for myself so next time I feel down about the ‘lack of progress’ in one of my projects I can read through this, pick myself up and remember the value in the hidden work. I do hope that others are not going through similar pain however if they are then I hope this helps to comfort you and/or encourage you to take it a little easier on yourself.