It’s always interesting to see what other developers use as their real workspace when they have control over it.  (Unlike cubical heck).

Once such sweet space is something Mitch Haile built.  I stumbled across it in one of me RSS feed consumption extravaganas and have to admit the space is really, really nice, but I have to say the screen real estate and mini server room/closet is very nice for a home build.

Just had to share the nerd eye candy for others to consume!

http://www.biscade.com/office/

Snaps on Flickr:

http://www.flickr.com/photos/bwa32/sets/72157607284828899/

Very nice work Mitch!  Kudos

There is a great Coding Horror write up by Jeff which gives a interesting perspective (most likely management.. but still the same) on the trade off of what your developer costs you and what new more powerful hardware costs you.

Hardware is Cheap, Programmers are Expensive

The post eludes to several key points, many of which I try to get management on numerous efforts to understand all the time.  Some hold true, but there is a point of no return.  Sometimes just throwing iron at it will only make more of mess (especially in the energy conscious era we have stepped into these recent years.)

Remember the quote, “To make money, you have to spend money.”… well the spin I see here is, “To save money, you have to spend money, sometimes.”

This directly ties into the The Programmer’s Bill of Rights.

I remember the days of Windows development that I heard that they did not want to give the development team too fast of machines, since then the code they wrote would never perform well on “normal” hardware that end users would have.  That was some what true, but much less important (excluding fancy fancy stuff) in a web centric world.  Now it has to deal with the size of the pipe and not the engine.

Over the years I have seen more times than not, is not about optimizing (as eluded to by Jeff) but cleaning and/or refactoring.  I usually find 9 out of 10 times if I refactor code when trying to make more out of it I get more bang for the buck.  But that also means you live a life of refactoring (which all good developer should).  This helps with:

• Stop the code decay / erosion.  All code dies over time.  (Try to get management to understand that one right?  Some developers don’t even understand it sadly enough.)
• Make the code more clear and concise for future developers who will have to read it.  (If it doesn’t you probably refactored wrong).
• Enhance the current functionality with less code (more bang for the buck).  Yes Virgina, there is a Santa Claus and this can happen to you too.
• Evolve the code to newer library/standards/technology.

The last bullet point is something I have found very important in the Java world.  You find that you have (or someone else) has written code for a project 5,6,10 years ago based upon JDK, lib, etc at the time.  If you evolve the code to use more modern JDK run-time libraries or even specific 3rd party libs/projects that didn’t exist back then, you can get some great windfall.  (Of course done with great scrutiny).

As always, there is not just black and white.  There is not just one solution to all problems.  Find the right shoe and make sure it fits.

This is an interesting read on a Google perspective on Mobile computing and the future.

http://googleblog.blogspot.com/2008/09/future-of-mobile.html

The excerpt that interested me the most was…

Sensors everywhere: Your phone knows a lot about the world around you. If you take that intelligence and combine it in the cloud with that of every other phone, we have an incredible snapshot of what is going on in the world right now. Weather updates can be based on not hundreds of sensors, but hundreds of millions. Traffic reports can be based not on helicopters and road sensors, but on the density, speed, and direction of the phones (and people) stuck in the traffic jams.

In my current consulting role, I see interaction with weather sensors, traffic data and other things dealing with transportation.  The thought that we could have devices (like your phone or other connected devices) have a cloud mentality and provide that data back in a collected form to state and local DOT or SHA could be very valuable.  But ultimately the long haul problem will be making heads or tails out of the huge flow of data, but that is what Google is good at right?

Final question though….

Will you like your device talking to other devices?

What if your shower radio started talking to the toaster and the phone about how good you sing in the shower?  What if they started sharing that info with the neighbor’s blender?  Hmmmmm