This isn't a new insight into software engineering but it's one I've been reminded of recently and not everyone knows about it or at least not everyone remembers to apply it.
"If it hurts do it more often"I don't know if Martin Fowler coined the phrase but he certainly talks about it here and a google search reveals loads of blog posts about it. If you know who originally coined this phrase or how it came about as an insight into software engineering then please let me know via the comments section below.
I find it is really useful to consider this rule whenever anything on our software projects is painful. No matter what it is. It seems counter intuitive at first but there have been too many projects that have failed or had a stressful last couple of months because they've left something painful until the last minute like testing or integration.
In our case we are planning our approach to a project which will involve integration of our software components with hardware and software components developed by different teams. The answer here is fairly obvious. Instead of integrating with other teams once every two or three months we really need to be doing this much more often. Even integrating once a month is going to be much more beneficial than every three months, especially in a project which will take about a year to complete.
We should also be finding ways to automate a suite of integration tests and running them every time someone checks-in any code in, or at least overnight if the tests take a while to run. Although the developers on the project will be writing unit tests via TDD, integration tests and acceptance tests we really need a single person dedicated full-time to the automation and implementation of a full suite of integration tests across all of the teams and all of the components.
If we don't have a software engineer with testing experience and a testing focus to start working on automating the integration aspect of the project from very early on in the project then the pain of integration will be delayed until the end. That will then cause the project to slip past it's due date and we would only know about this slip right at the very end of the project where it's too late to do anything about it.
Please leave a comment if you've either seen projects fail because they didn't do something that hurt more often or succeed because they did do something specific more often.
Posts
