All posts by Peter Mangiafico

Technology

All your internet are belong to us

2 Comments

Google just announced that their new Chrome OS based laptops (built by hardware companies like Acer and Samsung), will run only a web browser and all your apps will be on the web. It’s not a new idea. In the 90s, Sun Microsystems declared that the “network is the computer”.  They turned out to be right in some ways, such as enterprise, back-office applications, and the rise of web-based email. They were a little ahead of their time, and it took a while until Internet broadband and mobile devices made a “cloud” based data strategy viable.  We’re getting there.  I just don’t think we are quite there yet.

Googles’ is an interesting strategy, and their slick promotional video sells the idea by pointing out that the device is not really a computer – it’s basically a portal to the web, where all your stuff is stored.  If you toss it into a river, you don’t lose your data.  They also claim you don’t need to ever update it, since it updates itself automatically over the web (which most modern OSes do anyway).  These are all true, but unless *any* app that a user accesses works perfectly online, Chrome OS users are in a frustrating experience.  Ever filled in a big web form, only to hit the submit button and realize you went offline in the process, and then when you hit the back button in your browser, all your work is gone?

I do like the idea of cloud-based apps and use many myself, but I’m still not sold on the “everything can run in a browser” attitude, at least not today.  In fact, as the task specific iOS and Android apps have proven, web-based apps are often limited in various ways and a “native” experience is better.  Web browser’s need a lot more work, and while I haven’t seen Chrome OS in action, until I do, I won’t be convinced it’s ready to stand in for a competent full OS.

Finally, I’m also not sure most users are ready for the idea that all of their personal data is out there on the web, in a sort “trust me” type relationship.  A lot of tech companies (Google included) have some PR work to do to convince people that their personal data is safe.

So getting back to Sun Microsystems – whatever happened to them?  Don’t know?  That might be a cautionary note for Google.

Technology

Look at you JavaScript, you’re a big boy now

Oh, JavaScript, I remember when you were but a little baby.  Remember how you used  keep us all up at night with your pop-up errors in Internet Explorer 4 for each missing semicolon.

Remember how your most used event was “onclick”?  And that the most used action was “window.open”?

Remember how people looked down upon you as an inferior language?  “You mean I need to write JavaScript too on the client?  What’s wrong with ASP on the server?”

And then, you started to grow right before our eyes.  Remember the first time we saw you in Google Maps?  How the heck can you just keep scrolling the map without clicking buttons to update the whole page, we thought.  What magic is this?

And it was you, humble little JavaScript.  Growing up quickly.

Soon, you proved you were no little inferior language.  You picked up some nicknames, like ajax.  And you became part of big fancy projects, like Prototype.

And all of sudden, people wanted you to work with them instead of cursing you as a mere infant.  You became the shiny new kid in town.  “You mean your app doesn’t use ajax?” they would say if you weren’t around.  “That means you’re not web 2.0!”

Now I can’t go anywhere without bumping into you.  All the cool kids want to play with you.  Node.js, jQuery, Backbone, they all come calling for you.  Hell, big daddy Google would probably be lost without you.

Sometimes I miss the good ole days: frames, blinking ads, and pop-up windows.  But mostly I’m glad you are grown up.  Just don’t forget to call home every once in a while and say hi.

 

 

Aviation, Technology

What becoming a pilot has taught me about managing software projects

In my professional life, I develop and manage software projects.  In my personal life, I am a recreational private pilot.  Becoming a pilot was challenging but extremely fun, and continues to be a great learning experience.  I’ve found that the process of becoming a pilot has taught me a lot of useful things about how to manage software projects.

When you are taking flight lessons, you need to learn many different things, in a broad range of topics.  You learn some academic stuff (like aerodynamics and meteorology), some hands-on stuff (like how to actually control an airplane) and a bunch of details (like airspace regulations, and other rules and numbers you just need to remember).  But one of the most important lessons you are taught is problem solving and resource management.  In other words, all that knowledge you gained during your lessons is no good if you are too stressed or overwhelmed to keep control of the airplane and get it to its destination safely.

Here’s four key points I’ve taken away from my flight lessons and how they can be applied to software projects:

  1. Use checklists. The human brain can only hold a small number of things in short term memory at any one time (somewhere around 7).  Pilots use checklists to avoid relying on the memory limitations imposed by human anatomy.  They are used at just about every stage of flight, from approaching a plane for the first time, until it’s parked and tied down at the end of the flight. Forgetting one small but critical item (like neglecting to release a handbrake or setting the fuel mixture to the wrong setting) can have some very serious consequences.  By regularly using a checklist, you ensure you do the same things every single time and in the same order.  This idea is useful for many other areas (in fact, a whole book has been written on the subject).  Deploying a server, make a list.  Testing a release, make a list.  Need to fix bugs and track which ones you have fixed already, make a list.   And the great thing about software development is that you can use scripts to automate your lists.  What could be better than typing in a command like “deploy_server” and having all the items on your list execute the same way every time.  It sounds simple, but how many people do you know that do something repeatedly, but manually, and from memory.
  2. Have a flight plan and stay focused. Before take-off, pilots make a flight plan – sometimes on paper or via software, and sometimes in their head (if they are only flying around the airport for some practice).  The plan includes a goal for the flight, a destination, some alternates in case the first plan doesn’t work out, and a personal assessment of whether you are up for the flight.  If you have a lot on your mind, are feeling distracted, sick, or otherwise not ready to stay focused, then you are trained to not take off in the first place.  Once you take off, the only certainty is that you will be coming back down at some point – hopefully on a runway.  The same is true of software projects – once you “take off”, are you committed to seeing the project through?  Are you ready to stay focused on the primary goal of the project?  Do you have alternates when the primary plan needs to change mid-course? Do you even know what that goal is?  Does everyone on the team know what it is and do they agree to it?  If you paused when answering any of these questions, maybe you need to revisit your flight plan before you take off.
  3. Aviate, Navigate, Communicate. When flying a plane, your most important job is to, well, fly the plane.  It won’t do much good to know where you are and tell someone about it if you crash in the process (unless you care more about them finding your wreck than you do about walking away from it).  FAA crash reports are filled with people who crash after losing control because they were fiddling with a GPS or worrying about what to say to air traffic control.  Those three words remind you of the order in which you should focus your attention: only after ensuring the plane is under control should you worry about navigating, and only after that should you worry about talking to ATC.  In software projects, however, I think you need to go in the opposite direction: Communicate, Goals, Code.  Coding does you no good if you don’t know why you are doing it (the goals),  and having goals is no good if everyone on your team (and your customers) doesn’t know what they are.
  4. Use check points.  Whether using GPS or compass, maps, and a clock, before setting out on a flight, pilots mark down prominent points along their routes (a river crossing, a large town) and the approximate time into their flight they expect to pass them (based on winds and estimated airspeed).  Once airborne, the pilot ensures that these check points are passed at about the right times.  If not, you are either off-course or moving slower than expected (or both).  Either scenario is bad, since unexpected fuel starvation in an airplane is a very bad thing (which unfortunately is also common in FAA crash reports).  The same idea applies to software projects, where you should have regular check points to be sure progress is moving as planned.  Software methodologies like Scrum and Agile have iteration meetings every few weeks where you can adjust course as needed.  Projects get to be one year late one day a time, and while having these regular check points won’t necessarily make you go any faster, it will let you make more informed decisions.

One of the unique things about being a pilot is that once in the air, you are keenly aware that your life and the life of everyone in the plane with you is in your hands alone (the same is true of driving a car of course, although you have the luxury of pulling over if you suddenly decide you aren’t fit to drive anymore).  Most software projects don’t have that same level of importance, but they can still benefit from the all tricks that aviation has come up over the years for keeping that key take off/landing ratio = 1.