The Sherpa Project

I often hear people use the words effective and efficient interchangeably. While the two definitions are close, they are not exactly the same and they have different contexts where each is appropriate.

Here are the two definitions from the New Oxford American Dictionary…

The way I usually differentiate between these two terms and their accompanying mindsets can be partially described by thinking about taking a road-trip.

If I am trying to determine the best route to take to get from point A to point B then I have a variety of ways that I can reach my destination. When I choose which route to take - then I am thinking about effectiveness.

If I drive a specific route frequently then I can focus on efficiently navigating that specific route. If the road is paved then I probably want to drive my car (better gas mileage), if it’s a dirt road then I might need drive my SUV. When I apply the context of my route - then I am thinking about efficiency.

The differences in these definitions is slight, but important. When I focus on effectiveness then I’m looking at ways I can achieve a specific goal. When I’m looking at efficiency then I’m looking at optimizing the way I’ve chosen to achieve the goal.

If you think about the subtle differences between these two mindsets then it’s fairly obvious that software development almost always focuses on efficiency. Unfortunately, there are many times that we focus on optimizing our gas mileage while we are taking the wrong route to get to our destination.

When you need to focusing on doing the right thing then focus on effectiveness. When you need to focus on optimizing the right thing then focus on efficiency.

If you’re in a situation where things change frequently then effectiveness should be your focus. After you solve the effectiveness problems then you can focus on efficiency.

Over the past couple of days, I’ve been pulling together a simple Information Radiator for CruiseControl.net. The idea behind the project is to use the power of visualizations to provide simple, visible, and informative displays that expose the current-state of your automated continuous integration builds.

I threw this app together very quickly a week or so ago and I’ve been amazed at how addictive it’s become. In our team room, we have a dedicated monitor that is always running the application. The result is that you know exactly where the builds stand as soon as you enter the room.

I initially wanted to put this together as a temporary solution to picking out what items we will use to show our build status. We always bounce back and forth about Nabaztag, orbs, lava lamps, and other physical things to show our build status. It’s usually easier to find an extra monitor than it is to get a purchase request approved for a wireless-enabled rabbit. Big Visible Cruise is the same idea, it’s just a visualization instead of a physical device. Judging by how much we all enjoy seeing it, it will probably stick around in addition to any physical device we pick up.

You can find out more about the project at http://code.google.com/p/bigvisiblecruise/. After the holiday I’ll post some pictures and explain how we are utilizing the big display in our team room.

In the meantime, you can likely get an idea from looking at the display while it’s monitoring three different projects in the following screen shot…

This shows that I have three projects (Foo, Bar, and Some Project) being run on my CCNet server. In this example Foo and Bar are successful and Some Project is broken.

The other state that isn’t represented in the pic above is the “building” state. When a project is building, the row representing the project will turn yellow.

By default, BVC will poll every 15 seconds. I recommend using BVC with CCTray so that you have a big visual display along with auditory clues about your build process.

Big Visible Cruise is being released under the MIT license.

If you’re interested in WPF and/or information visualization, I’d love any contributions
I plan on providing some interesting visualizations over the next couple of months. Let me know what you’d like to see on the RoadMap page.

I don’t want your icon on my desktop.
I don’t want your icon in my taskbar.
I don’t want you to run on startup.
I don’t need a quicklaunch icon.

When in doubt, just ask.

It is easy to fall into patterns of practice in almost every profession. Software is arguably one of the worst when it comes to following stated “best practices” and looking for process frameworks or formalities that guide various stages of the software development lifecycle.

In theory, this is all great. In practice, it (mostly) sucks. The problem is that we try to be compliant with the wrong things and for the wrong reasons. There is no reason to be compliant with any framework, any process, or any certification unless it is results in creating value for your customers.

How many customers do you think know that you are CMMI Level 5 compliant? How many would care if they knew that you were? When it comes down to it, these certifications are useless if they are not working to make a significant effect on the quality of experience with your customer. For many processes or process frameworks, that’s exactly what they intended to do. Unfortunately, most of them ended up being a framework that is primarily concerned with building up huge amounts of waste.

I’m not sure when this all happened, but the one thing that I do know is that the majority of software projects that I have seen, studied, or have been involved with are obsessed with process and not with customers. This is one major reason that I began to question everything that I do on a day-to-day basis. When I started asking “Why?”, I started realizing that a satisfying answer was the exception. The majority of what we do, we do because we learned to do it that way.

So, what can we do about it? I think the answer is to look at things with Beginner’s Mind. Start to question your process, start to question your activities, start to question your intent, and start to think in terms of your customer.

Can you imagine what would happen if you took the time that you spent on “compliance for compliance sake” and spent that time with your customer? If we replaced the time we spent on a technical specification with having a couple of drinks with our customer then it would probably be for the better. If we removed the time wasted on the formalities and politics involved with functional specifications and put the effort towards understanding a day in the life our customer, or if we replaced change control formalities with a weekly game of golf with our customer then we might really get somewhere.

In short, I think there’s value in making the move to unlearn and look at everything with new eyes. Simple economics and common sense make me think that we might just have the ability to make better software.

Why is it that a general best-practice is to have strong passwords when most applications don't support them? I tend to use (very) strong passwords, but it seems like I'm discouraged more often than I can utilize them.

Is it really too much to ask?

You can find it here.

This article made me smile.

Why can’t we just all do things this way?

It’s possible, it’s easier, and it makes sense.

I can only hope that one day we’ll all wake up from the nonsense that we’ve believed for so long and ask “What the hell were we thinking?”

About a week ago I purchased the Getting Real book from 37signals. I’ve been eagerly waiting for this book to come out for a while now and I can say that it was well worth the wait. The book (available only as a pdf) is entertaining and very thought provoking. I can say that I agree with almost every one of the statements and sections in the book.

The biggest value for me in the reading of the book was the ability to be exposed to ideas for design as well as development. My primary activities mostly center around development on a day-to-day basis, but the insight into the design ideas in the book were a big eye-opener for me. I’ve preached most of the development-centric practices that are outlined in the book and it was nice to view the logic behind each of the sections in the book. The book also contains many good quotes that are provided from a diverse set of individuals.
I would recommend this book to anyone and promise that it will be well worth your $19.

I’ve been playing more and more with Ruby On Rails lately and it has been a very mind-opening experience with regards to many of my ideas around application architecture. There are many wonderful things about Rails, but the idea (and implemenations) of “convention over configuration” is demonstrated beautifully within Rails.

My development experience has been primarily centered around .Net since the early betas of .Net 1.0. I’ve completed dozens of production systems with .Net and there are many ideas and thought processes that repeat themselves over and over throughout each project. In some of my earlier projects, I played with the idea of convention and decided that there was too much “magic” in many of the convention-based implementations that I participated in. After a few different attempts, I finally gave up on convention and fell back to the typical .Net configuration as the norm for my projects.

I have to say that Ruby On Rails has completely changed my views on the power of convention. From my (limited) experience with Rails, I would have to say that the conventions that are built into Rails provide provide a ton of acceleration in producing working web applications. I love the idea that almost everything is based on convention.

The way Rails encourages convention provides for rapid development, prototyping, and results in cheaper applications. Convention is encouraged throughout Rails by assuming that you are following convention (plural table names, primary keys named id, urls indicating actions, etc.) while still allowing the flexibility to deviate from the conventions when necessary.

I’m still not sure that one-off conventions are extremely valuable in .Net because they would not be standard conventions and would likely widely differ between projects and across companies. I think that the potential is there, but some type of framework would need to be established to (at least partially) encourge common conventions across projects. As an idea, convention is a very powerful concept, especially when it’s built into a framework (or an acceleration platform). I’m hoping that something is on the horizon that will provide this concept to .Net and that it gains traction soon. I would love to be able to write .Net applications at the speed that I can implement Rails applications.

I attended the Launch Tour today and participated in the Ask The Experts booth for the developer track. I must say that I had a great time talking with everyone and that I was extremely impressed with the quality of the event. The sessions were wonderful, the turnout was great, and the discussions were very engaging. I appreciate everyone who turned out for the event and who stopped by the booth.

If the Launch Tour is close to you, I hightly recommend attending.