2Paths Team Blog

In April, 2008, I attended the “No Fluff, Just Stuff” in the guise of the North West Software Symposium, in Seattle, Washington, USA. For those not in the know, the NFJS series is aimed at tech savvy developers interested in expanding their knowledge and exposure to interesting developments in the land of Agile/Java (predominantly). With another symposium coming up in September, I thought I would pen some thoughts from my attendance of the April event to encourage others who may be interested in attending this series.

The welcome from Scott Davis was a fun introduction to the spirit of the conference. His jovial nature and passion for all things agile and groovy was instantly infectious and a great ice breaker to the weekend.

Here is my take on some of the sessions I was fortunate enough to attend.

groovy is groovy, yeah
Scott Davis, being a very groovy evangelist, sparked my interest in this not so new, yet very groovy dynamic language which is really Java by another name. The underlying take away from his Blue Pill talk was that Groovy can be useful even for those who do not totally drink the coolaid of hoopy dynamic possibilities afforded by all the runtime hackery allowed via groovy. The terse syntax and ability to obviate the need for boiler plate code in tests and domain models was very appealing.

Subversive agility and Test Driven Design
Neil Ford gave a rousing keynote which outlined his philosophy on agile and how to ensure naysayers are converted to the way of agile. In essence, if you can’t use subversion, use subversion!

Neil also gave an interesting talk on test driven design. This was intentionally not about test driven development as he focussed on the different way of thinking which is engendered by adhered to a test driven approach. As developers we often get caught up in following the path well worn which can be limiting when it comes to solving problems. By adopting a test driven approach, one’s ability to think different (to steal Steves bad english) is developed as we start thinking of solutions in a top down, loosely coupled approach which definitely helps design.

Metrics are bad mmm … Kay
Neil also gave an interesting talk on metrics. He covered many things including burndown accuracy, code coverage and performance. Whilst many people get caught up in the game of numbers he made a very good point - that its the trending of metrics that are more important than the absolute numbers. As a project progresses, it is more important to have improving metrics (code coverage, and better accuracy of burndown estimates) than it is to have good numbers. He also made a bold statement in saying that code coverage should always strive to 100% - one does not want to have code going into production if it has NEVER been executed in your test environment. A very poignant point indeed.

Business driven development
Venkat Subramaniam gave a number of talks on agility and dynamic languages (groovy once again). He is a very interesting speaker with a dry wit and sharp mind. It was quite entertaining listening to him speak. One of his talks was on business driven design and he outlined a number of techniques for rapid prototyping of tests and business requirements using FIT and BDD. It was a great introduction to some very customer focused ways of developing agile solutions.

In all I found the conference extremely enjoyable and very enlightening. Most of all it was great to get to interact with other dev-heads and to hear form some talented folks out there. It was very heart warming to see that in most of the straw polls on agile methodology usage and implementation, the 2Pathians were able to raise their hands and say “we do that” whilst many others were left in the “we want to be able to do that but …..” camp.

I would highly recommend the NFJS series to other folks out there.

Scott, Ted, Venkat, Neil Ford

Good to see we are using lots of tech that is interesting - need to add groovy to it

Well, this is officially my first blog ever! It feels a bit weird putting my thoughts out there for all to see.
Anyhow, gotta get with the wave of the future, or present, or whatever…

So, having just started working at 2Paths in July, I was pretty excited when I heard we were going to have a summer team event. When I listened to everyone’s ideas for a perfect team activity, I started to get a little worried that I wouldn’t be able to keep up. Things like hang-gliding, white-water rafting, rock climbing and mountain biking were suggested. Now these activities might seem average to you, but you have to understand that we have a pretty active team of people here at 2Paths who just love to be outdoors and on the go. We aren’t talking a bunch of beginner enthusiasts going out for a day of fun; instead we have a health mix of beginners, pros and those who will do just about anything.

Initially the plan was to head up to Squamish for a half day of rock climbing up a real mountain, however, despite weeks of sunny weather, we were in for rain on our planned event day. And the following day ended up being the day of the huge rock slide on the Sea to Sky highway which closed the highway for several days. So, being the flexible, easy-going group that we are (really?), we decided to head indoors to the Edge climbing centre in North Vancouver. After some initial confusion and delays, we were all outfitted to go climbing.

Now, I have never climbed indoors or outdoors, so I had no idea what to expect. A couple of days earlier, I’d learned that the word “belay” meant having someone hold your rope as you climb up and I’d also heard about “auto-belaying” which we were supposed to do. After watching a few people head up the wall (including a very talented 8 or 9 year old next to me), I gave it a go. I have to say it was actually easier than I expected provided I used my whole body and stayed close to the wall. Jumping down got to be fun on the auto-balays after a couple of tries. The team broke off into smaller groups with some of the more experienced climbers belaying for others. Some of the team also decided to go without any equipment on the steeper cliff faces using just their strength and some soft mattresses below. It was a pretty relaxed, quiet team event but we all got a chance to chill out away from work, and while we were only there a few hours, it seemed like we’d been there all day. Time actually slowed down for a while. Amazing!

Once we’d all headed up the walls a number of times and got our fill of climbing and sore arms, some of the team headed back to the office and the rest of us headed to the nearby Pemberton Pub for some cool beer and appies. For me, this part of the day was the best as I really got a chance to hang out and get to know the people on our team better. Plus the beer and food was pretty good too!

I’m not sure exactly what we’ll be doing for our next team event but I do hope that the planning goes smoothly and that the weather works for us and that we have more opportunity to do something ‘active’ as well as time to hang out and socialize. I’m in for anything provided there is a beginner version, except for maybe hang-gliding.

Continuous integration is a lovely thing. Automated testing is also lovely as you can see where things work or not almost instantly in different environments and scenarios.

Over the years I have used a few CI servers and tools - most notably, CruiseControl (Java and .NET) and Continuum (from the Maven crew). These systems, whilst useful, cam e with a few annoyances, most notably their slight fiddliness in getting up and running. Whislt they worked, it seemed that there were always tweaks required here and there to get things running smoothly and when things went wrong they we not that easy to correct.

After chatting with a few friends, I thought I would give Hudson a try as it seems like a new contender for CI server of the month. Spurned on by glowing feedback from said friends I though I would see how easy it would be to try and aggregate our disparate CI servers (For Java and .NET) into a single hudson installation - something advertised to be easy on the tin.

Here are the steps I followed:
- download WAR, runit
- config master/slave
- config maven app
- config .NET app
- force some builds
- too easy

A simple distributed build system that works cross platform sounded too good to be true, however it seems that hudson is well on the way to being just that. I couldn’t believe how easy it was to get a distributed build/CI system up and running and building/testing our Java and .NET apps with all reports and config managed centrally. I especially like the simple reports on build trends and the weather paradigm used for displaying build stability.

After this simple proof of concept, we moved the setup to a cluster of VMWare instances (Linux and windows) so we can now build multi-platform apps and manage things centrally for all projects. This is now our main CI platform and seems to be working well.

Hurray for progress!

With forecasts of April snow, our 2Paths contingent of two headed off at the crack of dawn one Friday for Bellevue, WA to attend the No Fluff Just Stuff - Pacific Northwest Software Symposium (NFJS). Having only spent 10 minutes at the border (whew!), we arrived early enough in the Seattle area to fit in some Fluff (aka shopping and dining) before getting into the Stuff.

After a quick introduction by Evangelist Scott Davis, and with hopes of winning an IPhone by the end of the weekend, I headed right into his double-bill of sessions about Groovy. The first one entitled “Groovy, the Blue Pill: Writing Next Generation Java Code in Groovy” was a good gentle introduction to neophytes like myself on Groovy basics. Now that my interest was piqued, I was eager to continue on with Scott’s next session “Groovy, The Red Pill: Metaprogramming, the Groovy Way to Blow a Buttoned-Down Java Developer’s Mind”. Never mind the Blue Pill - the Red Pill is where it’s at!

Scott’s enthusiasm for Groovy was definitely contagious, and my mind started churning, trying to think of ways to start introducing Groovy into current projects or future projects at 2Paths. An allure of Groovy is that it’s a dynamic language and can be run on the JVM. Groovy is implemented in Java, so the two languages offer seamless interoperability. Groovy compiles down to Java bytecode, so Groovy code can call Java code, and vice-versa. This would make integration into our existing infrastructure much simpler.

The Blue Pill was starting to take effect, as Scott showed us the terseness of the language. No need to labouriously write getters and setters, amongst other many nifty language shortcuts. Who needs semicolons or parentheses anymore? Because Groovy really is Java under the hood, programmers unwilling to let go of that extra baggage can continue to use it and nothing will break. We were then shown demos on how much more quickly we could bang out Unit Tests in Groovy.

In the next session, the Red Pill stuff was pretty mind-blowing. Introducing method pointers, closures, the ExpandoMetaClass. Method pointers make our code more readable and understandable by allowing us to alias methods with semantics tailored to our own business logic. Closures are an exciting and powerful inclusion in Groovy that aren’t available in Java, allowing us to pass around executable snippets of code. And last but certainly not least, there’s the ExpandoMetaClass that lets us either do a lot of really cool stuff, or get ourselves into a heap of trouble. With the ExpandoMetaClass we can intercept methods and inject methods into any Class. Scott showed us some fun examples that got us all fired up wanting to try more!

With my introduction to Groovy setting the stage for the weekend, I went on to choose more sessions on Groovy (Design Patterns, Testing, Groovy with Spring), but also attended other sessions such as Spring Configuration, Regular Expressions, and GIS for Web Developers. I found most of the other sessions mostly affirming knowledge I already had, but augmenting it with good snippets here and there that were new to me. Venkat Subramaniam was the other main Groovy Prophet, and I came home with his book “Programming Groovy” in hand, eager to start integrating Groovy at least into our testing infrastructure.

The atmosphere at NFJS was inspiring, as the speakers all had great enthusiasm for the technologies they were touting, and the audience was generally equally as keen. It felt great to be in a large conference hall amongst so many other like-minded programmers, all sharing, and getting fired up about what we do, and our seemingly unlimited potential. I fully recommend NFJS (regardless of me not winning an IPhone), and would love the opportunity to go again!

One of our recent projects has a .NET backend (with a JavaScript frontend). As we use macs for our dev platform, this means dual booting or using parallels in order to fire up Visual Studio to work on and debug the backend using the embedded ASP.NET server … until now.

The other day, out of curiosity, I downloaded Mono for Mac OSX to see how it works and if it would be at all viable to use as a development tool for .NET projects. With the installation came a Mac version of the MonoDevelop IDE which supports Visual Studio 2005 solution and project file support. I thought it sounded too good to be true but decided to give it the five minute test to see what might happen. I did a fresh checkout of the codebase, fired up MonoDevelop, opened the projects solution file and unsurprisingly some things did not function. For one, we use an add-in for Web Deployment Projects which wasn’t recognized. Additionally there seemed to be some build issues when trying to locate our logging DLL. With a bit of poking (literally a few minutes) I had found that all we needed was a hint in the project file to point to our DLL and the project built - very scary. Next thing was seeing if it would run.

As it turns out, Mono comes with an ASP.NET server called xsp2. Even more interestingly, editing the properties of the web Cleint project in MonoDevelop reveals very simple integration with xsp2 as an embedded server. This was all looking too good to be true. A simple config change (ports) and then I hit run for the client project and was amazed that the thing actually came to life and seemed functional. Very shocked was I!

There was a minor problem in that our configuration service was reading files and serving them to the client but had issues with line endings given the difference between windows and mac platforms and their ideas of what a line ending should be (for the record its \n!). That was swiftly fixed and the app not only came to life but was fully functional.

Admittedly, MonoDevelop is a pretty rough IDE but the fact that it took less than 30 minutes and not much tweaking to get things working was quite a lovely surprise!

We try to get out of the office every month or so for a bit of R&R - kayaking, climbing, boarding. Geoff put this video together:

nice production work Geoff!

“Are we a CMMI certified company?”

I was speaking with a business associate the other day. We were learning a bit about each other’s companies and he asked me this question. I answered as well as I could, trying to balance the art of diplomacy with frankness. I confessed that we were not, and that while there are many good things about the Software Engineering Institute (SEI) and its processes, we are a rather different software company than those that benefit from their Capability Maturity Model Integration.

“CMMI prescribes an intense process, and requires a lot of documentation in order to guarantee quality, repeatability and ongoing improvements, while we are an agile shop that is focussed on delivering high quality software with a well-defined but very lightweight process,” I told him. “CMMI is geared toward keeping a symphony-orchestra-like software company on track. There are a lot of players and the organization needs to move seamlessly forward when new players are switched in. We are more like a jazz ensemble: our extraordinary achievements are accomplished by recognizing the star power of the individuals in our team, and we are oriented toward freeing and empowering them.” I went on to describe a bit about the agile methodology, and how both the SEI and agile thought leaders are attacking the problem of managing software development from different directions. We are very interested in the quality of our software, and are constantly revising our processes to that end — its just that our context and techniques are different from CMMI.

After our meeting, as is often the case after I have charged forth with an off-the-cuff speech, I reflected on whether what I had asserted was really true. Are my previously held opinions of CMMI actually valid? I did a search on agile and CMMI and a few interesting articles dropped out. There are not a lot of good hits, and those that I viewed all validated the apparent antipathy with phrases similar to: Agile and CMMI: Oil and Water? It does seem that the community concedes that Agile and CMMI appear to be at odds. However, it seems that there may have been a spark of interest in reconciling the two methodologies a couple years ago. And although there are less hits discussing the topic more recently, it appears that agile thought leaders are participating in defining the next version of CMMI, and I will certainly review version 2.0 when it appears.

I’ll just pass on one article, which is provocative and well-written:
http://www.agilemanagement.net/Articles/Papers/StretchingAgiletoFitCMMIL.html
This article justly received a healthy distribution, so you will also find it on other sites. It describes David J. Anderson’s 2005 experience in designing an agile process for Microsoft’s Solutions Framework that was CMMI Level 3 compliant. The article is remarkable in providing details on the theoretical compatibility of CMMI and agile methodologies, drawing on the thinking of W. Edwards Deming, as well as describing how the principles were put into practice for Anderson’s MSF method.

While 2Paths is not currently in a position to begin the process of becoming CMMI compliant, there is much food for thought in Anderson’s article, and I expect that some of our upcoming process improvements will benefit from our studying it.

In this case, I learned a lot from attempting to speechify on a topic I was not fully abreast of!

It happened again, I got tangled in the eddy of the winding years

Just a moment ago, I stood in a thicket of pale green buds, yearning up toward the waxing light
There was no horizon there, just branches hung with sparkling drips, the first spring warmth, a gentle gurgle from the melted snow

I was down on haunches to take in a bright uncoiling fern
Delicate slow motion gesture
Every frond outstretched, exquisite grace
Each formed of tiny fractal copies of itself, and each alive

With the subterranean throb of waking life,
I slowly breathed the rising sun-warmed funk of last years mulch
Lost until I reeled and swooned toward the the tiny spiral there

With a microscopic crackle and electric hum
The frond unfurled with a creeping pace
I saw it grow!

—<0>—

Jarred awake, I stood and marked the passing time
Set off at once with determined steps toward the falling sun
Now the world was drowsy hot
Tawny golden wheat shimmered in the heated air, stirred with undulating ripples to the distant sky
Bees buzzed in the dun parched hollow

—<0>—

My footsteps plodded down the shadowed forest path
Cracked sudden on a thin-iced puddle
Jagged slivers traced a star out to the lace-edged frost
Concentric angles radiating from minute points

Like the veins in maple leaves above
Touched with flame, ablaze against a lacquered sky
That birch: a tumbled chandelier, leaves hued like candle flames

—<0>—

The sky bled fast to clotted indigo
Stars wheeled unchecked their arcing course
My crunching footsteps ringed with lilac in the snow
Beneath stark criss-crossed branches to my home, familiar cul de sac

Inside is gloom, it seems to be the end, so cold and dark and still
But at the hearth a ghost of warmth remains

Digging into ashes, there’s a sullen ember still

Blow gentle breath, the glow revives
With straw and twigs and crisp old leaves,
A ruddy light infects the stove, ignites

Soon leaping flames reveal the nestling room
Shadows stir and wave
The tinge of warmth invokes the memory of sun and light and growth

The fire’s heart: a den of coals ripples with its in-drawn breath
and flings it up as flame
Gives me hope and strength to abide the lull,
To ride the coiling year
Till Spring curves round again

With great vigor and a sense of wonder we headed into the great wide open that is Whistler Mountain. It’s not often that one can enjoy a day (or weekend even) on the slopes thanks to one’s workplace yet that is indeed what we were able to do as our work Christmas do.

Most of us stayed together within the confines of a lovely condo within Whistler Village itself. This allowed for some more relaxed socialising and a distinct family feel to the weekend as we all got to know each other better. The weather was fabulous and the snow was in immaculate condition, being so early in the season. As a group, those of us more comfortable with the terrain managed to stay together and enjoy the skiing/boarding together which is sometimes rare with larger groups as the more hardcore lose patience and trail off to find their own powder moments.

The thing that struck me most of all, apart from the great conversation, excellent skiing and riding and all round good times, was the fact that in two days of constant interaction, we all managed to NOT talk shop. This indeed is something that I think highlights our abilities to gel as a team (and as people) in that it shows we can actually have interesting and constructive interactions which do not necessarily bare any relation to our work selves.

In every team, there is a dynamic energy that brings it together. We recognize that the individuals in our team are not only critical to our success, but are also motivated by it: the key is simply to enable each of us to most effectively play our part.

As a small shop, we must all play different roles at different times. Our effectiveness is based on adapting to the shifting demands on our team throughout the project lifecycle. Each of our developers is both a specialist and a generalist. Besides constantly enhancing our general abilities, we actively cultivate complementary individual specialization, enhancing our ability to deliver technically distinguished software.

While shifting roles and specialization help us remain interested and committed, effective leadership is required to ensure everyone is playing the right role at the right time. We are oriented to shift roles as needed, and this includes the leadership role. While some team members possess natural leadership skills, others have particular knowledge and insights which are critical at certain points in a project. Smoothly transitioning leadership — sometimes on a daily basis — is a sign that our team is adapting well to the shifting needs of the project.

Such a dynamic culture is only possible with timely open communication. This includes communication between our team and the client, as well as within our team. We need to quickly share information as it becomes available. At a minimum, we have internal daily project meetings, and must be ready to remove impediments as they arise. We require our client to be available throughout the project to provide clarification and direction as needed.

Its not easy to establish and maintain such a dynamic team environment, but it is highly effective. We are able to deliver high quality software more effectively than either a solo developer or a large organization. This is very rewarding for all of us, which galvanizes our commitment to pursue and refine our approach.