Lessons from Past Jobs (1)

In the following I try to learn from my experience as a young software development student working for a real company for the first time (as opposed to just building software projects for fun).

It was the summer of my first semester of university, and I had just applied for my first student job. The job was great for a student with no qualifications: it involved actual development work, and the pay wasn’t bad. I got the job.

The experiences I had at that company turned out to be very formative for me, making me set a higher bar for future employment and giving me first-hand experience with real problems in the software industry.

It happened to be just a bit after my first reading of Kent Beck’s Extreme Programming Explained (XPE), and I was excited to be working at a (self-proclaimed) Agile company, using XP in the day-to-day work. “Fantastic,” I thought, “a chance to see XP in the wild!”

Learning Curve #

The company had one full-time developer and three part-time developers (who were, at the same time, full-time students) working on their product. All of the part-time developers had been hired at the same time, and had no experience with the software.

The software in this case consisted of a big code-base based on a popular web framework. None of the new hires had any experience with this particular framework, but all had worked with web development in some form or other.

It is obvious to most people (as it was to me, even at the time) that adding new members to your team incurs some slow-down. This has to be taken into account when hiring—the long term benefit of teaching new members the ins and outs of a system should be worth the initial cost in time.

The day-to-day manager of the developers was of a non-technical background. There was no team leader to manage his expectations, keeping them realistic, protecting the developers. The full-time employee rarely worked at the same time as the part-time developers (mostly due to the irregular schedule of the latter group). This had two consequences: Little to no time was being spent on training the new team members, and the manager sprung unreasonable demands on the inexperienced developers, who had no one to teach them how to say “No.”

The manager had learned to trust his instincts on how long an issue should take to resolve, based on the full-time developer’s record. He had forgotten—or never learned—the notion of the learning curve. This led him to blame the (to his mind) excessive time consumption on the new developers’ lack of research or knowledge. (“You haven’t read enough about the framework.”)

The code base, while not initially the cleanest, grew exponentially messier as code was added by the new, untrained developers.

In a desparate call to limit time spent, the manager finally told the developers to not spend any time refactoring or cleaning up the code. This, of course, only added to the problem, making development slower and slower.

No coding standards were enforced, no peer reviews performed, no pair programming encouraged. It didn’t seem very much like XP at all.

Lesson learned: It takes time to get new developers involved in a project. The most efficient method is having a senior developer train them. For this reason, a team should never expand with more new employees than it has available senior developers: it is important to ensure that the business has the capacity for training the novices.

Lesson learned: A manager who does not have a technical background and does not trust his team’s advice can be lethal to development. In fact, any leader who doesn’t trust his team may be. The problem can be helped by assigning a technical team leader to mediate with the non-technical business people.

Lesson learned: Even if someone says they are Agile or that they are using XP, they might not be. Actually doing these things takes dedication, persistence and a willingness to self-evaluate. These traits are rarer (especially in corporate culture) than one should think.

“We Value Communication” #

On the first day of work, the manager made it clear to the new developers that the company valued clear communication. Communication was a very important value to them. This is straight out of XPE, and made me very hopeful. Because communication was important, and context was easily lost when communicating textually, the manager said, we would prefer face-to-face communication over all else. If that wasn’t possible, a phone call should be the go-to method of communication.

As the part-time developers were working late, at times where no other people were present at the office, we often sent emails off to the manager with issues that did not have to be resolved immediately. This was partly out of a desire to be as little of a nuisance as possible (the manager might be having dinner with his family) or because the questions would require more thought than would allow them to be answered immediately.

In the pursuit of direct communication, the manager had made the (unannounced) decision to not answer emails, choosing instead to take up the issue with the person when they next met.

Unfortunately, it sometimes took several weeks before the wondering developer was present at the same time as the manager. At this point, both parties had forgotten the original email. Too much time had passed.

In the end, putting direct communication on a pedestal had completely ruined the usefulness of other forms of communication, entirely counter to the stated goal of clear communication.

Lesson learned: It is easy to get blind-sided by pursuing the means towards a goal, rather than the goal itself. Constantly keep the goal in mind, and reevaluate practices based on how well they work.

Lesson learned: Recommending channels of communication is a great idea, to make it easy for all employees to get an overview. Limiting whole types of communication will have negative effects. Employees must be able to have quick, direct communication as well as well-considered and more offical ways of communication.

Notes #

XPE: Kent Beck, Extreme Programming Explained, 2005, Addison Wesley