Saturday, September 18, 2010

To Be or Not To Be, That is The Question

So, a week ago I began working with a small but expert software development shop, after a project turned out to be more complicated than I could handle on my own. Rather than look at it as a project I would manage and run, I decided to look at it as an opportunity to learn and serve. I've been too far out of the loop for too long to do anything else, and my anxiety level kept spiking whenever I thought about how to get from start to finish. While I could have continued, and floundered until I got something done, the client wouldn't have been as well served... and I would have wasted a lot of time trying to discern good models of behavior from ineffective practices.

Distinguishing poor practices from effective ones is not impossible when working alone, but it is thereby made much harder than it need be.  A common occurrence in the office this week was for one of the senior developers to peek over the corner of the panel display, to ask one of the more junior developers about some quirk of syntax or change in library semantics. Kids like to play with the new tools, and in doing so they pick up the idiosyncrasies quickly - so when those idiosyncrasies change they are among the first to know.  But more to the point, trying to grind through such a question alone could be a 30 minute book-and-google-forum-search ordeal,  where asking the kid nearby usually amounts to time to fix in the 30 second range. That's about a 60:1 reduction, and over the course of a day that can really add up.

This week made me rethink about programming as a credible practice, as opposed to virtual work slavery. The office environment has a paced feel, not at all rushed or high strung. That in itself is worth emulating, but they get measurable work accomplished each day too. Sometimes the movement forward felt slow and short, but it was there, and the codebase is increasing both in size and in functionality. Also, testing is done as a necessary and sufficient flow of work, not as a bolt-on adjunct that one jettisons at the least bit of anxiety about deliverable dates. All in all, it was a much more humane way of working.

Despite that, there were things that felt oddly off, as if they could be working better. The pace of functionality addition seemed exceptionally slow. Perhaps that was because we were also changing significant parts of the technology stack: Ruby on Rails 3 was new and the RSpec test patterns were being updated. Perhaps too, because my own pace in this new language and environment means that I'm more of a distraction than anything else. I hope to do some catch-up this week-end on the crude syntax and basic patterns, and contribute more next week.

Another thing that is odd about the Behavior Driven Development is that the practitioners I've come into contact with measure the problem domain with an overly crude and imprecise rule. As if one were to start out deliberately measuring the coast with a 3000 mile long ruler, then with a 2900 mile long ruler (and make refinements), 2800 miles, and so on, until the measurements are made with a ruler short enough that the stakeholders no longer complain about the differences. The development process breaks the narrative down and reforms it as if the scenarios were the steps of an iterated fractal.  I can see now how B.D.D. promotes a focus on just the relevant functionality and eventually leads to just enough precision in practice. Still, it seems like it would be a little more efficient to start with the ruler slightly closer to the final size, or at least halfway there again, than to start with the most vague notions.  I suppose that is a matter of experience and judgment.

Finally, I'm liking what I've seen thus far. For whatever flaws it has, Ruby is a rational development environment that successfully promotes the rapid application methods that seem so completely squandered on the Java stack. The developers cooperate with each other, work hard, and still have time to jibe one another respectfully. They communicate with each other with and apparent honesty and openness that is rare to see in a professional environment. I don't know how long this will last, but I will pick up good experience as long as I'm able to do so.
Post a Comment