It was about 19 years ago now that a colleague of mine lent me a copy of a little white book. That book changed the way I looked at programming more than any other book (though The Pragmatic Programmer gave it a run for its money). One of the things, in particular, was Test Driven Development, or TDD.
With the upcoming end-of-life for Bamboo Cloud, I’m in the market for a new build server setup. For this1 experiment, I’m returning to an old favourite – Jenkins – paired with a potential new favourite – Docker. In this post, I describe how I’ve set up a Jenkins server in a Docker container, using the Multibranch Pipeline plugin to automatically configure a simple build2.
Came across this article by Steve Blank – “Startup Suicide – Rewriting the Code“. This can be summed up as:
- Under the pressures of growth, some startups allow their code base to get messy.
- This mess – and the pressure to keep it working – results, over time, in a slower delivery of features.
- This leads to a failure to adapt, which is seen as an existential threat to the future of the business,
- The business decides that a rewrite of the product is the way to go.
- This leads to death.
I don’t dispute the main premise of the article, but I do dispute the title. The answer is to rewrite the product. The question is: how do you do that?
I’ve been recommending a similar approach – though not as completely fleshed out – for the last few years. (I organise the spine of my map as a mind map, though – I like spreading it out in 2d instead of just a line)
One of the odder practices of “conventional” software development that I’ve ever come across is the post-release test cycle. It’s something that has baffled me ever since I first saw it; you go through the normal development cycle, including testing, and then you deploy to production – and then you test it again. Sometimes with test cases that weren’t done during development. Why?
“The build server uses the Git plugin for Jenkins to monitor all the branches on the local repository. Whenever a developer pushes to the repository, Jenkins will see the change and try to merge it into the stable branch. If the build passes, the merge is committed. If it doesn’t pass, the FeatureBranch doesn’t get merged – and it will stay unmerged until another change is made against it.”
This feature means that broken builds have almost no impact on team productivity. In fact – it can even be more productive to allow a broken build than to try to prevent it all the time.