Three ideas you should steal from Continuous Integration

I like Continuous Integration — a lot. Small incremental changes, continuous testing, continuous builds: these are Good Things. They provide statistics, things you can measure your progress with. But Continuous Integration requires an investment on the part of the development team, the testers, etc. There are, however, a few things you can adopt right now so, I decided to give you a list of things I think you should adopt.

Fail Fast
Keep the cycle between coding and knowing whether your code works as short as possible. Make it as easy as possible to know whether code works — ideally with excellent coverage (both functional and code) in unit tests that can run during a compile cycle.
If something doesn’t work, you want to know it before your developer has time to get up and fetch a cup of coffee. If that’s impossible, he should know by the time he gets back to his desk.
It should also be clear how the failure is related to the code. That means:

  1. Self-documenting code
  2. Self-documenting test cases
  3. Test cases that test one thing, and one thing only
Keep the build fast
I’ve worked on projects where hitting F7 (build) meant going home for the night. This is not a good thing: it gets developers to write a lot of code without every building, let alone testing. That, in turn, slows down the development cycle which has all kinds of nefarious effects.
Automate testing
Note: not just tests: testing. You want to get tests running without anyone having to think of starting them. You want to automate feed-back to your developers. You want to tell your developer (politely) that he’s made a mistake and should repair it before he inflicts the code on others.

About rlc

Software Analyst in embedded systems and C++, C and VHDL developer, I specialize in security, communications protocols and time synchronization, and am interested in concurrency, generic meta-programming and functional programming and their practical applications. I take a pragmatic approach to project management, focusing on the management of risk and scope. I have over two decades of experience as a software professional and a background in science.
This entry was posted in Quality, Software Development, Software Engineering, Software Testing and tagged . Bookmark the permalink.