My Personal Three S’s of Development

In the lead-up to Apple’s WWDC next week with the supposed focus on quality I thought this would be a timely topic.

Over the years I feel like I’ve learned a thing or two about building new systems. “New systems” is a generic term you can apply to just about anything you do. This could apply to adding a new feature to a car, or coming up with a new idea for an app, or anything in your field of interest or expertise. While the shiny and whiz-bang features get all the attention, none of it matters one bit if the development of this new thing doesn’t start with the following three S’s.

1. Security

What does it matter if your new feature does not first and foremost consider its effects on security? Ask yourself what would users of your system lose if someone else gains access to the system or if the system gives them the information. If you are opening them up for security issues then you are affecting them so much deeper than you can imagine. If you make something new and it is not secure, just throw it away. We don’t need your amazing new thing that bad. If security is not the number one consideration for even the simplest of features, you are doing it wrong. Just walk away and don’t come back until you’ve changed your tune.

2. Stability

A close second, and closely related, is stability, which is related to security. If a system becomes unstable or crashes because of your new feature you are thereby affecting security at some level. If it is buggy, kinda works, or sometimes doesn’t show up then go back until it is fixed. Otherwise, what you are doing is a half-job. Maybe you are under a deadline or need to get something up quickly. If it is an emergency stop-gap you better already have plans to actually finish it (make it secure and stable) the first chance you get before going on to your next new feature. Yes, I am repeating myself on purpose: if you making something new and it is not stable, just throw it away. We don’t need your amazing new thing that bad. I’d rather have a stable system without the new feature than unstable with.

3. Speed

This isn’t last in the list of considerations, but the last of the top three. Your new feature and all the cool things it does are way down on this list. If you’ve made it this far and your new thingie is secure and stable, it should still be tossed if it doesn’t pass this final test. It must be optimized until it can be optimized no more. It should be even faster than it is now. More lines of code bummed. More optimizations considered and tested until it uses the least amount of memory, cpu, power, fuel, whatever it is.

I thought I’d do a quick look to see what others have written on the subject and was surprised to find very little. I’m glad Apple has another renewed focus on these things, but why now and why this late? To the rest of you, why haven’t you been doing this from the beginning? Why are you letting anything out the door that is insecure, unstable, or slow? I don’t get it. It’s like backwards thinking.

If I were to add a fourth item to this list, it would be Simplicity. If the new system is not simple then it’s probably not done right. This is similar to other optimizations for speed but with an end-user focus. I think it’s best to leave this list where it is and maybe touch on simple systems separately.

If it just works that is not good enough. Sure, get it working, then go through this list and make sure it is as secure, stable, and speedy as possible. Then do it again. If it’s not secure, stable, and speedy then I am not interested, and you shouldn’t burden other people with your junk. You are wasting our time and quite possibly jeopardizing our very lives.