Automated Tests and Deployment are Real Code

Dale Emery has posted a great set of slides. I would recommend this to all software developers, testers, business analysts and everyone in the software management food chain to read.

Slide #9 from Dale's deck

This has reminded ne of a conversation with a tester not too long ago. I was doing some work with him on their test system. We pair-programmed the change - it was his first experience in pairing. It was the also only way we could achieve this tricky modification. The system has grown into a big code base. It was not well documented, apart from some Word documents that were not up to date. There was also a number of methods that mostly did the same thing.

I explained to him that the test system itself should be modular and unit-tested. His jaw dropped: "We should have tests for our tests?". "Indeed", I replied, "you are using this to functionally test the product as if it is installed in a live environment. You need to have the confidence that changes you make will not adversely affect the results."

This was an eye-opener for him.  He has never considered test code to be real code. Surely we sometimes do things in test code that we won't do in production code, but that is intentional as the code is fit for purpose. It still needs to be maintained and structured properly for it will probably live as long as the product itself would. Just as there is a cost to not doing TDD on any sizeable production of code, there is a cost to not doing it for any sizeable test code base. This test code will probably live as long as the product itself, therefore it needs to be maintained with the same fervour as the production code. Good developers understand this about unit tests, but I am seeing that the biggest breakdown still occurs where people need to build test systems to perform functional or integration testing.

The same applies for your deployment code. The DevOps movement tells us that infrastructure is code. Not only do you need to look after your production code and test code, you also need to look after your deployment code with the same zeal. It is hard to do, it requires discipline, but that discipline is what is going to allow you to relax on the weekend, instead of fighting fires in the office. I would call that prosperity:

Agile teams - Prosperity Focused, Values-driven from Schalk Cronjé

I have recently heard of a team that used to work to the mantra of building walking skeletons first, including building the skeleton deployment code first.  Of late, they have been told to manually deploy because THERE_IS_NO_TIME_FOR_WRITING_AUTO_DEPLOYMENT code. Now that is just wrong. It is a mutation of Dale's Automation Last Zombie (see slide #12 of Dale's deck).  We can even call it the Deployment Last Zombie. I am sure that team will pay for this short-term thinking pressed upon them.

Just as test-driven development has done a lot for design and testability we really need Deployment-driven development. Dare I call it DDD? Preferably not, there are too many buzz acronyms around already. Regardless of what we call it, this is what DevOps and the next level of effective software development brings to the table.

Just remember, treat your test automation code and your deployment code with the same respect that you treat your production code with.
 

How Management Can Help Continuous Improvement

When doing some house clearing, I can across and old note book from 2003/2004. Some notes I made about Continuous Improvement (CI) really struck me as they are as relevant today as they were when I wrote them. IN this blog, you will not any earth-shattering new information, just five simple principles that managers or thought leaders within an organisation should keep in mind.


Support the process through allocation of time, money, space + other resources
Support experimentation. Do not punish mistakes, but encourage learning from mistakes. Making a mistake is not failure,



When major organisational changes are planned or coming your way, assess the impact on the existing CI system.
Incorporate it in your planning. It is therefore important to align your CI system with your strategy.



Facilitate CI co-operation across functional boundaries.
Apply shared-problem solving. If only one group improves, it is just local optimisation. But co-operating across teams and functional boundaries, optimisation can go company global. This is also an underlying principle of rightshifting.


Become a learning organisation.
As a manager you must accept that learning will take place and, where applicable, act on all the learning that have taken place. The organisation itself, needs articulate and consolidate the learning of individual and groups. It is not of much help if only individuals learn, but that learning must be shared in some form or another.


The CI system itself must also be continuously improved.
It is important that sufficient resources are made available. If necessary, lobby higher levels of management to understand this. Try to use Reinertsen's Economic model to quantify what value your CI is process providing.




Note: Unfortunately I cannot remember some of the references I was reading at the time, when I made the notes. If anyone recognises something, please let me know.