joe codes

x-cart guru & custom programmer

  • About
  • Archives
  • Contact

Powered by Genesis

My Personal Three S’s of Development

June 3, 2015 by joecodes 1 Comment

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.

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Reddit (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to email a link to a friend (Opens in new window)

Related

Filed Under: Programming Tagged With: Apple, security, speed, stability, WWDC

Trackbacks

  1. Apple vs Pro says:
    June 12, 2016 at 10:55 pm

    […] year I commented on the rumored focus on quality before WWDC. I thought I’d do it again this year, but […]

    Log in to Reply

Leave a Reply Cancel reply

You must be logged in to post a comment.

Quick Thoughts

  • I was surprised to learn that foreach in JavaScript does not have a traditional break. The loop will run to completion.

  • Who knew that combination sums across all permutation lengths of an array would be so difficult? It was a challenge but the final product looks good and takes a lot of resources. Limiting the max length for basic memory limits. Would only do something like this for occasional reporting.

  • Working on a new project that can have hundreds of forms on a page. The browser was spending way too much time in Parse HTML. Wasted a bunch of time before learning this is a long-standing bug in Chrome when there are many forms or inputs. Other browsers are fine.

Recent Posts

  • Parting Ways with OWC
  • MacBook External DVD Player
  • Progressive Enhancement
  • Keychain Password Search
  • Smarty preg_match

Tag Cloud

Apple JavaScript Mason Perl PHP security simple Smarty speed stability Tax WWDC X-Cart

Search

Subscribe

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Comments

  • Bad App Alert on Startup Item Help
  • iPhone Pre-Order Needs to Change on iPhone Pre-Order Warning
  • Apple vs Pro on My Personal Three S’s of Development