Monday, October 24, 2011

Gorillarinas, Putting the agile skirt on a waterfall Gorilla

Fact: putting a skirt on a Gorilla doesn't make it any more graceful

Ballerina gorilla

Are your agile initiatives Gorillarinas?

If you're working in a large organization and trying to "be agile", it often turns into a strange situation where only a superficial set of changes are made, but folks wonder why their initiative isn't able to deliver the expected benefits. This is remarkably similar to putting a skirt on a Gorilla and then wondering why it isn't suddenly graceful.

I'm not saying you cannot train a Gorilla to dance ballet, I'm an optimist at heart and believe anything is possible. But don't make the mistake of thinking that the effort of taking an IT organization that has built up the overhead gunk and crud of a huge process and turning into a highly responsive and lean software delivery organization is anything less difficult than turning a Gorilla into a ballerina. This effort will be large, there will be casualties, and you will likely need expert help (or therapy).

As a member consulting organization, I get the benefit of meeting up with my compatriots at Redpoint to discuss the challenges, successes, and failures when working within transform hulking and clumsy organizations into something leaner, meaner, and more agile. One theme that recurs in these discussions is that many traditional processes are deliberately dehumanizing. They view people as interchangeable components that can be replaced at a moments notice and have no impact to the overall project. After all, if you've run out of ballerina's, you can surely substitute anybody (or anything) in a tutu to do the dance, right? This is a key failing and just plain wrong, and even in organizations that throw around slogans and mission statements proclaiming how important everyone's individual contribution is, all traditional processes turn developers, QA analysts, and even Bob the dinosaur into "Resources".

Some ways to know if you've got a Gorillarina:

  • Daily standups status report meetings that ALWAY last 1 hour (or longer)
  • A variety of torture devicestask/bug tracking tools... one for the "official" stuff and one for the "agile" stuff...
  • ScrumMaster who's responsible for the work and assigns tasks to team members!
  • Team members who sit around and wait for someone to tell them what to do
  • Time-boxes that are well intended, but just never seem to work
  • Planning starts with announcing a release date, then estimating the effort involved
  • Retrospectives are about collecting lessons learned for our PMO to track!
  • We do Pair Programming (a senior guy reviews all commits), Test-Driven Development (20 page formal test plans review d by QA AND the analyst team, and use Continuous Integration (we do a massive build the week before a release)
  • User stories, requirements stories, development stories, test stories, and all sorts of other “types of stories” allow us to track the work!
  • Our impediments list helps track why we miss our commitments!
Some things you can do to pave the way toward having a more graceful Gorillarina:
  • Recognize that you are not going to instantly get results by doing standups or using notecards or renaming your project manager the "Scrummaster"
  • I know it's been said 1000x, but empower your team(s) to solve problems, if your process is getting in the way, ditch it... or fix it...
  • Recognize that "agile" is not a technology thing, it's a business thing... everybody needs to have skin in the game.
  • Agility is about values reified as techniques and practices, not merely practices!
  • If you're in the Chicago area, drop us a line at
  • Find another organization that has a track record or producing results and let them help you (although our sales department would really like you to use the link above ;) )

One last note and something that was brought up while editing. Agile is not JUST the practices (jeez, there we go again...) it is as much about building shared values and attitudes about what the team is doing. Many organizations think they can send a couple of guys to "scrumaster training" and they'll come back and infect the entire organization. Helping transform teams and entire organizations from one mindset to another is a job that requires practice, experience, and skills that are not acquired in a one (or two) week class. It takes a certain type of person to fulfill this mission and if your goal is REAL transformation, it is in your best interest to seek out folks who have a proven track record. It can be a daunting task for someone who is inexperienced in the field, and if you think you can send a Business Analyst to a training course and then have them run around your organization waving the magic "agile" wand at projects, you'll most often end up with a bunch of "agile best practices" but no real transformation.

Special thanks to Si Alhir and Steve Fastabend for feedback and editorial assistance....

Wednesday, October 19, 2011

Promiscuous programming

How many folks out there are promiscuous programmers? You know who you are, every project you work on, you meet a new technology or language and feel compelled to "try it out"... without giving the right amount of consideration to the language that is currently being used. Worse yet, you seem compelled to badmouth a language that has been really good to you ( I love you java;) ) and always compare the imperfections of your programming wife ( java, you're syntax is really bloated) to the sexy cool stuff from one of your programming girlfriends (ruby, I love your monkey patch).

I'm not saying that this is necessarily a bad thing, I think it is very important to have breadth in technology and learning new programming languages is a way to become a better programmer. It's more important though, to have an objective perspective about the REAL comparison and not just get infatuated with every new thing that wanders by because you think (or worse yet someone else thinks) it's better. Listen to me folks, the grass is rarely greener on the other side of the fence... It's different, and frankly it MIGHT be greener... but even if it IS greener, that doesn't necessarily make it better.

So where am I going with this? Am I suggesting that being a promiscuous programmer is a bad thing? Not really... and in that respect perhaps the metaphor is a bit bad. But, you have to suspect advice about women from a guy who's only ever been with one woman about women because ... he has a noted lack of experience. What I'm saying is when you're starting out, playing the field and figuring out what you like is important, but it's also important to commit to something and really "know" it. Make sure that changing languages is a conscious decision and you weight the benefits and drawbacks of such a switch lest you spend your entire career as a programming slut flitting between one fancy new thing and another.

Thursday, October 13, 2011

Two factor developer personality type scoring

I was recently sitting through a technical discussion and was thinking about how different people were reacting to the information in the presentation. From this I started to think about how a two pairs of related factors seem to influence how people react to new technology. Here's a quick chart showing them as well as examples of prototypical statements a person at each extremes in each quadrant might speak about Source Code Control:

For a bit of definition:

  • The Conservative - Liberal continuum is a measure how inclined you are to try new technologies. An extreme conservative feels no need to use anything new and will never use anything new unless the old thing completely fails to work any more. An extreme liberal would be compelled to change technological approaches before even finishing a prototype because a new shine technology showed up on their radar.
  • The Skeptic - Believer continuum is a measure of how much critical thinking you put into a new technologies capabilities. An extreme skeptic would tend to disregard pundits and anecdotal evidence and require solid proof. An extreme believer will have a religious-like believe in a technology that has no basis in fact.

The reason I put this chart together is to help understand that these things are not binary switches. In addition, some traits are orthogonal (Skeptic and Conservative), but some are in opposition (Skeptic Believer). Moreover, different techniques are necessary to understand how to interact with folks depending on where they fall in both continuums.

Conservatives will generally require a lot of selling or you will need to burn the bridge behind them or they will continue falling back into the "good ol way of doing it". Conservative Believers will be the hardest lot to convince because the sheer amount of time they've been doing something (no matter how stupid it might be) will actually be a reenforcing factor and no amount of factual evidence to the contrary will sway them. On the other hand, a conservative sceptic can often be swayed with evidence and a good business case for doing things "the new way".

Liberals will generally require more oversight as they will tend to embrace and proliferate new technologies. Liberal believers are the most difficult because they will do it just because they read about it on hacker news and it sounded cool. These guys often need to be brought back down to earth lest your systems be riddled with one-off science experiments. Liberal skeptics (I'd put myself largely in this camp) are easiest for me personally to deal with, but I think that's because I'm one of them. For the most part, the closer to each other on the quadrants your team is, the more likely you are to get consensus on what to do (or NOT for some groups.

Wednesday, October 12, 2011

My javascript parseInt("08") surprise!

I recently had to debug a problem that was causing a javascript function to return the incorrect value. The code in question was right padding numbers less than 10 with a 0: so 1 became "01", 2 becomes "02" and 10 should be "10".
Number.prototype.to_s = function() {
    if (this < 10) {
        return '0' + this.toString();
    } else {
        return this.toString();
This works fine... in one direction.
I kept running into a problem when I tried to parse this back into an integer.
So I'd do something like
and the result would be 0. What I didn't realize is that the "0" prefix when parsing an string indicates the number is base-8 (octal) and therefore "08" isn't a valid number. I would have, however expected some sort of error message or NaN instead of 0. The problem is that javascript will only return NaN if the first character in the string is not a number... so It happily saw that '0' was a number, but '8' was not (in base 8) so it returned 0.
Aside: I see that this method of specifying base-8 is not supposed to be deprecated

Tuesday, October 11, 2011

JIRA, Pivotal Tracker, and for issue tracking

I've used each of these tools on at least one project now (JIRA for quite a few) and thought I would share my observations about when each one would be most appropriate.

Pivotal Tracker

Pivotal Tracker is only offered as a cloud based or hosted solution, but has a pretty impressive list of customers. On the upside, they've fully embraced the cloud concept and offer a well documented set of RESTful APIs to integrate with third party systems. You can connect issues to SCM commits using post commit hooks from svn or git (or anything with a little effort)

I find the pivotal tracker User Interface be a bit confusing, but pretty useable out of the box and geared toward agile methods. Another big plus is that they can auto-estimate your actual velocity and burndown which helps you get your arms around your real velocity. In addition, they have some out of the box reporting. is also a hosted solution, but of the three has taken an more interesting approach to bug tracking. They've jumped on the gamification bandwagon and have tried to craft an experience that is actually enjoyable instead your typical cold-war soviet style user interaction that most bug/issue tracking systems seem to espouse. While innovative, they are missing some features and are decidedly still in the Minimun Viable Product stage.

You can integrate with git via post-commit hooks, but third party integration doesn't exist is still in beta and frankly the documentation was somewhat difficult to find (hint -- the link is in the footer). I can appreciate the idea of keeping things simple and this product will certainly work well for a small agile team or an independent who's just keeping track of things for himself. It's hard to say how this would scale to a larger team or very complex project as it is deliberately bare bones and I suspect this could work against you on a largish project or team.


Last, but certainly not least, is Jira from Atlassian. I'd consider this the 800lb gorilla of bug/issue tracking and I've used it for years on multiple projects in a variety of teams and workflows. Frankly, you can do anything you want with this product... They can host it, or you can run it internally with a slew of different databases. It integrates with just about everything, and it has a plugin system that folks have used to build a vast array of plugins to help do just about anything you want.

The default user experience seems is horrendous and to match the impedence between what an agile/small team might need and the default JIRA config you're going to waste a lot of time either fetching plugins or configuring things to work how you want. JIRA's biggest strength is also it's biggest weakness and it would be difficult for me to recommend JIRA for smaller teams or startups as it's enormity imposes to some serious overhead --- either you eat the time trying to figure out the default UI or you eat the overhead of configuring it to be less complicated...

Here are the users I think would be a good fit for the tools:

  • A small team who just doesn't want to lose track of bugs or tasks, and has an interest in keeping an informal and deliberately fun culture -
  • A similarly small team, but one that finds a need for stronger organization and reporting options and/or if you think the idea of bug tracking being fun is somehow off putting - pivotal tracker
  • A large team or large organization who has thousands or hundreds of thousands of issues to track and will end up with a full time person or more to help manage track them. Additionally, if you need to host in-house, JIRA is the way to go

Thursday, October 6, 2011

Should I use mongodb, couchdb, or redis?

In the current nosql fervor, there is an important distinction that seems to get missed repeatedly. There are two (OK three) really important factors that these tools use to distinguish themselves and many people completely miss the point.

The first factor is durability -- does the data actually get saved to a disk somewhere and, if so, how often and how much might I lose if something "goes wrong"? Redis and mongodb users might be somewhat surprised to learn that, by default, they can lose your data should the process crash or shut down. While you can configure them to work around this issue, you're going to slow things down substantially doing so and therefore lose the big advantage they've been designed to provide. In short, redis is a great alternative to something like memcached, but is not really an alternative to something like couchdb.

Which brings me to the second factor, which is searchability (I couldn't think of a better term) -- Key-value stores are typically not designed to be easy to search, but to be able to fetch values by a particular key really quickly. Document stores are designed to enable more dynamic searching, often at the expense of some other attribute like speed, memory, or disk space.

Lastly, there's speed -- couchdb can be fast, but it's not really going to compare at real-time updates to mongo or redis. If real-time is your most important factor, couch is probably not your best solution (actually it certainly isn't your best solution).

So in the crop of current contenders (in no particular order) I'll give you my winners in certain use cases:

  • A fast disposable cache based on discrete keys: Redis... it's fast, it's widely known, it's easy to set up and use and more flexible than memcached (although memcached is also a good choice).
  • A durable and searchable document store that slowly accumulates more data and needs some concept of versioning (maybe like wikipedia or a blog engine): Couchdb
  • A quasi-durable searchable document store with quickly changing values (like a real-time status reporting application... maybe facebook or twitter: Mongodb

As for the other 9,999 choices that currently exist, I'd say don't dig around too much or agonize over your choice unless there is a specific and very important problem your application needs to solve that is difficult or complicated with these solutions. Should you get into that situation (like maybe needing to find directions like google maps) then you'll need to expand your horizons and look into other solutions. My recommendation is to start with one of these three and only go to a different solution when necessary. You could six months researching all of the possibilities and at the end have nothing but outdated research. Pick something and run with it, only then will you understand the problem and be able to make a better/more informed decision for your scenario.

More importantly, you'll probably notice that for many real-world solution, it might make sense to use all three of these (or more). I think part of what causes problems in "fair" comparisons of technology is that folks think they can pick the "single best solution for all problems" and that's just not a realistic perspective.