You don’t want to be a software developer. Or at least I don’t want you to be, I want you to be a software engineer. It may seem to be simply a semantic difference, but it’s an important one. Developers write a lot of software, implement features left and right. Some of the best ideas I’ve seen come from developers I respect. The critical difference is that developers omit the well known engineering maxim.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupéry

You should apply that maxim to every single line of code, every import/include, every decision, every packet, every expectation, every thing!

It’s trivially annoying when I come across needless cruft, but it’s beyond frustrating when stuff breaks, especially when it comes from people I expect to know better. I’m not just saying this with my “Get off my lawn” voice either, I can say it standing on my security soapbox too.

A gaming community, that will remain unnamed, allows it’s members to join groups anonymously. The system is complicated, but nice. Each group gets it’s own web-based chat room, and private forums; each with its own dedicated permission system. I actually like the system, the problem is every status/presence response includes a stack of metadata. At first glance looks like there’s nothing of value getting leaked, each roll is just a number with an array of other numbers. The problem comes when one member isn’t publicly listed, and another is. Once you can resolve the group roll id to a group name you can identify every member of that group, hidden or not.

Security and privacy data goes both ways, i.e., when your code requires the client to provide information that it doesn’t need, and then breaks when that information is omitted. If you have any desire to protect as much of your online privacy as you can, you should have already disabled your browser from sending referrers on each page request. That is, unless you want to login and do some online banking. Disable referrers and visit Chase.com. I know why they’ve decided this was a good decision, but expecting a header you don’t receive, and then allowing everything to break when it’s missing isn’t how you write good software. Less is more.

It’s not just requiring less, or providing less. You should also try and do less. You obviously don’t want any online account to be compromised, but just as bad is allowing a denial of service. We can argue about the correct number of failed login attempts before you do something. But there’s no doubt that if Eve is trying to guess the username and password pair, what you shouldn’t do is preemptively reset the users password. Passwords are already hard enough for users to manage, don’t do anything extra to make it harder on them. And, under no circumstance should you allow an attacker, without the password, to force a password change¹. I’m looking at you Wells Fargo!

If you’re not interested in building strong, correct systems, and you only want it to work, I’m not sure why you’re reading my blog, but you do you! Import left-pad and get on with life! But for those still reading, take a look at the code you’re working on right now, and ask yourself. “Is there anything here I can take away?” Not only will future you be grateful, and not only will I thank you when I inherit your code, but most importantly, none of your users will curse your existence, and isn’t that really what it’s all about? Making the fewest possible arch-enemies in life?