Tell the Truth All the Time
It seems straightforward to say that everyone should always be truthful, but it's actually more challenging than many people realize. Most developers who have been around for a while have been in a situation where they changed the direction of a project by stretching the truth. For example, say a user wants a feature that will be very challenging or tedious to build, or for which the implementation isn't immediately obvious. For some programmers, it's easier to say that it simply can't be done than to take the time to do the required research or analysis. (Be honest--most of us have done this at least once in our careers, the authors of this article included!) In corporate projects, many features have been scrapped over the years because developers did not want to develop them--even when the company would have been better off in the long run had the developers built the software that was requested of them. Requirements will sometimes get trimmed and schedules will sometimes get padded when developers don't feel that a feature is easy to build--with or without the necessary investigation.
It's not just developers who are tempted to stretch the truth. A vice president or CTO may announce that a product will be done in a month, when everyone (well, everyone but the customers) knows it won't. A manager will cut out quality assurance activities without telling anyone. The company will decide to fund or not fund a project without explaining why. The entire direction of a project can be changed out from underneath the team on the whim of a senior manager, without any explanation whatsoever. Most of us have been in the awkward position of being told by a superior to ship software that was simply not ready for prime time.
So how do we make sure to tell the truth all the time? Building transparency into a development organization requires open discussion--open not just to the developers, but to everyone involved in or relying on the project. In a transparent organization--one built on honesty, rather than expedience--every idea is evaluated on its merits. Alternatives are openly discussed, in a forum where everyone feels comfortable giving an honest opinion. In that forum, the right decision will get made. A solution is not rejected because it's time-consuming, tedious, or a lot of work. If that solution is genuinely going to blow the schedule or cause serious technical problems, the decision may still be to reject the idea. But only through honesty and real dialogue will the correct decision--meaning the decision that's in the best interest of the project and the organization--be made.
Open source projects can teach us a great deal about transparency. Every successful, large-scale open source project has an open, archived discussion forum. They use mailing lists, wikis, discussion web pages, newsgroups, IRC channels, and other forums to make sure that developers and other project team members have many opportunities to bring up important project issues. But transparency requires more than just installing a wiki or mailing list software; it requires a real commitment from the team to make decisions openly and to keep everyone in the loop, and this is where open source projects really excel.
In contrast, managers associated with many corporate software projects will hand down decisions to the team without consulting them at all. The most common reason for this is the schedule: for some reason, many people in that position feel that asking the developers for an opinion is just begging for a schedule delay. And this is not just a matter of heavy-handed micromanagement; in fact, often the opposite is true. If a project is being built, a senior manager, a stakeholder, or a user may actually avoid bringing up--or may even shoot down--a good idea, in order to keep from disturbing a project that seems to be making progress. Open discussion is squelched in the interest of time. Ironically, much of this discussion is actually a time-saver: the developers are almost certainly able to evaluate whether or not an idea is worth implementing more effectively than the manager is. But without an open forum and some encouragement to voice their opinions, the project team will miss this important chance to make the right decision--that is, until very late in the project, when it is much more expensive to make changes.
Trust the Team
Many corporate environments are dysfunctional because of the company hierarchy. For example, a vice president who is two levels above the development team leader can make sweeping changes to the project at any time, with or without support from the developers. When this happens, the team is forced to scramble to make the necessary changes to the code. And once a bad decision is made far above the team in the company, it has to be accepted as law--even if it causes rework, forces bad architecture decisions, or causes the entire project to grind to a halt.
As most experienced lead developers know, getting a senior executive to change his mind once a "final" decision has been made is often next to impossible. A programmer may be highly respected on the team, and may have gathered an enormous amount of evidence that a decision handed down from above will cause harm to both the project and the balance sheet. Yet when this evidence is presented, all it seems to do is threaten the executive's sense of hierarchy and consistency. In fact, it can often cause him to dig in his heels, and stick more resolutely to the bad decision. If you're a programmer in a large corporation, it's likely that you can think of several times in your career when you've had a good project cancelled because of a senior executive's whim. Or the opposite may be true--you may recall a project that clearly should have been terminated, but which was kept alive because it was somebody's pet project.
This would never happen on an open source project. And it's not because there is no hierarchy. As Karl Fogel points out in his excellent book, Producing Open Source Software (O'Reilly 2005), many successful open source projects are run by a maintainer he refers to as a "benevolent dictator." According to Fogel, in a project like this, "final decision-making authority rests with one person, who by virtue of personality and experience, is expected to use it wisely." As Fogel explains:
Being a BD requires a combination of traits. It needs, first of all, a well-honed sensitivity to one's own influence in the project, which in turn brings self-restraint. In the early stages of a discussion, one should not express opinions and conclusions with so much certainty that others feel like it's pointless to dissent. People must be free to air ideas, even stupid ideas. [emphasis ours] It is inevitable that the BD will post a stupid idea from time to time too, of course, and therefore the role also requires an ability to recognize and acknowledge when one has made a bad decision-though this is simply a trait that any good developer should have, especially if she stays with the project a long time. But the difference is that the BD can afford to slip from time to time without worrying about long-term damage to her credibility. Developers with less seniority may not feel so secure, so the BD should phrase critiques or contrary decisions with some sensitivity for how much weight her words carry, both technically and psychologically.