Should coaching be treated as hourly contract labor?

Often, companies try to balance staffing with the natural variability in IT workload by engaging contract workers. They don’t want to make a long-term employment commitment to the number of people required to handle their maximum workload. So, they hire enough full-time employees to handle their typical workload, and in periods when the workload is higher they bring in temporary workers on a contract basis. That way, companies can expand and contract staff to match the internal demand for IT services.

Problems occur when the parameters of the temporary staffing engagement are at odds with the nature of the work performed. Because “coaching” has not been a well-understood category of services, it has more-or-less accidentally fallen into the “hourly contract” mode. Is this appropriate? Does this model cause difficulties for any of the three constituencies that have an interest in it: The clients, the workers, and the middlemen?

Continue reading

Billy Pilgrim and the software estimation debate

Warnings:

  • tl;dr
  • sarcasm
  • calories from fat: (don’t ask)

I’d like to begin with an insightful quote. Until I find one, here’s a quote from Vonnegut:

“I am a Tralfamadorian, seeing all time as you might see a stretch of the Rocky Mountains. All time is all time. It does not change. It does not lend itself to warnings or explanations. It simply is.”
— Billy Pilgrim in Slaughterhouse Five, Chapter 4 (Kurt Vonnegut)

The online debate about software estimation may well be the greatest waste of pixels since the invention of porn. Like porn, the debate comprises a never-ending repetition of the same scene over and over again, the very definition of “boring.” And the actors conclude each day in the same state they were in when they awoke. Every day the same, every day exhausting, every day pointless.

The argument, like Kenny of Southpark, refuses to die. It wakes up each morning as if nothing has happened. In a sense, I guess, nothing has.

Anyway, here’s the thing: Despite people’s best efforts and their protestations to the contrary, no one can predict the future accurately and precisely.

Continue reading

The what, the how, professionalism, and pragmatism

Warning: Rant
Warning: tl;dr

So, there’s this idea floating around of technical debt. There are some nuanced definitions, but in general it means bad design baked into the code. The “nuance” has to do with why bad design is baked into the code. There are a lot of debates about this, and you might wonder why, as it isn’t intuitively obvious how anyone could argue in favor of baking bad design into their code.

Yet, they do.

Continue reading

Don’t do anything stupid on purpose

It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.

Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading

Best practices for software development

There’s no shortage of advice about best practices. Naturally, commercial enterprises like IBM and Construx have advice. Their advice is designed to lead people toward their products and services. Of course, that’s because they believe their products and services support best practices. After all, they designed their products and services on the basis of what they consider to be best practices. So, it’s all good, right? They’re financially successful, so we can trust them. Besides, everyone knows that commercially-packaged best practices are carefully designed and well proven.

Individual practitioners are also eager to share the practices they have found "best" in their work. Their advice can be helpful, provided we remember it tends to be opinionated ("Git:Mercurial = Assembler:Java" — not "practices," BTW); haphazard and idiosyncratic (not to mention sexist and poorly written); specific to a single technology (and poorly written); or a rehash of generalizations (supported by questionable references). Like this Wikipedia article (as of 24 July 2013), such advice "has multiple issues." Continue reading

Why should we do code katas?

I participated in a coding dojo recently in which some of the comments I heard caused me to think about the purpose of practicing code katas. It seems that many programmers, including some pretty advanced ones, don’t quite get the point.

We were reading about some code katas online so that we could choose one to do for the dojo. We came across a description of the Bowling Kata written by Robert C. “Uncle Bob” Martin. A couple of the guys quickly dismissed it when they saw Uncle Bob’s name. “He’s too prescriptive,” said one. “I don’t want to be told how to approach the problem,” said another. They looked for a write-up of the Bowling Kata that didn’t try to guide us in how to approach the problem.

They found one and we used it. All evening we kept running into silly little issues and speed bumps, such that we really didn’t get a lot of value from the whole exercise. We went down tool-related side paths, broke our development environment a couple of times, forgot what we were trying to accomplish, and started over multiple times. It never felt as if there was any goal or even a general direction. Despite the fact the group included some very fine professional programmers, I have to say it was not the best coding dojo I’ve ever been in.

Obviously, due to the sort of democratic and participatory event a coding dojo is, I have to accept a share of the blame for that. I actively chose not to make suggestions to bring the activity onto some sort of intentional course, because I wanted to see where it might go. In the end it went nowhere, but the experience led me to sit down and reconsider the reasons we do these things, and how we can get value from doing them.

The key point is that there are reasons for Uncle Bob’s approach to katas. Rather than getting to the point directly, I’m going to begin with a couple of rambling digressions, as per my usual style. Continue reading