Section 1.1. Tell Everyone the Truth All the Time

1.1. Tell Everyone the Truth All the Time

The most important principle in this book is transparency . A project manager constantly makes decisions about the project. If those decisions are based on real information that's gathered by the team and trusted by management, that's the most likely way to make sure the project succeeds. Creating a transparent environment means making all of that information public and explaining the rationale behind your decisions. No software project goes exactly as planned; the only way to deal with obstacles is by sharing the true nature of each problem with everyone involved in the project and by allowing the best solution to come from the most qualified people.

But while anyone would agree with this in principle, it's much harder to keep yourself and your project honest in practice. Say you're a project manager, and your project is running late. What do you do if your bossmuch to your surpriseannounces to the world that your project will be done on time? Unfortunately, when faced with this situation, most project managers try to change reality rather than deal with the truth. It's not hard to see why that approach is appealing. Most people in software engineering are very positive, and it's not hard to convince them that an unrealistic deadline is just another technical challenge to be met. But the passage of time is not a technical challenge, and if the expectations are unrealistic, then even the most talented team will fail to meet them. The only real solution to this problem is to be open and honest about the real status of the projectand that's going make your boss unhappy.

And so, instead of telling the truth, many project managers faced with a deadline that's clearly unrealistic will put pressure on their team to work late and make up the time. They silently trim the scope, gut quality tasks, start eliminating reviews, inspections, and pretty much any documentation, and just stop updating the schedule entirely. And, above all, they wait until the very last minute to tell everyone that the project is late.., hoping against hope that luck, long hours, and a whole lot of coffee will correct the situation.

And sometimes it works... sort of, until the users have to work around bugs or missing features, until programmers have to start patching the software, and until managers have to go on a charm offensive in order to smooth over rough relations among everyone involved. Even if the deadline was met, the software was clearly not really ready for release. (And that's assuming the team even managed to squeeze it out on time!)

That's why the most important part of building better software is establishing transparency. It's about making sure that, from the very beginning of the project, everyone agrees on what needs to be built, how long it will take to build it, what steps will be taken in order to complete the project, and how they will know that it's been done properly. Every tool, technique, and practice in this book is based on the principles of freely sharing information and keeping the entire project team "in the loop" on every important decision.