The Grubbsian

Folks, I think the time is nearing…may it come quickly.  I just loaded up IE8 beta 2 in a VM and I just realized that by the time IE8 is released, IE6 will be 8 years old and two whole versions behind.  The thought of trying to write rich-Internet applications for a browser that was released in mid-2001 is becoming more and more frightening.  

An interesting experiment going on over at 37 Signals: http://www.37signals.com/svn/posts/966-urgency-is-poisonous.  I think they might be on to something.  I know that my current project would have benefited greatly from this kind of freedom from urgency.  I can attest first hand that extreme urgency does not elicit the best code or the best mental attitudes from a team.

So I've been looking at some new languages recently, particularly dynamic languages like Ruby and Python.  One of the first things I noticed about their syntax was the lack of access modifiers.  I suppose the assumption could be made that since C# is type-enforced that it lends itself to access modifiers but I also wonder if maybe it's just a case of programmer mistrust.

If I'm writing an API that's going to be consumed by other developers, am I really so paranoid that I need to lock things away into isolated boxes to prevent misuse?  No, I think I fairly well trust consumers of my code to understand my code prior to using it or do so at thier own peril.

I can see the argument being made that it makes the API cleaner if implementation code is hidden from the consumer.  I don't disagree, but I think that problem is better solved by encapsulating implementation logic into a lower level class.  This has the added benefit of making the implementation available for anyone that wants to take a look under the covers, but still providing a clean API layer.

So what am I really proposing here?  Should we just mark everything public everywhere?  No, I don't think that's really what I'm saying.  What I am saying, is that it's interesting that a number of dynamic languages have decided to trust thier developers more than C# and I just think that's interesting.

The jury is still out on Google Chrome…most likely since no one has really been able to get their hands on it yet.  The browser is set to ship in beta sometime today.  But even before its release the very idea of a new browser begs the question… "Do we need another browser?"

Like most philosophical questions of this depth (mind you not very deep at all) the answer is varied.  Some say, "Yes, more browsers equals more choice equals more competition equals better features, blah blah balh."  Others say, "Are you crazy?  I just got over IE6!"  In my opinion, it’s not really about the browser it’s about the engines. 

I don’t care if the title bar of my browser says Microsoft, is a drab 1940′s post-ware gray (ala Safari), or has a little curled up fox gently engulfing the globe.  What I do care about is how the thing works.  As a developer, I crave consistency.  When I write a piece of code I want it to function precisely as I expect it to, and I want it to do that in every environment that calls it.  In this vein the nice thing about Google Chrome is that it’s built with open source pieces…it’s the Frankenstein of browsers really.  It has WebKit’s rendering engine, parts of the plug-in architecture are ripped off from FireFox, and I suspect that a its new JavaScript engine is built on concepts from a whole realm of different open source projects.

So, we’ll have to wait and see what comes of it.  If it runs Firebug, and is really as fast as they say, then it’ll probably be a good browser for developers, if not it will just be another "Oh that’s kinda cool", and then we’ll all go back to FireFox.

So, I’ve been working at a client location now for the past several months and up until about three weeks ago I was able to use my own laptop for most of my development.  Unfortunately, due to the security policy on one of our more recent projects I have been forced to use the machine provided (because it’s joined to the domain).

Now, this machine is very typical for this company, most of the developers have this exact setup.  Let me just give you the run down:

1. Lenovo ThinkCentre – Pentium 4 (2.xGHz), 1GB Memory, 40GB Hard Disk.
2. Acer 17" LCD Monitor (just one mind you)
3. Standard Lenovo keyboard (wired)
4. Standard Lenovo mouse (wired)

So there you have it.  The most basic business machine…ever.  If I was sitting in accounts payable, or in marketing, or even an IT manager this machine would be exactly what I need.  It would handle my spreadsheets, word documents, and emails with ease.  As a developer however, it leaves much to be desired.

So this got me thinking about the cost/benefit surrounding the choice of hardware for your development team…and the choice to plant this doorstop on my desk.  Developers are not typical users, they’re not really even power users, they are their own class.  Constantly restarting, installing, uninstalling, resetting, formatting, deleting, pegging the processor, running out of memory, etc, etc.  Basically anything bad that you can do to a computer, a developer will inevitably do.  So the first compelling reason to get good hardware is for the hardware’s sake…it will simply last longer and perform better for a longer period.

The second thing that distinguishes developers from other users is that their primary output is code…a medium wholly dependent on a computer.  Other positions within a company, while extremely reliant on computers and software, are not completely crippled when a computer is slow or temporarily unavailable.  So the second argument for quality machines is maintaining developer output.

The third reason I’ll highlight is developer happiness   Again, developers are not normal.  We are fickle but easily amused and really good hardware running well tweaked operating systems just make us smile.  Smiling developers write better code…it’s a fact.

So please, if you manage a development team or are responsible for provision hardware for one…think about the day-in-day out developer who’ll be sitting behind that tiny screen, and get him/her a bigger one.

The September issue of .NET Developers Journal will include an article authored by yours truly entitled, "Design for Developers".  It’s basically a primer for developers on the art of design.  I don’t consider myself a designer by any means but I’ve picked up a few tricks along the way and am fortunate enough to be given the opportunity to share my learning with the community at large.  I’ll post again when the issue is out with a link to the online version.