Is just getting the job done always enough? One of my personal philosophies is that if you’re not learning, you’re not improving. If you’re not improving, then what have you really accomplished? In fact, there’s a pretty good chance that you’ve even gotten worse, if only because everyone else has gotten better. It’s like a television or movie series that comes back year after with the same old, tired formula. No better than previous iterations, and doesn’t even meet the expectations set by its predecessors. Think Bond, James Bond.

So how do we learn?

Let’s suppose that you wanted to learn how to survive a volcanic eruption. You have two basic options: go and find someone who’s done it before ( Tommy Lee Jones?) and learn directly from them, or, find a book or other information source and learn it on your own.

Where I work, both options are impractical, for different reasons, within our product, development and quality assurance groups. As part of the dev team, I’ll only speak to what I’ve observed here but I think it applies just as well to the other groups.

Learning through the sharing of experience

In our core team, we currently have 31 developers (excluding myself): 5 leads, 7 senior developers, and 19 junior. Ranks are strictly based on years of experience, which has no bearing at all on quality of experience. In essence, the knowledge gap between our junior and senior developers is small, and even smaller between our seniors and our leads. After a certain amount of time in the team, a developer sort of plateaus — this is how we do things, and, well, that’s that. The mentality is, “this is how I was taught by the guy before me and it seems to work well enough, so why change?”

Self learning

We’ve got some bright people on the team, there’s no question of that. If given the opportunity, they’re capable of doing good work. The problem we face is that they just haven’t been given the opportunity. Not once, in three years. Our schedules are the most aggressive I’ve ever seen, without any break between releases. The schedule simply does not allow for any amount of experimentation with new techniques or technologies. We tried introducing some change in to one of our current projects and we’ve been burned pretty badly by it; we slipped on a date for the first time since I’ve been around, and the repercussions have been swift in the making. More on that later, but first…

Some history

The software division started out as many software stories do: a couple of smart people with lots of domain knowledge, but no technical expertise, and no product, went out and sold an idea. Through sheer force of will, and the help of one very sharp developer, they managed to build and deliver on their promises in a matter of months. As the deals rolled in, and with them, requests for more features, the engineering team grew slowly but things quickly boiled over, causing that first developer, who started it all, to leave abruptly [1].

From there, it was a long, slow descent to the present day. The developer wasn’t replaced quickly and the decision was made to move core development offshore, at a much lower cost. No one back at headquarters really understood what was going on in development, just that things seemed to be working smoothly. Dates were hit, features were delivered, customers were happy, and their numbers were growing. What more could you want?

Well, at some point it was decided that an entirely new platform was required for the company to continue on it’s current growth path. A “forklift” project that would be developed in parallel and eventually replace the existing system, which would continue to be developed as demand was still strong and new customers were being signed on. New talent was finally brought in but the existing resources never benefited from them, as they worked in isolation. The goals for the new project were technologically lofty, to put it mildly. Time passed and milestones were missed, dates slipped further and further, and eventually the project was scrapped in favor of the existing platform which continued to enjoy success, in that it was always on schedule.

Everybody panic

Cut to the present. We’ve had a few production outages, with some lasting for more than a single business day. The type of business we’re in, and the money at stake, not to mention the promises we’ve made, this is totally unacceptable. We’ve had dates slip. The platform we’re building on top of is unstable to the point where every release only compounds the performance problems we see in production. Our customers aren’t stupid — they’ve noticed the consistent performance degradation and have been complaining pretty steadily, so far to deaf ears.

The reaction? Knee jerk. I’m told a consultant is being brought in, and a project manager hired and set to start in a week’s time. I’ve no idea how they came to this, as no one in my team, now numbering 42 developers at last count, was interviewed or consulted before any decision was made. In fact, I’m not even sure my boss was.

I think it might be a small step in the general vicinity of something vaguely trying to resemble the appearance of being in the right direction, but, given past performance, I don’t think it’s going to work. There is a tendency to stop short of solving the real problems, and in doing so, generally causing more harm than good. I’ve some thoughts on a real solution, but I’ll leave that to another post.

[1] “Sure, I’ve been there, getting the wrong answers from the boss. Some business people just aren’t good at making informed decisions even when you’ve patiently explained all the tradeoffs and benefits. I think we, as programmers, need to be sure we’re holding up our end of the bargain - delivering all the data the business-people need to make good decisions. When they make bad ones anyway then it may be time to find a new job. Until then it’s our job to follow orders, and to make the best use of the time we’re given.”