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.
Continue reading “What TDD means to me…”
So for my first #BlogADayMay, I’m doing a rant I’ve had saved up for a while. Continuous Deployment, which is one of the new shiny hawtness going around, isn’t always the right thing.
Continue reading “Continuous Deployment isn’t always the right thing…”
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.
Continue reading “Setting up a Jenkins Server with Docker – Adventures in Learning”
Came across this article by Steve Blank – “Startup Suicide – Rewriting the Code“. This can be summed up as:
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?
Continue reading “Is rewriting the code “startup suicide”?”
The new user story backlog is a map
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?
Continue reading “Post-Release Testing – what’s that about, anyway?”
I mentioned in my last post how we have started using Feature Branches with Git and Jenkins. In that, I rather casually mentioned that
“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.
If you’ve been following my tweets recently, then you’ll know that we’ve recently converted the majority of our projects at work from Subversion to Git for our source control. We didn’t just do this because we wanted to play with a new shiny toy, but because we hope to achieve a new way of working. That’s what I want to describe here.
Continue reading “Making Parallel Branches meet regularly with Git and Jenkins”
The title says it all, but I thought I’d spend about eight hundred or so words saying more. 😉
I’ve seen a number of people think that “being Agile” is about having a build server, or about using Kanban, or an Agile project management tool. It’s not about unit testing, or pair programming, or continuous delivery, or devops, or any of a hundred other buzzwords. Don’t get me wrong – well performing Agile teams will be using these kind of tools and practices. But that’s not what makes them Agile.
Continue reading “Agile – it’s not about the tools you use”
I saw an an article on Seth Godin’s blog about positive thinking. Godin makes the valid point that people who think positively tend to succeed more, in part because their confidence means they don’t second-guess themselves. You can easily waste a lot of energy debating what to do.
A point that Seth didn’t cover is that positive thinking means it’s more likely you will attempt something new: if you feel you can accomplish a task, you’re more likely to try. Sometimes, when you try something new, you will succeed. Other times you will fail. When you fail, there’s a chance you will learn – and learning makes it easier to succeed next time.
One of the key take aways of agile development for me is “experiment, and fail early”. Fail early, fail often, fail cheaply. And learn every time.
Software is too expensive to build cheaply.... 