Reliable Systems

That’s right - I set a schedule of publishing an article every Monday and Thursday around 1 AM. If I’m ahead in getting articles ready, I queue them up for the future. But the queue has been empty this week, so this article is late. Now, I’m a creative guy so I have all kinds of reasons excuses for why I didn’t have an article ready either Monday morning or yesterday morning, but that doesn’t change the fact that I didn’t have it ready, so there wasn’t one, so this article is late.

It’s easy to treat being late but with a good reason as being the same as being on time. But they aren’t - and you damage your reputation for reliability if you act like they are.

I used to have an employee that worked for me who couldn’t get to work on time. Now, we had flex time so the definition of “on time” was really broad, but one aspect of it was some rough degree of consistency: If you were going to come in around 9:00, let’s make it average within an hour of that over the course of a month. When he was late, he’d come into my office and I got treated to “Well, I wasn’t late - there was traffic on the Beltway” or “I wasn’t late - I had to take the children to day care because my wife’s car didn’t work this morning” or whatever.

The problem is that why he was late didn’t change that he was late. I’m a really empathetic guy: intent and context matter when you move from what happened to what are we going to do about it. I liked the guy, I wasn’t going to fire him or even do any official HR action because he couldn’t get in on time. I was much more concerned that he didn’t really take ownership of being late than anything else. After all:

• We live in a major metropolitan area. When is the beltway interstate not busy between 8 and 10 AM?
• There are other ways to get your kids to day care. They may not be cheap or reasonable, but they do exist.

The bottom line is that when he looked at what was happening in his life, he chose to be late rather than take another option that would have resulted in getting to work on time. The real problem was that he didn’t see it was really a choice; not that he was powerless in the face of the circumstances of his life but instead that he was choosing to be late. In fact, it may well have been the right choice - I certainly wouldn’t ask him to go to extraordinary or expensive lengths to avoid being late.

Own Your Results

Most software projects I’ve worked on have been late. In fact, I’d say nearly all if you pulled out the letter of the law - did we deliver every feature to every user on or before the delivery date. This is hardly news to anyone that works with software development projects: Most studies treat these projects as “on time” if they deliver 80% of the functionality within 80% of schedule or some other similar tolerance.

As IT professionals, we’ve so internalized that software projects run long, that it’s easy to not see all of the decisions that we made as a development team to be late. It’s a lot easier to assume that we are powerless in the face of the circumstances of our project. But we make choices all of the time that drive being late, and in many cases it may be that the alternative aren’t reasonable (they would be very costly, politically unacceptable, or business unacceptable) but they do exist, you are not powerless to the unpredictability of software. It starts with accepting the development schedule in the first place.

The next time you’re late with something - personally or professionally - find out how powerful it is to just say clearly and emphatically We Were Late, and then move quickly to what are we going to do about it. Arguing about what happened (whether you are or aren’t late) isn’t going to get you to a good answer about what to do about it. In the same message where you deliver that you’re late, make it clear what the impact to others is: What it means to the company, your customers, generally anyone that depends on you.

This may feel like professional suicide, but I’d offer up that the more your organization tends to eat those that admit their mistakes, the more powerful it is to take this approach. As a friend used to remind me, they can’t kill you, they can only fire you. Think about it: If they did, are they the organization you want to work for? Really?

Instead, you’re most likely to find that it defuses the situation: People are ready to confront you with all of the evidence of how late you are and what it means to them. If you’re on the same side of the conversation they are, how much energy can there be in the confrontation?

If you have the reputation as being the first to own up when you can’t do what you said you would, you will have a reputation for reliability even when you aren’t.

One of the first things I’m listening for when interviewing developers is for how they relate to problems with authoring code, namely how do they approach a defect. Depending on how much experience they have and how much they’ve thought about it, I’ve found developers go through three levels of Zen when considering problems:

It’s Not the Compiler

Similar to the classic discussion that Select isn’t Broken, every developer when first starting out runs into something they are just sure is the compiler’s fault. The code is right, the compiler just doesn’t agree. It may be tempting to even use #pragma or the equivalent in the language to get rid of the warning or error.

In the end, it isn’t the compiler, it’s your code. Try explaining carefully and thoroughly to another developer why the code is right and the compiler is wrong, and most of the time in the middle of your explanation it’ll hit you what the real problem is, and that the compiler was right (if perhaps obtuse in how it is reporting the problem). This is an excellent trick to breaking through cognitive bias: Explain to someone else exactly why the world is flat, and in so doing your mind will often make the creative or fresh jump to what the real problem is.

It’s In Your Code

It’s one thing to trust the compiler - compilers have generally matured over decades, and even newer languages like C# and Java have very low defect rates of compiling because even if the syntax is new, the basic lexical parsing is very close to C++ and the long standing family of engineering behind it.

If the compiler is the most trustworthy code, what’s the least trustworthy? The code you’re writing right now. Everything else is more tested and more reviewed. In general, the probability you’re going to run into a defect in an operating system library or framework is relatively low, low enough compared to the probability of defects in your own code as to be statistically insignificant.

Even in areas of high churn, like evolving web standards and CSS for Internet Explorer, if the output isn’t right the defect is virtually guaranteed to be in your code.

It Doesn’t Matter Where It Is - You Have To Fix It

The ultimate evolution of this thinking is practical: It doesn’t matter where the defect is, you have to fix it - and you have to fix it in your code (or at least code you control). In the end, you’re writing software to deliver features for someone, and you’re only successful if it works. They really aren’t going to care whether you can’t make headway because of a problem in your code, an underlying library, or the operating system: They all produce the same effective result of the feature not working. So in the end, it isn’t a question of who’s right but rather what you’re going to do to resolve it.

There is some danger in this last point. There is a fine line between pragmatically realizing you have to make it work one way or another and just hacking away at a problem you don’t understand under the assumption that you’ve found an underlying defect you need to work around. Before you assume this is the case, you should prove not just to your satisfaction you’ve found an honest defect in another library but seek some independent evidence of this: A knowledgebase article, defect report from the library owner, or at least corroboration of your peers is a good place to start. Developers that charge straight to attempting to work around a perceived defect in a library without verification are really back at the first level.

Listen To Where You Are

When I’m talking with developers, I can usually find out where they are by listening for key phrases, such as “it works on my box.” If you hear that and it’s offered in anything other than a sheepish or self deprecating tone, this developer probably has a way to go. Listen to your own language - what do you say when you run into something? If you find yourself getting into a cognitive bias death spiral, that’s the time to get up, take a break, and come back to it. Repeating my favorite trick: Go find a talented friend to explain just how right your thinking is. In my experience, that exercise invariably has me figure out where I’m off track even if the other party can’t follow what I’m saying.

Editors Note: Sometimes you let an article spend too long cooking before you publish it. Jeff Atwood came at this from a very similar angle on Coding Horror while this was in review. Check out his article as well.

As I work with different clients doing software development, I’ve been struck by how different the Project Managers are. From what I have seen, the people in the role of Project Manager tend to fit into one of three archetypes:

• Project Leaders: Command the technical respect of the development team and the business respect of the client. Generally could write the software if necessary, but it isn’t an appropriate use of their time. Nonetheless, they frequently review code and occasionally contribute something because they just can’t help themselves.
• Project Managers: Typically have experience in either the client’s business or general software development, but augment that with specific training in project management tools and principles. Don’t contribute or review code, but actively participate in functionality and technical discussions.
• Project Monitors: Are trained in project management tools and principles, possibly deeply up to and including being a Certified Project Management Professional®. Wouldn’t dream of contributing or reviewing code, can’t actively participate in technical discussions, and can only lightly participate in functional discussions.

Here’s the question: What type of project manager do you need to have the best outcome of a software development project? For the sake of discussion, let’s say the best outcome is the one that produces:

• The most capability, closest to schedule, with the fewest defects discovered in the first 90 days after release.
• The clearest understanding by the participants and internal observers of the status of development during the project.

The first item is the real challenge, because it revolves around the fundamental software development triangle of quality, functionality, and schedule/budget. The problem is that only one of them is really a variable - functionality. Few people will view a project as being successful if quality is significantly adjusted or if the project is late. An experienced team can optimize the effort put into quality assurance, but the largest swings in project effort come from dropping or changing functionality to either save time or eliminate defects. A feature not implemented is a feature that doesn’t have to be tested and proven.

Adjusting functionality to save time seems very simple on the surface - remove new features from the list and the development time that was estimated can be applied to other aspects of the project. The challenge is - how much time will you really get back if you drop a particular feature? Rarely are features so isolated that this is an easy question to confidently answer. Secondly, what is the probability the feature will stay dropped? What may not seem essential to the development team may be the cornerstone reason your sponsor is funding the project.

To make effective decisions about what features can be cut or reduced, you need to be able to:

1. Clearly understand the true incremental benefit in time and quality to the project of the change.
2. Clearly understand the ability of the project’s customer/stakeholders to accept the project as being successful even if that feature isn’t available.

This is parked squarely at the intersection of technical and business expertise. If you don’t know enough about the customer, the feature won’t stay cut - it’ll come back at the request of the people funding the project, and usually do so at a much less convenient time. If you don’t know enough technically, you will tend to over-credit the project schedule for each feature removed. Developers are optimists: They will tend to underestimate how much work it will take to deliver on features in the product, and overestimate the initial savings of removing a feature, particularly if it’s problematic to implement.

Pick Your Battles

Project Leaders - those that have the technical and business skill necessary to intuitively understand what it means to add or remove a feature - are most likely to produce the best outcome on a software development project. They still need to know the techniques and tools of project management - otherwise you won’t have the clarity around the project necessary for people to view it as being successful - but they need to come at it with their business and technical hats in equal measure.

Project leaders are in very short supply, so what projects need true project leaders and which can still be successful with project managers or even monitors? Think of the difference between flying a plane and driving a train. A train is on tracks - you only control one variable (speed). Planes have many more variables - not just traveling in three dimensions but also complexities of many more external interactions. A Project Monitor could drive a train. You need a Project Manager for plane, and your Project Leaders? They’re for the fighter jet on a combat mission.

Monitors can track what’s being done, Managers can contribute to how it’s being done, but a Leader understands deeply why it’s being done and can change up the game when needed to win.

Key Times To Pull Out the Big Guns

Projects that break new ground: When the team will need clear guidance on what’s crucial to deliver and what it means to deliver. A leader can achieve more than the others not just because of the other attributes already described but also because the team will accept tactical management better because of the leader’s technical credentials.

Teams with strong personality conflicts: In this scenario you need both peacemaker and mutual respect, so strong technical and business credentials are important to get each party to stop talking and start listening, then to carry through on the project together.

Projects with no obvious variables: While it’s somewhat of a hyperbole that a project can’t tolerate a change in schedule, quality, or functionality it does sometimes come to pass. In particular, some projects have hard deadlines that are externally imposed and are non-negotiable - like compliance with a government regulation or natural business cycle (the holiday season). These projects need to emphasize creativity in approach to achieve results within tight constraints.

Distributed project participation: When the project is very distributed or requires significant interdisciplinary involvement for success it requires a wider range of business and technical skills to bridge all of the small gaps between mindsets. This often requires a fine listening for what people are repeating back to detect deviations from course while they’re still small enough to fix.

What Are You Looking For?

When looking for new project “leaders”, most corporations emphasize project management skills and techniques - IPMA Level B, PMI Certification, and heavy experience with Microsoft Project or some enterprise project management software package. Not surprisingly, this tends to attract project monitors, not leaders. The next time you’re lucky enough to participate in the selection process of a project manager or leader in your company, think about the hard skills you can’t easily teach them first.