David Hume’s Guillotine tells us that we cannot derive an ought from an is.
Abstract philosophical musings you might think, but then again, you work in software, so you know that philosophy matters, right? I want to muse on this for a while, and not in an abstract realm. I want to take this down into the real world. I’m going to take the law at face value. If it really is true that an ought cannot be derived from an is, what should we do differently?
“How can I automate this?”
“Should I automate this?”
Two similar sounding questions, but which one you start with makes a world of difference. How often do we start with the is? We start with the fact that we have a framework in front of us that let’s us easily add tests, or the fact that we are told to automate everything or even the ‘fact’ that manual testing is too slow or too cumbersome for the modern software shop. But aren’t we forgetting something? Aren’t we forgetting the law our friend Hume told us about? Just because we can do something doesn’t mean that we should.
This applies at every level of software development (because what is software development except automation?)
Should you make this product?
A number of years back the company I work at started a new initiative. We had acquired two previously competing products and after the acquisitions we decided to try and combine the best of both products and re-architect everything into a new product. It seemed like a great idea and we put a lot of effort into it for several years, but recently the product was canceled. Why? Because we had decided that this product did not need to be made. Some people were interested in it, but market analysis and other factors indicated that it was not worth further effort. We might have been right or wrong about the market forces at the play and the strategy employed, but this does illustrate something. Could we make this product? Sure. Should we? Not if it won’t help people. Not if it will lose us money.
Just because you can do something doesn’t mean you should.
Should you automate this?
What about an example that is a little more related to test automation?
At one point I worked with a team that did workflow tests. These were scripts that we would run through every morning to check if the nightly builds were ok. As you can imagine they were boring to do and so we decided to automate them. Makes sense right? Automate away the boring stuff. We don’t want to spend half an hour every morning working through the same boring scripts. So we went ahead and did it. We automated them, but should we have?
I’ve talked before about how boredom can be an indicator that you should automate something, but that it can also be an indicator that you are doing something useless. So which is it here? I think a bit of both actually. We automated them all at that time, but since then we have removed or changed many of them. There are still a few that have stayed around because they are valuable, but we certainly didn’t need as many as we had.
This once again illustrates the point that just because you can automate something doesn’t mean you should. If we start from the is – is this possible? Does a framework exist that allows me to do this? – we never get to the ought – does this make sense? Will this be valuable? If we had started with ought questions we would have just gotten rid of half the scripts we had and automated the few that were actually valuable. Instead we started with the is questions and ended up spending a lot of time creating and maintaining tests that we really didn’t need.
We need to start with the ought. In the software world we (understandably) love using software to do things. Sometimes that is the wrong answer. Sometimes there is a non-software solution to something. Sometimes we are just doing the wrong thing and so setting up systems to do it faster isn’t helping anyone.
Start with ought. Know why you do what you do. Take a minute to think things through before you plunge in and start doing. If you know the ought, figuring out what to actually do becomes much easier