Filed under: Automation, Software craftsmanship, Software development, — Tags: Automated deployment, Automated testing, Automated un-deployment, Code review, Continuous integration, Feedback loop, Long feedback loops, Pair programming, Small releases, Test driven development — Thomas Sundberg — 2011-04-14
Why not hack away as usual and hope for the best?
The answer is trivial. You perform the technical practices because you want to deliver value. Deliver value to the one that sponsors your development. The one who pays the bills or your salary. The only way you know if you have delivered value is when you get feedback. So getting feedback is important. Getting the feedback often is crucial.
The feedback loop is the time from when you decide to do something, write a piece of code, to the point in time when you know if it were the right thing to do. Feedback come from many different sources. The most important feedback is of course from your customers, those who pays the bills. This may be internal customers or external customers, it doesn't matter. They are the most important persons to get feedback from.
Feedback as often as possible is good. It will allow you to alter the course if something isn't proceeding the way it should. The shorter the feedback loop is, the faster you have a chance to change. So whatever you do, always make sure that it is an activity with a short feedback loop.
What happens if you have a long feedback loop?
It obviously takes longer time before you have a chance to know if you made a mistake or if you succeeded. It is of course not an issue if you succeeded. But if you made a mistake and based the following development on that mistake, it can be very expensive to fix. This is the same thing as using a rounded value in a calculation and then multiply with something later. The error gets larger and can affect the result.
You tend to keep your eyes open and constantly alter the course when you drive a car. Just very small changes, but all the time. You never close your eyes for five minutes on the highway. Five minutes is a rather short time frame but long enough to have an accident if you drive at high speed.
The length of feedback loops are relative, a few minutes is a short time in many situations.
It is important to realize that it is not about the technical practices, it's about the value they provide. If a particular practice doesn't deliver value, don't use it.
We talk a lot about things we should do. We should do Pair Programming, Test Driven Development, Continuous Integration and so on. But those are just tools. What we really strive for is the value these practices bring to the development. If we don't know why we are performing a certain activity then it's just a cargo cult.
So what value will each practice bring? Let's take a look at different practices and see how they can shorten the feedback loop. Some of them are core practices from eXtreme Programming, some are not. Those that are core XP practices are marked with (XP). The practices are ordered on a scale from short feedback to longer feedback.
Pair programming implies that two persons work on the same problem. Two brains and four eyes will constantly be looking at the code. The developer writing, the driver, will get suggestions and comments from the developer not typing, the co-driver. The comments may be anything from naming to suggestions on algorithms for the current problem. This is the same as doing a code review instantly and continuously.
Feedback is given within seconds.
Test driven development means that you write your tests before you write your production code. This will always result in a testable production code. How could you fail with that? The test are easy to execute and will test all parts of the system. The test will reveal if you broke any part of the system that you didn't work on.
Feedback is within minutes.
Continuous integration is applied whenever you save your code to the version control system. A continuous integration server will pick up the changes and build the system. Building means (at least) that everything will be compiled and the unit test will be executed. Any integration problems will be discovered and can be fixed immediately.
Feedback is within minutes.
Automated testing is any testing that is executed by a computer. Unit tests, integration tests, acceptance test should all be executed automatically. Unit test are often executed during the build on an continuous integration build. Integration and acceptance test may take longer time to execute, but they should be piggy backed on the continuous integration build and executed regularly if the preceding steps passed properly.
Feedback is within minutes to hours.
The most valuable feedback you can receive is feedback from the end users. The persons who actually will be living with the program you have created. To be able to receive their feedback you need to release the system. This should be done in small parts often. Feedback is within days to weeks.
During code reviews you get feedback on the code you have written.
Feedback is within days or weeks. If you can, use pair programming instead. It brings the same value a lot faster.
Deploying to production is often a ritual that involves a lot of manual steps, a great portion of anxiety and risks. This can be handled if the system is tested enough and you trust your automated testing and deployment. There is always a chance that you have failed in some way with the tests so it is equally important to be able to un-deploy, rollback, automatically as it is to deploy automatically. If the production fails for some reason, un-deployment should be fast and painless.
Feedback is within minutes to weeks, and rollback is painless.
Common for all the practices above is that they will shorten the feedback loop. They will do it on different scales, but they all contribute. If you can, always make sure that you apply the fastest possible practice and therefore has the shortest possible feedback loop.
RSS