Richard Cowin

Goals for frameworks, languages, libraries, and tools (Goal 1)

As I was thinking of the key goals I want to achieve as Rico moves to 1.2, I came across a new post by Andy Hunt on Why Ruby.  He talks about  how one of the two main reasons he likes ruby is that it "stays out of your way".  I agree that Ruby does a great job in this area by  allowing itself to be molded to the problem at hand without getting in the way. 

This is probably one of the hardest and yet most important goals of any framework, language, library, application, or tool.  I think a good framework/library should allow itself to be shaped to easily work with required technologies and processes that are in place.  Being opinionated is great, but only in the areas that the user does not want to worry about. 

One of the tricks is to understand what are the required technologies 'it' must work with.  In the area of javascript libraries that clearly means existing HTML and CSS content.

So number 1 goal is to "stay out of your way".

Paths, Roads, and Highways

This morning I did my Monday morning commute (200 miles) that I am doing 3 times a month for the last couple of months.  I am just getting to that point where I can zone in and do the trip without much thought as to where I am.  At this point, I only become aware of the landmarks and towns when I am curious how my timing is doing.  With about 90% - 95% of the trip being highway, I make pretty good time.

The great thing about highways and roads is that they get us where we want without too many detours and with reasonable road maintenance (well, better than driving across the country side without roads).  Roads are kind of interesting in that they restrict where we can drive and yet they provide a lot of value by typically following paths that others have traveled in the past.

I am not particularly interested in expressing my creativity and freedom by driving across arbitrary fields that don't have roads (besides, my wife gets plenty upset with what little off-roading I do).  I am much more interested in getting somewhere in the quickest and simple way possible - scenic drives are part of a different story.  We are content to live with this restriction, because it adds lots of value to our lives.

As we evaluate frameworks, we need to consciously decide which part of our work we need be creative in and what part we just want to get done with minimal effort and thought (but with sufficient quality).  Frameworks like Ruby on Rails, really restrict us in many ways (for example: directory structure), but allow us to really concentrate our effort in areas where creativity matter to an application.

I also think back on the old story where an architect waited to lay the sidewalks at a university until after the first snow.  He then looks at where the majority of the people tracked through the snow and lays the sidewalk along those paths.  You can see this as a kind of framework extraction process as well as a wisdom of the crowds sort of thing.

So, as we looks at software frameworks, we really need to understand how they restrict us so that we can spend our time and effort to be more creative in areas that add value.

Kathy Sierra has a great right up on using constraints to increase creativity in her post "Creativity on Speed".

Well, this road stuff might be stretching it a bit,... but it seems far better than most road based metaphors used by large enterprises in the technology field.  And besides, I have to think about something for those 200 miles.  Happy driving.

Software Habitabiltity

One of most important indicators for software quality is habitability.  This can be see this from 3 perspectives:  Firstly, how habitable is the code for others to live comfortably (convenient and simple) with.  Then of course, there is always the habitability of the UI from the users perspective.  And lastly, there is the habitability of the application for those that must administrate it (it is a good citizen and easy to administrate in the environment it runs in).

Of course habitability is not easily appreciated in software (like buildings) until it is in an executable form and is actively used in all three of these perspectives.  I also find it interesting that if the software is truly habitable, then the time spent by all three of these user types is minimal.  Or, at least it is fairly transparent in that the software stays out of your way or does not distract you when you use or change it.

As I recall (though I can't find a specific quote right now), Christopher Alexander always emphasized that one one of the most important criteria for quality in an architecture, is that the building must support (if not enhance) the peoples daily activities as they flow through it. 

I will try to explore habitability in software  applications and their associated frameworks as well as delve into the three perspectives of habitability over the next few months.

What are those buttons doing in my class?

The discussion between Martin Fowler and Elliotte Rusty Harold on Humane vs. Minimalist approach for collection interfaces has already spawned sufficient debate over all the factors.  However, Elliotte used a bizarre analogy between remote controls and class interfaces and for some reason this comparison bothered me. Then, I thought "Hey, there might be something to learn from the remote control".  So, here is yet another perspective on the issue:

OK, first a quick review of my history of media center remotes:

• First there was the remote - cool
• Then came the the features with buttons - I started making purchase decisions based on which remote had the most buttons - ahhhhh
• Then came the multi-purpose buttons with special modes - more features!?
• Then came the other components w/ more remotes - hmmm??
• Then I could  not find the remotes - Oh, I can tape them all together!?
• Then I noticed  that the controls all had different shapes of buttons with different layouts and different functionality - hmmm?? 
• Then I realized that I didn't understand most  of the buttons - what language were these guys speaking - not mine???
• Then I eventually remembered only the buttons I use - I still can't find the stupid remotes.
• Then Apple introduces front row that provides a new construct (easily accessable menus) for finding features -  now they are talking my language
  
• Then I got rid of most of my remotes - they are reduced, but I would prefer having just one!
   

Note: This may not directly reflect my own or any actual history or occurences. 

Lessons learned:

• I hate searching for remotes - I can never remember where I put it or what I called it - they should always be where I want them
• Lots of remotes are not good - one remote is better
• I don't have a real issue with buttons as long as their behavior is predictable and work similar to other buttons
• I hate having to press different buttons to achieve my goal - I confuse easily and have a poor memory
  
• The laguage should be mine (the guy who wants to be entertained) - not the feature happy designer who wants me to press each and every button
  
• I mostly like  to be ignorant of the small details of how the remote/component works - details should not be in my face every time I use it
• Remote should not require large context switch - it should just do what I need

Overall Lesson:
Really creative products, that make my life better, seem to ignore old rules and boil the design essence down to the consumers ultimate goals. 

Conclusion:
I guess I prefer minimal controls/classes with intuitive interfaces that don't distract me from what I am doing.