google chrome software updates make everything else feel broken


I am growing more and more annoyed at the Apple's and the Adobe's of the world who are constantly interrupting my work to tell me that there are updates waiting for me to install. Why do I have to manage this? Yes I know that I can go in there and tweak the settings so that I don't get annoyed... but why should I even have to do that? I would need to do that across every user account on every machine I use on a regular basis! (5) This is noise, and it isn't at all necessary for me to have to think about it.

I believe this is part of the convenience of applications delivered in the cloud. (sorry to throw that term out there) It is part of the convenience that has me accepting fewer features in order to get that functionality.

There are companies out there who understand this, and are working hard to create a better user experience. Google for example went to great lengths in order to be able to update their entire browser in under 100 KB of download just to make the experience more efficient, user friendly and safer. Not only that but chrome updates happen automatically, again to help with security. It's very close to the experience I get by logging into gmail, which is always up to date.  Now I can already hear rattles of complaint about "control" over your own machine, but I have to ignore this or I'll get completely derailed. I'll say in short that I think that control is an illusion, and the alternatives are worse.

If you have not already read this post by the chrome developers I highly recommend it.
http://blog.chromium.org/2009/07/smaller-is-faster-and-safer-too.html

And then you have the Apple, who has gone from a position of pushing hard to avoid needing to reset the operating system unless absolutely needed to requiring reboots for Quicktime, Safari and sometimes even iTunes (especially in windows).  You can argue all you want that it's because of kernel extensions or who knows what else - but at the end of the day it doesn't matter why. This is bad design and leads to a diminished user experience.


It seems like more and more often I am prompted with a software update dialog that looks like this one. Three out of four of the updates require a reboot! Are you serious? And chances are good that I will continue to ignore this dialog because closing all of my browser sessions, and ending the long running handbrake encode, and stopping the download I have going, and turning off the TV program I'm watching all amount to a whole lot of trouble for something I don't think I should even have to think about.

Seriously what is so special about Safari that they require me to download 36.2 MB and restart my machine for a point release?? Maybe this didn't seem so offensive before Chrome, but now it feels dated and clunky.

I really should pick on Adobe here for the horror that is the Adobe Updater, but honestly I really do expect more from Apple. Adobe is too easy of a target.

 Please fix this Apple, you can do better.  Where is the Steve Jobs who wanted to save lives by reducing boot times??

build it (so it's easy) and they will come (make the right decision)

One of the biggest lessons I think I've learned over the past few years is that you have to be very careful with what you make easy to do in a software system.


When you are working within a preexisting system, it is very hard to work effectively outside the bounds of that system. Whether you are limited by time constraints, peer pressure, political decisions or just pure technical inertia, those early/legacy decisions in a system will have long reaching impacts on the decisions of those who follow.

I'll give you an example. On a product I worked on for years, the decision to use an object relational mapper (ORM) in early stages was based on a desire to eliminate boilerplate code, reduce the learning curve for new developers and generally push the development of new entities down to the entire team rather than specializing this role in one person.  All in all the reasoning was sound, but the inability to see some of the psychological aspects that would impact the future had some serious impact on the future of the system.
  1. Developers stop thinking about database impacts because they never really SEE the database
  2. The object model and the schema become inexorably tied *
  3. Accessibility to the DAL ends up being given to junior developers who may not have otherwise dealt with it yet.** 
  4. Things that could reasonably be built OUTSIDE the ORM end up dropped in without consideration because developers are following the template. 
* This can be avoided by having data contracts that are specific to the DAL
** There is nothing inherently wrong with ORM, and if your DAL is properly abstracted so that the ORM isn't propagated throughout the stack then this too isn't necessarily a problem. 

I add those two caveats because I really don't have an issue with ORM, in fact I think used properly it makes way more sense then to waste days of development doing repetitive and simple CRUD work.

However the deeper issues that arose for us still focused on convenience. It was convenient to expose the friendly querying methods of the domain objects that mapped to our tables directly to the business logic assemblies. It was convenient to let junior developers write code that accessed those objects as if retrieval and persistence were magically O(1) operations. Of course in reality we discovered embarrassingly late that we had more than a few graphs of objects that were being loaded upon traversal, leading to a separate mapper triggered SELECT for each object and its children. This is the kind of thing that only becomes apparent when you test with large datasets and get off of your local machine and see some real latency.

And yes, in this case, I think you could argue that QA dropped the ball here. But as a professional software developer you really never want to see issues like this get that far.

I've picked one example, but there are many many others in the system I'm referring to. Including but not limited to a proliferation of configuration options and files, heavy conceptual reuse of classes and functionality that are only tangentially related to each other, and an increasing reliance on a "simple" mechanism to do work outside the main code base.

Ultimately, this post has less to do with ORM and proper abstraction and more to do with understanding how your current (and future) developers will react to those decisions. I think a conscious effort has to be paid to how a human will game your system. You need to come up with penalties for doing dumb things if possible, and the path of least resistance for the right ones.  There are entire books dedicated to framework and platform development that encompass some of these ideas, but they apply at every level really in my opinion. (except maybe the one man shop?)