Category Archives: People

The “Sofware-Project-as-a-Ladder” Metaphor

ladderThe world of software development is a world full of metaphors. Since its early days, software development has been compared to fields like writing, construction, and even rugby.

Metaphors are important for understanding unfamiliar topics and, yes, even in the 21st century, software development — with its own set of peculiarities — is still unfamiliar to many, including people who have worked in the software industry for decades.

Today, I would like to contribute yet another analogy by comparing a software project to a ladder.

A classic wooden ladder is made of two rails and multiple rungs, mounted together with wood glue.

THE RAILS

No matter what kind of ladder you build — short or long — you need two firm rails that act as a framework for the rungs.

In software development, the first rail corresponds to the people and the second to the process.

It is fairly obvious (and much has been written elsewhere about the fact!) that you need the right people in order to succeed. Right means highly motivated, proactive developers with the required skill set for the job at hand.

But you also need the right process that makes sure that developers are going in the right direction. The process doesn’t need to be heavy and bureaucratic (it shouldn’t be, in fact), but it must ensure that work progresses steadily towards the final product and that no important aspect of the product is overlooked. In short, a systematic process is essential to remove the “chance factor” from a software project.

THE RUNGS

Once you have the rails you can add rungs. Rungs will ultimately determine how long your ladder will be. Every rung gets you higher and closer to your goal.

In software development, rungs correspond to practices. Practices like continuous integration, unit testing, refactoring, static analysis, just to name a few. While the process has long-term, far-reaching influence on a software project, practices are micro-processes, steps that are taken by developers on a daily or hourly basis. Processes are strategic, practices are tactical. Each rung on a ladder only has a small impact on the overall length of the ladder, but it is the sum of all rungs that makes up a ladder.

THE GLUE

To get a sturdy wooden ladder, you have to put wood glue inside the notches. This way, you ensure that the rungs will stay in place, even under load.
Even if you have the best-quality rails and rungs, your ladder will sooner or later fall apart without glue.

In a software development project, glue corresponds to the environment that an organization provides to the team: quality of offices and technical equipment, but also issues like work appreciation, salary, and overtime — in short: how people are treated. These factors influence developer motivation and productivity and whether they will stay with the project and the company. In a bad environment sustained quality work is impossible.

I know that every analogy breaks down at some point but what I like about the “Ladder” metaphor is that it doesn’t favor any particular element. For a successful project, one that delivers a great product on time, everything needs to be right: people, process, practices, and environment.

In Defense of B Players

A couple of months ago, I came across Jon Soberg’s post “Why hiring B players will kill your startup”. According to him, B players (who actually do a good-enough job) are the worst hires you can make. I totally disagree.

I’m convinced that having only A players on a team is neither possible nor desirable. Just imagine you would assign rock stars developers like Anders Hejlsberg, Linus Torvalds, and James Gosling to a project. What do you think the outcome would be? I wouldn’t be surprised to find them all dead within 24 hours…

You certainly do need A players. They are usually full of energy and highly creative. But in my experience, they often lack persistence and they get bored easily when they are assigned mundane work, especially over an extended period of time. Just like athletes permanently want to put their muscles to the test, A-level coders permanently want to challenge their brains.

Unfortunately, they don’t always use their brains to invent and implement awesome features that customers are willing to pay for. Instead they love to try out new technologies and spend countless hours tinkering with questionable language features.

Very often, these alpha coders have strong opinions, behave like prima donnas and are — let’s face it — not exactly what you would call great team players.

On a real-world project, you need B players, developers who don’t shun away from grunt work. Even if they are not brilliant all the time, their main strength is getting things done. Instead of just conceptualizing features, they actually implement them — in good-enough quality. They rarely gold-plate or over-engineer; instead, they live by the Extreme Programming maxim “The simplest design that could possibly work”. They are what Joel Spolsky calls “Duct Tape Programmers”.

To be successful as a company, you will need both, A players and even more B players. Use A players as lead developers, to generate ideas and to develop prototypes; employ steady performing B players to ensure that your products actually ship.

Just having A players can certainly ruin your business, too.

Masterpieces

I’ve already written about the importance of daily practicing for software developers. One essential habit is Playgrounding, where developers practice in easily accessible try-out areas.

Playgrounds are great for tactical programming, when you want to explore a language feature or a certain technique. In order to try out strategic — or larger — ideas you need something else, something I call Masterpieces.

I borrowed the term Masterpiece from the guild system that was (and still is in many countries) responsible for the education of professional craftsmen. Journeymen who want to become masters not only have to take theoretical lessons and write exams; at the end they have to present a so-called ‘masterpiece’ which is meant to demonstrate that they possess the required skills of the trade.

In my opinion, developers should work on Masterpieces, too.

By my definition, a Masterpiece is a project that serves to improve development skills, provides real-world utility to others, and demonstrates the skill and maturity levels to potential clients and employers.

The last point should not be underestimated. As a hiring manager, would you rather hire developers who can demonstrate their abilities (and stamina) to create real-world software products or people who just claim how good they are? (Usually, for legal reasons, it is next to impossible to show production code from a previous (commercial) product that candidates have worked on, but with Masterpieces it is easy.)

Masterpieces don’t have to be true masterpieces according to the other generally accepted definition of the term: “works of art of outstanding quality and/or novelty”. If they are, that’s terrific, but the main focus of a Masterpiece is on skill-improvement and demonstrating the “can-and-willing-to-do” attitude of a developer. Nevertheless, it goes without saying that Masterpieces should be of decent quality. For instance, source code should be laid-out nicely, have good identifier names and there should be documentation, at least a README file, that shows how to use it. If there are automated unit tests, so much the better!

Here is an example of a very small Masterpiece. Some time ago, while trying to improve my Python skills, I wrote a tiny tool called “NoComment!” — a Python script that scans C/C++/Java source code and counts the total number of commented and uncommented lines. It also calculates a comment-density metric. Call it trivial, but it does have real-world utility. You can use it to easily find out if there is code in your project with too little documentation. Even though it is extremely simply, I added a README file, some regression tests and put it up on Sourceforge.

But just showing that you are a great coder is not enough these days — social and especially communication skills are at least as important.

That’s why Masterpieces are not limited to implementing software. You can improve, share, and demonstrate your skills by hosting blogs, giving lectures at conferences, publishing tutorials, podcasts, screencasts, and by contributing to Q&A sites like stackoverflow.com (who wouldn’t want to hire Jon Skeet for his next C# project?).

Masterpieces are a clear win-win habit: you can improve and demonstrate your skills, while others benefit from your knowledge and experience. Just like in the guild system, you cannot become or be a master without them.

Software Project Democracy

“It has been said that democracy is the worst form of government except all the others that have been tried”
— Sir Winston Churchill

Considering all that fuss going on about agile processes these days, I sometimes wonder if this is yet another case of violating the first principle of the Agile Manifesto:

“Value individuals and interactions over processes and tools”

Given that there are so many books and consultants on the subject of Scrum/Kanban/Lean Product Development, isn’t it possible that people once again focus on processes instead of individuals?

While this hype is certainly annoying at times, the answer is a clear “No”. Agile processes care a lot about individuals and give democracy to the whole team. There is a clear concept of cross-functional, self-managing teams. Developers “pull” their work and decide (or at least largely influence) what and how to do it; work is not foisted upon them by a single dictator (aka. traditional project manager). In Scrum, the project manager role is filled by the product owner together with the rest of the team. This distributed style of project management is democratic, empowering, and very motivating for all members.

Yet, the most people-valuating “process” I’ve ever heard of comes from Tom DeMarco and Timothy Lister, mentioned in “Peopleware”:

1. Get the right people
2. Make them happy so they don’t want to leave
3. Turn them loose

To me, this is the best recipe for project success ever. If you’d follow this “process”, you wouldn’t need Scrum/Kanban/XP at all. If your team just consisted of smart and motivated people, everything else would follow. Why? Because as part of the team — and most importantly — you would also have the “right” leader, one who clearly says what to do and in what order. I’m not talking about a Gantt-chart/PowerPoint virtuoso, but a leader with the following properties and skills:

1. Charismatic, a born leader
2. Systematic, follows-up issues
3. Technically adept
4. Cares about the product and the team more than his/her personal career
5. Has the respect of upper management and the rest of the team
6. Shows that (s)he cares by inspecting and criticizing the main work product (the “Source Code”)

Alas, such gifted leaders are very hard to find.

Some claim that in real life benevolent dictatorship is by far the best form of government, much better than democracy, which is accompanied by frequent shady compromises. But also in real life, benevolent dictators are hard (if not impossible) to find and that’s why democracy was invented. So despite of all its shortcomings, democracy is the best government system in practice.

In some sense, you can view the appearance of agile methodologies as a result of our industry’s inability to find the “right” leaders. Yes, there are training and certification programmes for project managers, but in my honest opinion, they don’t help a lot; if anything, they focus on the “systematic” part, yielding people that spend a lot of time on upfront planning, estimation, and project reporting (“defending”) to upper management. They not only waste their own time but also the time and motivation of the rest of the team.

Hence, I think this strong shift from software management absolutism to software management democracy — from traditional project management to lean and agile management — it is not just hype. It is a natural and logical consequence. It is an uprising from the disappointed and suppressed “doers” who have had to suffer far too long from “traditional” project management practices.

Until our trade has developed a system for breeding benevolent leaders (like the guild system did hundreds of years ago with the apprentice/journeyman/master model), I vote for agile software development and the software process democracy that it gives me.

 

 

Documenting is a Team Sport, Too!

baton.jpgEveryone likes good documentation — unless they have to write it themselves, right?

One reason for this is that writing good documentation is hard, very hard in fact. It took Joseph Heller eight years to complete “Catch-22” and many other novels took even longer to write. As a countermeasure, some authors use a pipelined approach to writing (see Gerald M. Weinberg, “Weinberg on Writing: The Fieldstone Method“) that nevertheless allows them to release in shorter time-frames by working on many projects in parallel.

Speaking as a developer, documentation gets into my way of doing other, more enjoyable things, like, well, coding, for instance. I’m writing (!) this article to the defense of the poor chap who has been given the ungrateful job of writing version 1 of a document.

Imagine this situation. One of your team members, let’s call him Jack, is given the task of finding out how to setup a new development environment for some embedded Linux development board. After a week of trial and error he finally gets everything to work properly. Now — of course — he is expected to document what he did so that everyone else on the team can set up their own boards, too. Being a professional developer he sits down and types away; an hour later, he is finished.

What happens next is typical: Harry, the first guy who tries out Jack’s HOWTO, runs into problems. Not one — many. In some cases essential steps are missing, while others are confusing or just plain wrong.

Harry is upset. He runs about and whines how bad the documentation is, what a poor job Jack did and how unfair life is in general…

For sure, in a perfect world, Jack would have written a perfect document that lays out the shortest route from A to B; it would be instructive, entertaining, a work of great pedagogical value. In real life, Jack is exhausted. He had been a pioneer for an extended period of time, tried out many things that didn’t work, suffered hours of frustration and got stuck in a rut many times. Most likely he operated under time pressure and even more likely he doesn’t exactly remember what he did (and did not). Isn’t it a bit too much to expect that he now takes the perspective of the uninitiated developer and writes the perfect manual?

In my view, Harry shouldn’t complain — he should rather spend his energy on improving the document. He benefits tremendously from Jack’s pioneering work and I think it is only fair if he contributes a share. And what he can contribute is something that the original author can’t: When he reads Jack’s document his mind is fresh and clear, without any assumptions, so he is the best person to tune the document for the same kind of audience. And Jack is always there to support him — provided Harry didn’t insult him for not doing his job properly…

But even the next guy after Harry might spot mistakes or inconsistencies; and many month later people will discover parts that are obsolete because the environment has changed in the meantime. Then, it is their job to clean up; they are again the best persons to do it.

Writing good documentation takes both, a different mindset and time; and as the writer’s saying goes: “All good writing is rewriting”. Especially in an agile environment it is a bit too much to expect to get everything from a single person. XPers have long been used to this mode of software development through the principles of collective ownership and refactoring. I believe, these principles apply to writing documentation as well.

The Manager in the Room

room.jpgEarly in my career, I had a boss who was spending most of his time in his office—and what a huge office he had! In fact, his office was so big, you could hardly see him, as his desk was located opposite to the door at the far-end of the room. Hunched over his keyboard, he was diligently hacking away, coding on his (more or less) private little project that he enjoyed so much. Little information flowed from him and if you dared entering his palace, you always felt a sense of guilt for disturbing him.

In retrospect, I think it is obvious why he behaved like this: what he really loved to do was programming, but since there was no technical career ladder, he had to become a manager in order to advance his financial situation. So this introvert, technophile person took on a job he wasn’t qualified for, a job that required dealing with people first and computers second.

But what exactly is the job of a manager? There are many answers to this question, but in my view, there are two things that stand out:

1. Removing obstacles
2. Showing that one cares

Removing obstacles means that a manager has to do everything humanly possible to make sure that the team can work as effectively and efficiently as possible. This includes many of the obvious tasks, like getting proper infrastructure, money, and staff. But that’s just the bare basics. I have heard of a manager who didn’t get approval for buying a coffee machine for the team, so he bought one out of his own pocket. I guess the money was paid back nicely by his teammates—not in money, but in increased motivation and loyalty. Lack of space? If he has a better/bigger/quieter office than the team, he should offer to switch rooms. And if there is a problem with the bathroom, well, let’s hope for our manager that he can find a janitor…

I once worked for a company where the department manager (another “hide-in-the-room” kind of manager) delegated organizing a company outing to a senior developer, an assignment that dragged on for days. I think that this brilliant manager did a wonderful job of demonstrating his superb status, but wasted valuable development time—which is, to quote Peopleware, the ultimate management sin.

“Removing obstacles” really boils down to what Robert Greenleaf called “Servant Leadership” in the 1970s, but the concept is much older, summarized in the words of Chanakya from the fourth century B. C.:

“The king shall consider as good, not what pleases himself but what pleases his subjects. The king is a paid servant and enjoys the resources of the state together with the people.”

Even though removing obstacles is very important, it is not at all sufficient. We all know that perfect service is unnoticeable and thus the team might not know about all the fine work that is going on behind the scenes. Even if the manager works like crazy to keep the ball running, the team might get the impression that what they are doing is not important after all.

There is only one way to fight this: the manager has to get out of his room. Often. Very often. For a manager it is not enough to spend most of a day sitting in meetings with peer managers and/or top management: a manager has to spend time with the team, everyday, without giving them the impression that he is checking up on them and—needless to say—without wasting their precious time. All a manager has to do is clearly convey the message that he truly cares for the work his people are doing. By walking around, by asking how it is going, by telling jokes, by asking technical questions (without being afraid that most of his people are much smarter than him), by asking if he can lend a hand (for instance, it’s a disgrace if a developer under time pressure has to convert some data manually—a mundane job that’s perfectly suited for a servant leader).

Being a successful manager requires many skills and practices, but almost everything derives from these two items. Managers everywhere: Don’t insist on your status and be present; be a good servant to the team and clearly show that you care—for your team and the work that they produce.