Don’t Build A Security System Until There Is Something To Secure

I know a lot of people give credit to the idea of “time to login“. Personally, I don’t think that’s the right way to look at starting an app. (Note: As Joshua Flanagan pointed out in the comments below, I completely mis-represented the post I linked to. Sorry about that. The rest of this post is still valid, though.)

Let’s say you are hired to build a time-punch machine, for clocking in and out of work. Do you immediately go and build a secure room with a buzz-in door and hire an armed guard to make sure only actual employees can get to the time-punch machine? Or do you build the time-punch machine and once it’s ready, figure out how the company wants to secure it? Chances are, it’s enough to just have a card wall where people keep their cards. You grab your card and punch-in or punch-out. You don’t grab other’s cards. It’s the honor system and it works. (yes, that was an extreme and probably ridiculous example, but it gets the point across)

Back to software, now… If you’re hired to build a time-tracking software application, why do you want to go off and build a security mechanism first? If the time-punch machine can use the honor system, why can’t the first working version of the time tracking app? Maybe the first version can just deliver a screen that let’s people enter time and write their name in as one of the fields.

It’s About Value, Risk, and Validation

When a client asks you for the time tracking app, their goal is to track time. Yes, they also want to make sure people are tracking their own time and not messing things up. Eventually a security mechanism will be needed as it helps to solve some of these potential problems. But delivering a working version of the time tracking page(s) first gives you much faster feedback on the direction of the app, with something that is actually valuable to the customer – for more valuable than just a login screen.

There is also a lot of risk in building a security system first. It’s very easy to over or under engineer a security system and find out that you built a secure room with armed guard when all you needed was an “on your honor” sign next to the card wall. I’ve often spent weeks or months building a full security system with role management and permissions that are stored in a database, etc, just to find out the client really needed something simple. I’ve also found myself in the opposite corner, building something simple and then the client coming back and saying that they need something much larger. It’s difficult to know with any certainty what kind of security needs a system will have, until there are things that actually need to be secured. Once those exist, though, it’s easier to judge how they need to be secured and how access to them needs to be granted.

As someone who has been a client, and now someone that is in the business of making clients happy, I can tell you that I want to see functionality first. It’s hard to get validation of what your building when you aren’t building the thing that gets you to your end goal. So, don’t build a security system until there is something to secure.