Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 534 posts at DZone. You can read more from them at their website. View Full User Profile

The fear tax

08.27.2010
| 4707 views |
  • submit to reddit

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.

On one system we worked on had a requirement to write some Javascript code to encrypt the data sent from the browser which was then sent securely through SSL to the web server.

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…

 

References
Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jonathan Fisher replied on Fri, 2010/08/27 - 9:18am

I don't think your security requirement was necessarily 'over the top'. Requirements calling for a trusted client are not all uncommon... If you get a chance to re-design your application, you should consider Bi-Directional SSL rather than encryption with javascript. Remember, no security is fullproof, therefore all security must be layered. I would like to correct you on one point: Trusting an IP address is NOT security, in any way, shape or form. IP is not a secure protocol, therefore, IP address security is not secure. You'd be better off without it, since it will make you paranoid about the real security problems. I've seen people have entire applications be 'secured' by trusting one IP address. This is a ridiculous assumption... IP addresses are not authenticated, you can tell if the IP address is NAT-ing 5 untrusted clients.

Steven Baker replied on Sat, 2010/08/28 - 11:53pm

this is classic from enterprise architects (or even just software architects). seems they are just trying to justify there role (and pay).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.