work archive at The Sherpa Project

Archive for the 'work' Category

Dec

Wisdom from The Tao Of Programming

By admin 0 Comments

Categories: teams and work

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?’”

“It will take one year,’” said the master promptly.

“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”

The master programmer frowned. “In that case, it will take two years.”

“And what if I assign a hundred programmers to it?”

The master programmer shrugged. “Then the design will never be completed,” he said.

So true.

Stay small.

Nov

Announcing: Big Visible Cruise

By admin 6 Comments

Categories: agile, community, continuousintegration, opensource, simplicity, software, teams, travel and work

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.

Oct

Vista Ultimate - The One Month Meltdown

By admin 0 Comments

Categories: work

I’ve been using Vista for over a year now and I’ve been very happy with it overall. I’ve primarily used Business Edition, but I switched about a month ago to Ultimate Edition. The graph below shows my stability report over a one month period (higher is better)…

Vista Ultimate

Today I re-installed Business Edition. Maybe now I can get a little work done.

Oct

Remote Pairing

By admin 0 Comments

Categories: agile, devtools and work

I’ve been spending roughly 4 - 8 hours a day doing remote pair-programming lately. Although there are always connectivity issues (usually once or twice per day), it’s still only a minor nuisance. Overall, I’m really enjoying the experience and it’s starting to feel pretty close to side-by-side pairing.

The tools that I use on a daily basis include Microsoft SharedView for screen sharing and Skype for voice and video. The combination of these two tools seems to work very well (even over wireless).

SharedView is still in beta, but it is a very nice, minimal, and responsive tool. With the exception of the ads (integrated into the tool), I’m impressed. I’ve used many other tools in the past but this one just seems to fit the way I work better. The features like the ability to see other mouse pointers, clicking, and highlighting is a very nice feature.

Right now, the only thing that consistently bugs me is the quality of my headset (junk). I’m hoping to pick up a new one in the next couple of days.

Sep

Learning From Bruce Lee - Simplicity

By admin 1 Comment

Categories: simplicity and work

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?

Sep

Inspiration: Q-Drum

By admin 0 Comments

Categories: business, design, work and world

Sometimes, it’s good to unlearn.

Think backwards, throw out your preconceived notions, forget about dependencies, and ignore your constraints.

If you search long enough, you just might find the right problem to fix. When you focus on the right problem, you might actually surprise yourself with what you can come up with.

Q-Drum solved the right problem.

The real problem…

A novel solution…

Sep

Minimizing Notes

By admin 1 Comment

Categories: work

For a long time I was a note-taking freak. I’ve probably used every type of note-taking technique and application out there at one point or another. I’ve relied extensively on Notepad, OneNote, DarkRoom, e, WriteBoard, stacks of Moleskines, every kind of PDA (including the hipster), TidlyWiki, MindManager, and a ton of others that I won’t mention.

One day, I realized that I spend a whole lot of time taking notes and very little time reviewing or referencing them. Based on this realization, I decided to experiment with not taking notes at all. This worked out much better than I ever thought it would. No paper, no laptop, no distractions. So far, it’s been a great experience.
I’ve realized that there are some situations where writing things down or drawing visuals helps me digest things easier. In these cases, I’ve narrowed everything down two different techniques that I use consistently. Here’s what I’ve come up with…

Hipster Note Taking

This is my favorite technique. I usually take out a couple of 3×5 index cards and use one for drawing a mini-mindmap and keep the other one handy for any action items that I take out of the meeting. There are many times that my cards stay blank. When I leave a meeting with mini-mindmap, I take the card and spend some time thinking back through the concepts. After I mentally review the concepts, I tear up the card.

MindManager Note Taking

This is my electronic version of the technique above. I use MindManager to collect my notes. After the meeting, I review the mindmap, reorganize it, think about the concepts, and delete the entire mindmap.

As I’m processing the information from the above techniques, I drop the relevant information into one “master mindmap” that I use to collect the things that I know that I’ll need to remember. After about six months, I only have a handful of things on my “master mindmap.”
So far, this is working well. I feel like I can devote more time focusing in the meetings and thinking about the topics. It feels good to be note-free.

Aug

Be Careful With Your Numbers

By admin 3 Comments

Categories: agile, business and work

A couple of years ago I put together some collateral to use when “selling” agile to potential clients. As part of the effort to educate our sales team about agile methods I wanted to provide some strong evidence for our sales team to use.

The only numbers that I had seen at this point were the numbers cited in Agile and Iterative Development: A Manager’s Guide by Craig Larman. To say the least, the numbers were very impressive: Of those polled, 93% saw increases in productivity, 88% increases in quality, 83% improved stakeholder satisfaction, 49% reduced costs, and so on. I dropped these numbers in the collateral and I made every one of the sales members happy.

A few months later I was looking for some deeper numbers and I started to dig deeper for more quantitative data. The first place that I went to look for numbers was the study used that came up with the above numbers (by Shine Technologies in 2003).

When I started digging deeper, I realized that this survey has huge room for error. I’m not an expert on surveys or quantitative methods, but what I read didn’t leave me feeling convinced that it was worth publishing and standing behind the results.

After digging a little deeper, I noticed that these numbers (that I had been advocating) were based on a web-based survey that had only been taken by 131 people. Yes, 131 people and web-based. Ouch.

You can find the survey here.

Now, I don’t want to completely discount the survey and/or the results. This is important information; but I’m just not comfortable presenting these findings as “evidence” that agile works. I’m just not comfortable putting them up on my company website and I’m not comfortable putting them in my presentations. I believe in agile methods, I just don’t believe that this study “proves” that they are a valid alternative.

An interesting thing that I have noticed is that many individuals and many companies have used this survey as justification for agile initiatives. Last week (at Agile 2007) I saw these numbers presented multiple times in slide decks and I’ve seen them on plenty of web sites of vendors that are offering agile services.

Anyway, I just thought that this was an interesting bit to share about how you should always know more about the survey results and numbers that you use to backup any claims. Make sure you can stand behind your numbers and that you find out the information behind the numbers.

Aug

Agile 2007 - Parting Thoughts

By admin 1 Comment

Categories: agile, events, learning and work

Overall, Agile 2007 was a wonderful experience. I really enjoyed my time at the conference and attended some really good sessions (and a few that were really bad as well). This was my first conference and I’ll be back for sure next year.

My favorite sessions included:

(Follow the links for the abstracts, presentations, and handouts)

Agile Enterprise Rollout–The Greening of the Software Industry (Jean Tabaka, Ryan Martens)
The Role of Leadership in Software Development (Mary Poppendieck)
Learning Kaizen from Toyota [with MindMaps] (Mary Poppendieck, Kenji Hiranabe)
I Don’t Like Mondays - Improving Agile Team Collaboration Events (Jean Tabaka)
Reaching New Heights: Learning to Adapt is Essential (Susan Ershler)
Agile adoption at Google: Potential and challenges of a true bottom-up organization (Mark Striebeck)
The Agile Enterprise: Real World Experience in Creating Agile Companies (Jeff Sutherland)

Some of the big-picture realizations that I came to:

Mary Poppendieck has turned into the Tom Peters of the software industry (well-deserved).
Lean thinking has started to move to the center of the agile universe (finally).
Executable specification / story-driven development is moving to the mainstream (finally).
Everyone wants to scale agile.
Everyone wants to distribute agile.

A few things that I’m concerned about:

Lean has moved to buzzword status. A lot of people are talking about Lean but I don’t think the majority understand the essence behind it. I think this will get better.
Everyone wants to make “Enterprisey” software with agile teams.
There are a lot of “agile” consulting firms that are full of shit.

And some other random thoughts…

I think the fact that everyone is focused on “scaling” agility to large teams and distributed projects and that there will be a lot of agile disasters over the next couple of years. Now that the bigger software companies are moving to agile, the teams are getting too big and they are adopting agile in scary ways (too big, too fast). I think that you need to evolve to big teams, not start out there. I would also (passionately) argue that you should focus on how to have smaller software instead of how to scale agile teams to accommodate large software. I seem to be in the minority.

Lastly, I really think that the organizers of the conference need to step it up. The programs sucked (hard to read, hard to navigate, mis-prints, missing pages, etc.), the event was really hard to follow (talk duration, locations, topics), the location of the conference sucked (tight hallways, hard-to-find rooms, etc.), and the beverages and food was awful (a big thank you goes to Rally for providing everyone with bottled water).

I certainly appreciate that everyone worked hard to put this together, but I expect the basics to be nailed for a major conference.

Aug