Tag Archives: Agile 2008

Working Together… with Techology

If you want to build a ship, don’t drum up people together to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

-Antoine Jean-Baptiste Marie Roger de Saint Exupéry

Where to start with this one? and where to finish? The only thing I will really promise is meandering, but I think this is interesting, if not well formed…

The first thing you need is a little context about what is driving my thoughts on this:

  • I’m an XP fanboy. Even if the XP community is manifesting paranoid schizophrenic at this point (more on this in a future post), once you have experienced pairing and have a break through where things start to flow, you can never go back. Everyone working in isolation becomes really painful and is frankly less efficient IMHO, especially over the life of a project.
  • I haven’t found a way to effectively pair working on Puppet‘s core. Mainly because of the ~1000 miles in between myself and Luke. We talk on the phone, open the same files and goto line numbers or sometimes we try sharing the screen. This certainly helps with knowledge transfer, but feels clumsy and never gets the flow that you need to crank out solutions together

So how can a distributed team work together?

I’d been reflecting on a development tool called UNA, one of my personal highlights from Agile 2008, when I saw the Devunity presentation from TechCrunch 50 which set out to provide a similar environment. These types of tools facilitate possibilities for working together that I will try to illuminate, and then I’ll throw in my 2 cents plus interest.

I volunteered to participate in a ‘Coding with the Stars Competition’. This was envisioned as a sort of geek fest Agile development engineering version of ‘Dancing with the Stars’. I was paired with John De Goes. We were the first team eliminated. I admit I was disappointed just a bit, not because we were eliminated, as much as that we didn’t do a good job of portraying the power of what Una enables. In order to be true to the show, the judging was capricious, but at least I’m not bitter about that… :/ (In all seriousness, the whole thing was just for fun and while Una is a great tool when the network isn’t feeble, the collaboration Una enables probably isn’t best demonstrated in 4 minutes of software development ‘theater’ without a lot of setup and backstory.)

Resistance is Futile...

Resistance is Futile...

John is obviously intelligent and intense, which means I automatically like him. Marketing admittedly might not be his strong point (I do appreciate the Gigeresque imagery, though I’m not sure the proverbial ‘everyone else’ can.), but he’s put a lot of time and thought into building software and how people can do it better. Una is the result and when you see John talk about Una, this is obviously a labor of love.

Ok, so what does Una enable? I’m not totally sure, but I know that watching John use it and what I learned using Una for two hours was compelling enough that I’m still thinking about the experience six weeks later.

Una is for all intents a text editor bordering on IDE with a networking component that lets multiple people work on the same files at the same time. I have my cursor, you have yours and when the network packets are flowing, we can see each others work in real time. This is different from sharing a screen, because we can all control what we see and do independently. Whenever anyone saves a file UNA runs the tests and everyone knows how long ago the tests were run because there is a timer which resets after each run.

I admit that this seemed a bit disconcerting in the beginning, but after a couple hours of working together with John, some really interesting things started to happen. We started working ‘together’…

How many times have you watched someone type and witnessed a typo? Usually, you point something like that out and the person will go back and fix it. No big deal, right? 5 seconds of ‘hey’, ‘right there’ and it’s fixed. But what if you could just fix it? And while he (or she) could see you fix it, the break in concentration goes from 5 seconds to maybe one. After about the first hour of working together, this type of thing started happening, spontaneously and organically. The cadence of test driven pairing potentially changes from syncopated keyboard switches to an almost surreal flow. The communication really started to go ‘into the code’ and the oral cues became less and less necessary (this probably wasn’t the best thing for the ‘competition’, que sera, sera)

And this was only after an hour of working with a tool I’d never seen before and a person I’d never met! Imagine what might happen after working this way all the time with a talented team… Honestly, I’m not really sure, but based on what I saw from the TC50 presentation Devunity also sees some of the same potential.

This is where my two cents starts, but first I need to introduce a few more ideas (I did promise ‘meandering’). I really really really like data, and I especially like figuring out interesting ways to take lots of data from different places and present it in a way that facilitates understanding.

For he today that sheds his blood with me shall be my brother...

'For he today that sheds his blood with me shall be my brother... ' --Big Will

At some point in the past, I also enjoyed playing multi-player real time strategy games. My favorite games enable epic battles with all manner of complexity in the viable strategies (ok, and an occasional zerg rush). A critical skill one develops playing these types of games is keeping an eye on the mini map. Players develop an intuitive notion of critical places on the map. Just one pixel of certain colors anywhere might warrant investigation, but flashes of color in certain places require immediate attention or the game is lost. The mini-map also let’s you know what your allies are doing, where they might be winning or losing, and is critical for any sophisticated coordination.

In parallel, people have put a lot of energy into tools that let you analyze the quality of code, particularly Object Oriented code.

What if we had a tool that took an OO code base, generated a view of it in a ‘mini-map’, maybe several views, like the class hierarchy, the dependency/call graphs, and the file layout, then using color we super impose more data, like cyclomatic complexity and test coverage. (I know some Java IDEs are pretty close to being able to do this)

Now what if we can update this mini-map data in real time and use it as feedback in an environment like UNA?

We know the critical pieces of the code, and have a sense of the aesthetics and metaphors that code embodies. What if we not only get feedback when we run our tests, but we see green and red cascade across the mini map in the places other team members are working? Or we can see cyclomatic complexity increase? Or new untested code… (Too bad you can’t fix problems like that by pushing ‘A’ and clicking the mini-map to direct a screen full of your hydralisks… *shrug*)

The team will start to intuitively know ‘what’ colors ‘where’ warrant investigation, or perhaps even immediate action. The battle unfolds transparently and with a clear sense of where the team might be winning or losing.

Take it a step farther, what if instead of version control being based on file sets, the whole ‘battle’ is recorded, keystroke for keystroke. Not only can any point be recovered, but that is some serious data about how everyone works. I’m not even sure where that would lead. I do know that new information enables optimization, both specific and systemic improvements. Tactics and strategies can’t help but evolve. (hopefully not draconian notions of productivity…)

While we’re at it, let’s put VOIP channels in this thing and facilitate/record dialog, too.

I can’t think of a single human endeavor that doesn’t benefit from observation, analysis and reflection. The code review process would go from looking at the static result to watching the journey. Root cause analysis potentially reveals more about ‘how’ and ‘why’, instead of just groping at ‘what’. What could this feedback reveal about how we work, and how we work together? As I stated in the beginning, I don’t know… but it sounds pretty cool, no?

I not sure where the line is between enabling productivity and gratuitous indulgence, but the technology is all there, it’s just a matter of hooking the right things together in interesting ways.

I’m certainly not going to build anything like this anytime soon, but if someone reading this does, and you happen to make a whole lot of money revolutionizing collaborative software development, just promise to buy me one nice dinner, and you probably owe John one too, unless you are John, in which case run with it. (I’m partial to sushi, but I’m open to other options. If you devote your life to building this and lose everything, I’ll buy you dinner. Omakase Onegaishimasu)

Miles Per Gallon

In truth, a good case could be made that if your knowledge is meagre and unsatisfactory, the last thing in the world you should do is make measurements; the chance is negligible that you will measure the right things accidentally.

George Miller

Last week I drove to Los Angeles with my wife, two kids, my mother-in-law and her sister in our not so eco-friendly SUV. Hilarity ensued, but that’s not the point of this post.

I don’t usually drive this car. Until recently, most everything in my life was in about a 5 mile radius, work, play, whatever. The SUV is ‘her’ car; my wife drives it to where she does research and home most everyday.  Occasionally, we all get in and go somewhere exciting, like grandma’s.

You are starting to wonder what is the point, and I’m hoping I’m about to make some.

This late model SUV has a speedometer, a tachometer, and in addition has a computer that is estimating instantaneous MPG and average MPG since the last fillup, since the beginning of the trip, since the epoch, etc.

On the way to LA, with this SUV stuffed full of people and random stuff, I averaged just over 20 MPG at ~80 MPH. On the way back, I averaged 25.6 MPG with the same people and even more stuff and nearly identical MPH.

On the way there, I kept watching the gauges and thinking ‘these rolling hills are killing my gas mileage’. On the way back, I was optimizing the speed and acceleration patterns, only dipping below 20 MPG on the steepest inclines.

If one rides a bike on hills, he or she figures this out pretty fast. There are certain speeds you can hit a hill that can be maintained with less effort than it will take to go slower, all this is based on fitness, the equipment and the hill. Also, acceleration uphill is fairly expensive. Your body figures this stuff out because energy expenditure and efficiency have consequences, and the feedback is rapid.

In an automobile, I doubt I ever would have figured it out without the gadgetry.

You can’t manage what you can’t measure.

What does this have to do with software? Velocity is a commonly used idiom in project planning. I’ve seen velocity measured different ways in practice, and seen it’s measurement discussed in many more.

But I’ve never really seen efficiency measured with relation to velocity. The only time efficiency is considered is with respect to getting more velocity.

I’ve never seen anyone in a planning meeting ask, how can we maintain this velocity more efficiently? Is this velocity the most efficient? Over the life of any decent sized project, this seems like it would be important.

(Aside: The XPers might, as they have a notion of sustainable pace, but I’ve never been in a pure XP setting. I’m starting to think they only exist in legends or they are like the Jedi scattered by the clone wars trying to cultivate the force in swamps and deserts… I’ll be at Agile 2008 this week, so I’m hoping to come home with some new Jedi minds tricks.)

How many miles per gallon are you getting? Are you losing MPG to the rolling hills?

Perhaps the more important question, how would you know? What do you measure? (The instantaneous estimate feedback was key for me, hmm…)

Keepin’ On

Been keeping busy, just checking in. . .

The conferences in SF (Velocity, Cloudcamp, Structure) were a great time to learn, to teach, and make friends. Puppet got a lot of love, but we still have a much grander view of the potential for the project. Puppet is still basically an awesome working prototype, the next year should see improved performance, clean and clear points for integration and a lot more reporting.

Luke showed a video of a GUI reporting application that aggregates and helps visualize Puppet’s reporting. We had a an email the next morning from a Fortune 500 company about getting into the closed beta. Looks like another large internet property is also going to be in.

This last week, I did a tiny bit of development for the 0.24.5 release and finally restyled reductivelabs.com to be a bit cleaner. I also worked on some slides about Reductive Labs for OATV StartupCamp and threw around some ideas for an Ignite talk for Foo Camp, which are both next week.

I was thinking about ‘What Would Machiavelli Do?’ because Niccolo always gets a bad wrap, but now I’m leaning towards ‘Business Advice From Western Philosophers’. (I’d still throw in some Machiavelli.) I’m going to struggle to boil things down to 20 slides but I think I can make an engaging talk. (I could probably spin at least half a dozen fun talks out with all the different philosophical schools, probably starting with ‘Existentialists‘. And then there is always the Taoists or the Sufis. . .) Feel free to make suggestions in the comments.

StartupCamp and FOOCamp are another great opportunity to get out and spread the Puppet word, but also to learn from a lot of smart people who are doing interesting things. I’m sure my mind will be buzzing this time next week, and some of that is bound to generate some interesting posts. Right?

I also am going to be at Agile 2008, and on that note, some really nice thoughts about software development and infrastructure are starting to crystallize, stay tuned. . . I promise something meaty before StartupCamp starts on the 10th.

%d bloggers like this: