Connecting the dots…

The bitter red pill 

I’ve written a lot about change. It’s made me think extensively about why change is so difficult for most of us. A lot of us would like to change things about our lives. Our minds know it, but our bodies reject it. It’s all about habits.

Let’s take the example of getting software into production. If you’ve been in a large corporate for a long time, you’ll understand this process in quite a specific way. That way will include all sorts of manual ‘quality gates’ that you will need to pass through on your path to the final step of getting your code into production and into the hands of your customers. These gates are controlled by various committees or boards, each of these committees requiring reams of documentation to prove to the gatekeepers that certain standards have been met before the gate will be opened and your code will be allowed to sail through the gates into the next environment. The process is generally very slow, drowning in bureaucracy and filled with arcane rules and policies that have accumulated over the years or decades, each building on the last set of rules, trying to address risk and maintain the highest quality possible. Because of the imposing bureaucracy, teams generally tend to slow down their release schedules to only a few a year, to minimize the pain of having to jump through all the hurdles that a release entails. Software gets released less often to customers and the chance of delivering the wrong thing (or indeed the right thing, but just too late) gets greater. An average release into production can take anything from 6 months to a number of years. Sometimes the software becomes redundant before it’s even released and it never sees the light of day.

If your experience is in a tech startup, getting your software into production looks very different to you. You spin up a virtual server on a cloud platform somewhere and configure it as you need for development purposes, no length procurement process is necessary. You write your tests first before you write your code so that when you check in your code to your source control repository, the continuous integration (CI) server runs through your code and checks it against the tests and tells you immediately if your code is working according to the required functionality and quality standards. If the code passes the tests, your CI server automatically sends the code to the next virtual environment, usually some sort of integrated environment, where another set of tests will be run checking if your new code plays nicely with other systems that it has to co-exist with. If it doesn’t, the code is removed from that environment and you get immediate feedback of what went wrong. So you fix it and try again. When the tests are run again and it now passes, the CI server automatically promotes the code to the final production environment and your customer gets to play with the new software and you can get feedback on it. The release time into production in this scenario is anything from a few hours to a few weeks.

Both these methods have at their heart the noble goals of solving the problem of ensuring quality code gets into production and that any risk to the business is minimized. The difference is in the way the problems are solved, and this is where the change part comes in. If you’ve been doing software development in a large corporate for a long time and your only point of reference is scenario 1, you will struggle to understand that there are other ways of solving the problem. Even if you do realize that there are other ways, you will often try to shoehorn some of these new methods into your old process because it’s so familiar to you. You try to have the ‘new’ and keep the ‘old’. What’s really going to bake your noodle is that you have to give up entirely the old ways if you want to embrace the new.

Let go, and wake up in a new world.






2 responses to “The bitter red pill ”

  1. Agent P Avatar
    Agent P

    I think there is a couple of concerns that I need to point out.

    1. The Risk Issue

    So, as a start-up or a young tech company your total company worth is mainly less than USD$ 10 000 000

    It is a lot of money, but compared to the corporate beast it is what they will pay for a damning lawsuit to disappear. When your risk of change is small and your total company don’t affect a significant part of a nations GDP you are okay if and when something goes wrong.

    The risk is also reduced a lot if you began with Test Driven Development rather than archaic practices. Lets face the truth, the average TDD coder delivers better code than the average non TDD coder.

    2. The “we are bad at hiring” issue

    Somewhere when you reach a certain point your organization the odds are you will hire a bad person or even worse, a good person will start slacking. People in our era is not good at fixing this. It involves a lot of manual effort and firing someone is very hard in some countries. So process are designed rather than addressing the right issues.

    3. The tests are only good when it is done correctly.

    I am a believer in Test Driven Development, but that is a art. You need a disciplined team that is not afraid of interrogating code of their peers and ensuring its quality. The suggested approach require good developers. Extreme Programmers.

    In short, you can only expect a non-tech organization to trust its developers if those developers are disciplined, reliable and proven with a good track record.

    1. songsta Avatar

      On point 1:

      Risk isn’t always financial. There is reputational risk too, which can be extremely important for startups too. Risk is also relative to the company and the situation. The point is we should try to minimise this risk in the best way possible, and this is usually in a TDD manner. TDD is more difficult to do after the fact and especially which tech that doesn’t easily support it. This doesn’t mean that we shouldn’t try.

      Point 2: This is where a self-managing team comes into play. Radical candour amongst the team should be used to try to highlight any issues that come up. I don’ believe in bad people, just bad situations.

      Point 3: TDD is something you put in place so that you don’t have to trust your developers. The test results should highlight the quality of the code. That for me is the reason that you put automated testing in place.

Leave a Reply

Your email address will not be published. Required fields are marked *