7 Wastes of I.T. (And a few Bonus wastes)

Today I’m going to quickly go through the 7 wastes of IT and my take on them,

At some point in the future, I may go through them in more detail.

    • Partially done work
      Have you ever been on a project or been doing a task and then asked to drop it?
      That wasted effort for developing that piece of work is one interpretation. 
    • Extra features
      Writing something that isn’t what the customer wants – or worse yet something the customer will not use.
    • Re-learning
      Have you ever learned something, never documented it and then had to come back some time later and had to re-learn that thing again?
    • Hand offs
      Anything that involves passing how the system works from one person to another. Not everything is given over, and usually the handoff is too short to be of any use, or months before the recipient needs the information. Where we go back to re-learning and they have to go through it all over again.
    • Delays
      Delays can cause a loss of knowledge of the system. Ever completed a piece of work, had to wait days or weeks before you can migrate into production? by then you have moved onto something else?
      How difficult has it been to fix any issues that occur? Would it have been quicker if you deployed sooner?
    • Task Switching
      This I have recently been through. 3 projects. All done simultaneously, all requiring 100% of my time. I spend so much time changing context from one task to the next that I don’t focus on anything and it ends up being a mess.
      Also, every time you change context, you have a ramp up time to focus. Change too often and that ramp up time eats into the productive time.
    • Defects
      Anything that takes you away from planned work is bad. Defects tend to do that. They cause unplanned work in the issues they cause and also in having to fix them and the aftermath.
    • Bonus Round
      • Unused Creativity
        Your people may have ways of doing things, but giving them a chance to try new things and new ways to do something may gain efficiencies and new perspectives. Giving your people a creative out, also gives them more job satisfaction.
        Not using creativity, you are prone to repeat the same mistakes and have morale problems. Also, creativity is where your innovations occur.
      • Technical Debt
        These are effectively defects, quick fixes etc that will bite you at some point in the near or distant future. It could be messy code that when you need to do a change will take weeks or months instead of hours or days if done properly in the first place.
        It can also be lack of documentation, or poor documentation etc.
      • Heroics
        This is working long hours or extra hours. Any time that is taken away from rest time causes productivity to suffer, either short term or long term. People get tired.
        I have a colleague that will work in his own time on a project for work to try to get ahead. He is not paid for this time, and most of the time he accomplishes little. He would be better off learning in that time if he needs to rather than slog it out. He actually reminds me of this Dilbert cartoon.

Sometimes waste is unavoidable, but every effort should be made to reduce it. This in essence is one of the foundations of Lean and DevOps in my opinion.

Safety Conversations

I work for an electricity utility and one of the things that the company is passionate about is safety. Its dangerous work out in the field. Dealing with electricity, there is always the chance of electrocution. So everyone, even though who work in an office learn about safety.

Once of the concepts we were introduced to was the safety pyramid. We found out that if you focus on reducing unsafe acts, you actually make a difference and reduce fatal injuries. Its a trickle up effect. Being aware of the situation from a safety perspective, you make the workplace safer overall. That’s not to say that you eliminate fatal injuries, you just reduce the chance of them happening.

This got me thinking, what if the same process was applied to software development. Would being aware and trying to fix minor bugs, those both during the development process but more importantly those already in production. Would you be making your system more stable overall, thus reducing the chance of a severe outage? If so, how would the pyramid look. So I put the following together.

I know the concepts of Test Driven Development, Acceptance Test Driven Development and the whole, shift left theory deals with this, but does putting it in this perspective help?

I’m interested in your opinion, please let me know in the comments below.

Complexity and Evolution

The modern world is made of lots of moving parts. Nothing is orchestrated, there is no grand plan, but they come together to make the world we live in.

It is this ‘complexity’ that makes predicting anything impossible. It also makes predicting solutions to the worlds problems, be it economic, crime, world hunger or even how our business will run in 10 years time impossible. We turn to our leaders and experts for guidance, to steer us in the right direction, but it turns out that for long term goals, they have as much influence as the rest of us. Where the leaders and the experts go excel at is leading in the short an medium term. The reason for this is that their expertise can only go so far before entropy kicks in and it just makes it impossible to be right. So how should you solve problems, in incremental steps.

Surprisingly, this method of solving problems has been around for billions of years. In Nature, its called Evolution.

In evolution, each incremental step starts off with a mutation (variation). If the mutation gives the organism an advantage, the organism lives and procreates spreading that mutation. If the mutation causes a disadvantage, it is more likely that the organism dies, and the mutation is no longer spread.

Karl Sims a computer graphics artist tried simulating evolution in a virtual world. From his videos, you can see that his virtual creatures started having traits that living creatures have. This just shows how well nature has used evolution to solve problems.

Types Of Complex Solutions

There are 3 types of solutions to complex problems.

Mount Fuji

Mount Fuji

photo credit:Reaching Out via photopin (license)

There is one, and only one perfect solution to the problem. As you improve, you get to the ultimate solution, any more effort and you are just going down hill.

Very few problems fall in this category, but when we solve a problem, we seem to think we have found the best way.

Rugged Landscape

Mountain Range

photo credit:Sunny Mont Blanc via photopin (license)

Here, when you solve a problem, you have one solution of many possible solutions. Some better than others. It is very hard to find the perfect solution, but you need to keep trying to see if there is a more efficient, or better solution.

Dancing Mountain

Here, you find a solution to your problem, but the ground shifts from under you. Circumstances change, where you were on top of the solution, you now are at the bottom and you have to start again. You need to keep shifting to stay ahead.
This is more closer to reality.
So just like in nature, evolving and adapting is the way to go.
So, how does this relate to DevOps, well, given DevOps has its basis in Lean and the Toyota Production System, there is a concept of improvement through trial and error. Make changes in small steps to continuously adapt to a solution to a problem that is constantly changing. This concept is Kaizen, Continuous Improvement.
So how do you implement Kaizen? Its quite simple really, think of something that will improve a process. This could be as simple changing the order of how tasks are done, automating/semi automating, documenting steps better, make something more understandable etc. The second step is to try it out in small scale. Finally evaluate the process to determine if there is an improvement or not. If there is an improvement, great. Change your process. If there isn’t an improvement, see where the issue is, and re-evaluate to determine if a modified version will work, or if the new process should be dropped altogether.  These steps may look familiar, its Peter Palchinsky’s Principles.
The thing is, with evolutionary change, a small change on its own may not give you a significant cost or time saving. In fact, it is less likely to give you a significant cost or time saving, but if you have  a culture where this is the norm, where you continuously try to change and improve, then all those small changes add up.

Small Changes

So what constitutes a small change? Let me give you a real life example that I had. As part of the daily health check that I do for the company I work for. The health check steps are documented in a wiki page with checkboxes so you know which steps are executed as you go along.

Once of these steps was check if a file was transferred successfully to its destination. To do this, we would FTP to the remote host and see if the file was present every morning. This process didn’t take long. About 5 min each day. This was one task out of many as part of our health check that would take about an hour to accomplish if there was no issues. Over a day at times if there was. To save time with this check I wrote a python script that would show a web page (Using SimpleHTTPServer) of the remote directory to be viewed. The script took about 15 min to write. Now we have a visual indicator that is embedded in the wiki page (through iframes) to see if the file is present. This change alone saved 5 min. Yes, the script could be made better, a better solution would be to send an alert email or SMS etc if the file isn’t present or other countless improvements, but that is not the point.

This small change which saved 5 min was a first step. Other small improvements followed. Provided there are no issues, the health check is now down to 5-10 min. With issues, its is now rare that they would take a day or more. Most of the time its an hour or two to resolve the issues. We still have a long way to go, but we are on the journey.

The point is, that you start with something and build upon it and keep trying to improve it. Some things work, some don’t, but you won’t know until you try.

Galls Law

John Gall, an American paediatrician wrote a book “General systemantics : an essay on how systems work, and especially how they fail.”

In this book (Which I admit I haven’t read) there is one statement his is known for

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system

Here John Gall advocates building complex systems through evolution by starting with a simple system and building upon it. Pretty much how an Agile project should work.

 W. Edwards Deming

Now we come to the tail end of this post. Back in World War 2, while the men were fighting, the women would be the ones working in the factories. Building every day products and the machinery of war. With limited resources, the factories had to work smarter and harder to get reasonable productivity. Deming, through all this worked out a system to achieve this.

At the end of the war, all the men came back and the women were out and everything went back to the way it was. At least in America and the allied nations.

In Japan, they were just trying to re-build from after the War. Deming was brought over  the techniques that he developed during the war. The Japanese embraced this. None more than Toyota. Which is where we get the Toyota Production system and the start of Lean.

One of these techniques that Deming brought over was the PDCA cycle. Also known as the Deming Cycle.


  • Plan your change and determine its success criteria
  • Do your change
  • Check that it meets the success criteria
  • Act accordingly
    • If the success criteria is met, Yay complete.
    • If the success criteria is not met, the re-evaluate and plan the next step and repeat the cycle.


So as you can see, through independent means, many people have found that the evolutionary way to trial and error seems to be the best means to achieve the best solution to a problem. Be it nature, manufacturing or computer science.

Learning Resources

I’d like to list my learning resources. Where I learn the most about software development, Devops and Testing.

I work during the day and my wife works at night. We have a 4yo son that I take care of in the evenings, so sometimes its hard to learn new things, especially when you need to dedicate a large block of time. To help counter act that, I like to learn by taking information in by various means. This includes video, audio and written content. I find that taking the same information in various means helps me understand and link the pieces together to a coherent thought. Usually I try to read, watch or listen to content on the train in the morning and evenings.

So, here are my sources.

Firstly, video.

Skills Matter This site is a British site for a company that hosts a number of talks and courses a week. They put up these talks for free. Its a good resource for finding the latest trends and perspectives.

SoftDevTube is the software development you tube, although not updated as often. It has varying topics, but isn’t updated often. Previous videos are very interesting though.

Confreaks.tv is mainly ruby based, but a majority of the topics are still relevant for any language. Again, this site isn’t updated that often.

DevOps Enterprise Summit puts up their videos of the conference. These are put up a few months after the conference, but there is quite a lot to keep you occupied for a while.

Youtube is also a great resource. Just search for topics, speakers, events etc and you can find content.


Test Talks Jo Colantonio hosts a podcast dedicated to testing and test automation. This podcast is mainly for web development, but I do find the concepts interesting.  I rarely miss an episode.

Software Engineering Radio I have been listening to this podcast for a very long time. Probably almost 10 years (The podcast is 10 years old, and I started listening quite early). The topics are timeless. I highly recommend listening from the beginning.

DevOps Cafe I have only recently started listening to this podcast, but it has been around since 2010. I’m trying to catch up from the first episode (currently at ep 11) but I have so far found it to be a great resource for DevOps theory from a high level.

Coder Radio Not as technical as you would expect, but I do find the topics interesting at times. I haven’t been listening for a while as I’ve been catching up on DevOps Cafe.

Meta-Cast I have only been listening to this podcast for about a  months to a year. The topics are interesting, but I tend to skip if I don’t find the title interesting.

Coding Blocks Another podcast where if I find the topic interesting, I will listen to.

Thats pretty much it for podcasts. There are a number of others, but these are my current regulars.

Web Sites

I tend not to read as much from Web Sites anymore. I flick through, but I tend to not read as much as I should. I use to read them quite a bit, but its getting harder to find the time.


This includes

I find DZone to be a good resource for blog posts of varying topic.

Reddit Programming Channel This is another resource that I find interesting at times. It is less policed than DZone, but still has great content.


Instead of reading web sites, I’ve started reading more books. If a book is mentioned on a video or podcast, I’ll try to read it and learn. I tend to get my books through Amazon, through the kindle. Also Manning have Deals of the day where you can get up to 50% off. I tend to go for the ebooks as the dead tree versions cost quite a bit to ship to Australia. LeanPub is also another good source. Gojko Adzic, the Specification By Example guru has a number of books self published at LeanPub.

I also buy dead tree versions from the book depository and Abe Books. Abe Books is good to try first to see if there is a used version of the book available.

I have also found some books in op shops (Lean Thinking).

Other Learning Resource

Udemy – Lots of free courses (Found on OzBargain regularly) but like most Ozbargainers, I have yet to complete may courses.

The same with kindle books, they pop up every now and then on OzBargain.

There are many places to find learning materials. Most are free. What I tend to find is that a video might reference a book as a source of inspiration, which sometimes I will try to read, or a podcast will have a guest speaker which I will look to see if there are any videos available.  Sometimes you go down rabbit holes and learn the origins of where a theory came from. For example, with DevOps, it lead me to Lean, which lead me to the Toyota Production System – something completely unrelated to IT, its manufacturing but the content is still highly relevant. This then lead me to NUMMI which then lead me to changing culture etc. I find it fun going down and holes and learning along the way.  So have fun and let me know how you go.