The fear tax
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Seth Godin recently wrote a post about 'the fear tax' which he describes as a 'tax' that we pay when we do something in order to try and calm our fear about something else but don't necessarily end up calming those fears.
We pay the fear tax every time we spend time or money seeking reassurance. We pay it twice when the act of seeking that reassurance actually makes us more anxious, not less.
I think one common example of a time we fall into this trap when developing software is around the security of financial systems.
Due to legal requirements that firms operating in that domain operate under we can often end up with a very complicated security solution which is unnecessary for allowing us to achieve what we want to.
Once it reached the web server we then had to send it in a SOAP message to a backend server where it could be unencrypted through the use of a private key.
Since one end point was in Java and one .NET there were slight
incompatibilities in the way they handled security so it ended up taking
a lot of time to actually get it working properly.
We had this extra security around the messages on the backend to protect against an unauthorised server trying to send messages to that server.
This despite the fact that the backend server was behind a firewall which would not accept any requests that came from servers outside the specified IP addresses of servers known to be in the DMZ.
In other words in order to remain compliant we were paying a significant fear tax in terms of increased complexity of our code base and the time taken to get all the code working in the first place.
Another simpler example of this that is often found in code is checking whether an object being passed around the code is null.
I've worked on code bases where we've ended up checking whether a particular object is null 2 or 3 times.
Alternatively we can use a pattern to take this problem away and then we don't have to worry about it again.
Seth's closing advice is as follows:
Instead of forgetting about the wasted anxiety after the fact, perhaps we ought to keep a log of how often we needlessly pay the fear tax.
Instead of over-staffing, over-planning, over-meeting and over-analyzing, perhaps organizations should take lower-cost steps and actually ship.
Think about how much you could get done if you didn't have to pay a tax to amplify or mollify your fear…