The Sherpa Project

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.

Found on Wikipedia…

“In Jeet Kune Do, one does not accumulate but eliminate. It is not daily increase but daily decrease. The height of cultivation always runs to simplicity.”

-Bruce Lee

Could your software use a litte Jeet Kune Do?

Nice and refreshing…

I just completed reading The Laws of Simplicity by John Maeda. Without a doubt, this was an excellent book. There are ten laws in the book and every one of them is worth the few minutes that it takes to read through each chapter.

It’s almost funny that I read the book in only a couple of hours (it’s under 100 pages) and I’ve spent the last day reading an installation document that tells me how to get ready to setup some software. Based on the first law and the tenth law, I think about 80% to 90% of my time could have been spared.

On the project that I'm working on, we are currently tracking our sprints with index cards (on a wall gantt) and by daily/sprint/release burndowns in a spreadsheet. The wall gantt is the tracking that is used for our day-to-day tasks and the spreadsheet is used more as a communication tool for our external stakeholders.

Our team has recently run across some issues with a few third-party software packages that have impacted our velocity and required some additional tasks. As part of the on-site team, my visibility has mostly been with the wall gantt. I've noticed that our velocity has taken a hit, but I wasn't sure how our velocity had trended over the release as a whole.

I recently ran across sparklines and was interested in using them to take a look at our velocity. I was extremely impressed by how much information could be viewed in a short space.

It's fairly obvious where the trashing started (around sprint 10). The sparkline shows a daily story-point burndown inside of each sprint. The high and low points of work remaining for each sprint are shown through the different colors. For the spreadsheet, I used the free Bissantz tool (thanks guys).

I'm looking forward to picking up Beautiful Evidence by Edward Tufte and reading about more visualization patterns. Reading his work is always extremely insightful.

YAGNI as a development concept is a very powerful idea. The idea of making a decision at the last responsible moment saves money, effort, rework, and will often save sanity. The idea is very simple and bascially revolves around removing speculation. When we constantly think in terms of YAGNI, we are often mitigating one of the largest risks to software projects.

In my experience, extensibility is usually the largest risks to a software project because it often results in the largest degree of over-engineering. This usually isn't a popular idea, but I think it's true. There are times when it's warranted and valuable, but the problem is that we tend to always think that it's valuable. We always say things like: "what if", "someday", "it's possible that", "I can imagine a scenario", and so on. These are usually things that should be considered, but not always things that should be developed. In theory, we need to pose these questions to our stakeholders and our stakeholders should be making these decisions (not the development team).

The problem with the theory (allowing the business team to make the decisions) is that they are often caught up in the same vicious cycle of over-engineering our specifications. When I'm handed a large requirements specification document, I know that 25% of it is outdated, 40% of it will never be implemented, and that the real value likely comes from 20% of the requirements. The state of the specification is a result of over-engineering by the stakeholders (and it compounds the issue of over-engineering by the development team).

I don't have a silver bullet to fix the issue, but I believe that we can at least identify the problem and get in the correct mindset of fixing the problem by thinking about how to eliminate waste. Simply considering known value vs. speculative value can go a long way. We should always be thinking about doing less. Less is a powerful idea because of the compounding growth of each additional thing that we choose to do. For every "I can imagine" scenario, we have business costs, development costs, testing costs, and maintenance costs. We also have other costs that we usually don't think about including opportunity costs.

To push the idea further, we should consider the idea of "less" across the spectrum of our activities. One big opportunity comes with documentation. I think that The Elements of Style should be required reading for everyone that contributes to documentation on a project. Our documentation should be concise and avoid all the additional "fluff" that makes up the majority of the large documents that I see on typical projects. Documents should be focused to the point that every word in the document has meaning just as every requirement should be valuable and every bit of software should be testable.

Unfortunately, the idea of more is the norm. The positive side is that we are the problem and we can all take steps to eliminate waste in our day-to-day activities. If we don't do anything else, we should at least consider how the idea of "less" can apply to our projects and our organizations. It's not an overnight change, but it is a valuable exercise in thinking about what really matters.

I've been using Backpack extensively throughout the past couple of months and I've been very impressed with the simplicity and effectiveness of the service. One of the first things that immediately stood out was the effective use of blank space at the right times.

For instance, when I create a new page I have instructions that appear to help guide me through the process…

This is a very simple, but very effective idea that drastically increases usability

The Signal vs. Noise blog has a post about this here. I wonder if it was backpack that they were talking about in the post?

A while back, I was looking for an answer to a Javascript question and I ended up finding the answer in this Javascript reference. More important than finding the answer to my question, I was intrigued by how clear the reference was with minimal text and the fact that the reference was put together as a list of assertions. It came down to the code being self-documenting and being very easy to understand.

Ever since I saw the Visibone references (all of which are very good), I have tried to learn new languages taking a test-driven approach to learning the legend. Usually, the first thing I learn about is a test runner that I can use for the language and then I play with the language by using the test runner and creating a bunch of tests. Everything is self-documenting and I can go back and tweak examples when I want to expand on my knowledge or find out how certain scenarios work. Best of all, I have a record of my learning and when I switch versions of the language or library, I can simply run my tests to see if anything I know has changed since the last time I used the language or library.

I recently started playing with the prototype library, and this approach has been a great asset. I can learn a little at a time and review my progress at any time. The prototype library is a Javascript library and I started out by using the script.aculo.us unit testing library (which is built on top of prototype).

My approach was to create a new .Net website, create a master page with all of the javascript references, and then adding new content placeholders for each logical area that I'm learning about.

My test page looks like this…

…and the tests look something like this…

This has been a great way to learn prototype and I think I'm probably going to do this more and more moving forward. Just about every language seems to have a unit testing framework and I like the idea of having code that I can go back and execute.

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.

If you haven’t seen this post, go read it. I love it.