Dev Management

The election season puts me in mind of the many ways I have seen teams decide on which features to implement. Like all human endeavors this process is political, meaning that it is shaped by the relationships and power structure of the organization. Consequently, you can use various systems of government as metaphors for different approaches.

For the sake of this discussion, we’ll treat defects the same as features. This isn’t totally accurate since some defects simply must be fixed as soon as possible. However, most defects are subject to the same decision process as features.

The Dictatorship

With this system, a single, all-powerful voice decides what gets done when. This is a common approach on smaller projects, where these decisions are made by the project manager. That’s not to say that this person doesn’t listen to advice from others. But when it comes time to decide they, alone, make the call.

Ultimately, the other systems typically have a single person who has to make the final decision. In my opinion, this is an essential characteristic of an effective organization. Everything should funnel up to a single person authorized to make decisions. People at different levels should be empowered to make various decisions, but in the end a single person should have the final authority. Otherwise, you flounder endlessly when a consensus cannot be achieved. It becomes a dictatorship when the leader ignores the advice and guidance of others and acts strictly on their own belief.

This approach only appeals to me if I can be the dictator, using my sagely wisdom to guide the product direction. In truth, this system can work well if the person in charge has a keen sense of what it takes to succeed. From accounts I’ve read, this is not unlike Steve Jobs’ approach to new product development. Though you can argue with his approach, it’s hard to question the results.

The Oligarchy

In an oligarchy , power is shared by small, elite group. This approach is often used on larger projects where various constituencies are represented. You might have representatives from project management, sales, development, quality assurance, and product support. In some cases, actual customer representatives might be involved.

The group meets regularly to discuss what is needed and when. Tradeoffs are weighed between features needed to spur new sales and fixes needed to appease existing customers. Typically, the group is lead by someone with final decision authority, but most decisions have a strong consensus.

This approach is certainly more representative, but it is also much more time-consuming. I’ve worked on projects that used this method, but they were very large with complex interactions between subsystems. Still, a light-weight version of this can be helpful to make sure all factors are weighed effectively.

The Democracy

In its purest form, this approach relies on votes from the masses to make the selection. Sometimes, members of the development team do the voting. In other systems, the customers are allowed to vote.

Though I cannot find a reference to it anymore, I recall that Sun used Duke Dollars as a way for developers to vote for specific fixes in the early days of Java. I’ve worked on teams where each developer was given some number of votes that they could apply to the bugs or features of their choosing.

I’m not a big fan of this approach. When the developers do the voting, this tends to favor the interesting, glamorous features over those that are more mundane. Often, these mundane features make a bigger difference to the customers. When the customers vote, they are typically guided by their own way of working. An effective product has to balance the different ways customers will use it.

You could use a hybrid approach, where the developers or customers submit votes but the decisions is ultimately made by a small group or individual. The problem with this is that it can be demotivating to the voters. If a feature with a high number of votes is rejected, they will ask why they even bothered. So, if you use a voting system, you should be willing to act on the results.

The Meritocracy

In the meritocracy , the best idea wins. Instead of suggesting a feature or voting for it, each feature is submitted with a business case. The business case is used to decide which changes make the biggest difference to the product.

This is my preferred approach to prioritizing features. It allows for input from all stakeholders and provides a means to assess priorities. With this system, anyone can challenge a feature and have it replaced in the schedule by demonstrating that another feature has a better business case.

Unfortunately, it is not always evident which idea has the greatest merit. So, this system relies on approaches from the others to make that call. A team or individual weighs the various proposals and picks the ones that best meet the business needs.

This approach also avoids the “squeaky wheel gets the grease” syndrome. Often, it is the customer or developer who is most vocal that gets their way. Great ideas languish because the proponent is not willing or able to be heard above the din of the highly vocal.

Truthfully, there are very few pure examples of any form of government. Most are a combination of these approaches. The most important characteristics of a feature planning system are:

• The ability to gather ideas from all stakeholders.
• The willingness to listen to these ideas.
• A system to evaluate ideas on their true merit.
• A clear vision of the product that helps to determine which ideas truly enhance the product and which just muddy the waters.

Of course, it wouldn’t hurt if we could somehow take humans out of the equation and have features selected by a race of benevolent and powerful robots. But that’s a post for another time.

My last post, Design Fail Patterns, dealt with the ways that people often select the wrong technologies for a project. That made me think of another way I’ve seen projects and people fail.

Cast your mind back to the days of the tall ships, great wooden vessels that plied the oceans under wind power. Imagine one of those majestic ships sailing along when suddenly it hits a reef, tearing a large hole below the waterline. All hands scramble to save the ship. They bail and bail, but the ship continues to sink. As the ship sinks lower, they bail more furiously until finally the ship is lost. The survivors are washed ashore on a nearby island.

As they stare out at the masts of the ship, still visible above the waves, the Captain asks, “Why weren’t we able to plug the leak?”

One of the crew pipes up, “Captain, sir, we were too busy bailing to plug the leak.”

OK, this is a contrived example, and it’s very hard to believe that it could occur in real life. However, very similar situations frequently arise in software development.

Bad Codebase

The most typical way I’ve seen this occur is on projects where the early work has set us up for failure. The infrastructural code is so full of bugs or badly designed that it has become a stumbling block to get the rest of the system built. The team furiously pounds away at the code, driving toward a critical milestone fixing bugs as they can. But with every iteration, things take longer to do and the codebase gets harder to work with.

In this case, the leak is the poor codebase. The only way to plug the leak is to rewrite that part of the system. Often, the programming team is unable to recognize that this code is a lost cause, particularly if they participated in its development. More commonly, the programmers know that this code is the problem, but they can’t talk management into the schedule slip that is necessary to fix it. In the end, the project takes longer to complete than if we had stopped and rewritten the offending code.

Unfortunately, a leak in software is rarely as visible or as easy to appreciate as a gaping hole in a hull. However, the programmers’ work to patch the system instead of fixing it is just as futile as the sailors who just keep bailing. And the result is nearly as predictable.

Poor Process

Another way this phenomenon is manifested is in adherence to bad processes. I worked on a project that used very poor configuration management techniques. The approach to version control was sloppy, and there were no controls for how integration servers were configured or how code was deployed for testing. Consequently, even though we would get successful tests on the integration server, we continually faced problems in production. These problems stemmed from several causes. Sometimes it was because of files that were edited on the integration server and not checked into source control, so they never got deployed to production. Or someone would set up the directory structure differently so that it would work on one machine but not the other.

When these problems appeared, the proffered solution was that people should be more careful. This case might be slightly different. Instead of thinking that you’re too busy bailing to plug the leak; in this case you believe that bailing may be all that’s needed.

I’m a firm believer that your test machines should mirror your production environment in every way possible and that you should deploy your code for testing exactly as it will be deployed to the production environment. And if I ever catch someone editing a file on a test or integration server, I’ll keel haul them!

No Time for Personal Development

I also see the “too busy bailing” mentality at work in peoples’ careers. As a hiring manager, I have interviewed hundreds of candidates for jobs over the years. I’m frequently amazed to learn how little people invest in their careers and the knowledge necessary to advance.

For example, most of my work has been on Object-Oriented projects. So, I typically ask OO questions of the candidates. One question is about how they learned OO programming. What books did they read? How did they hone this knowledge? Typically, I find that most candidates learned OO in college and have done nothing to build on that knowledge, other than their normal work experience.

I’ve also interviewed candidates for web development. So, I’ll get a resume from a bright young college student who is about to graduate. They tell me they want to be a web developer.

“Great!” I say. “So, have you ever built a website?”

“No.”

“Do you know HTML and JavaScript?”

“We had that in a class once.”

“Well, then what have you done to become a web developer?”

“I’m real busy with class right now.”

So, basically, this guy is looking for someone to pay him to become a web developer. I’ll always consider a new grad without formal experience, but I want someone who has done more than just sit through classes on their way to a degree. Show me some passion or interest in your area by working on something outside of class. Or at least have knowledge in the basic tools.

Tool Selection

The final way I see people being too busy bailing is through adherence to less effective tools. I often interact with people who have been using vi their whole career, or some other minimal editor, and just can’t be bothered to change. No amount of telling them how you can save them time will convince them to switch. They may even admit that they know they could be more productive if they switched, but they don’t want to take the time to learn a new tool.

Truthfully, this could be a case of the tool becoming the job rather than being too busy bailing. In that situation, a person spends so much time, say, hammering that they lose sight of why they are hammering: to build houses. So when a new way of driving nails comes along, they stick to their current way of working. “I’ve been hammering for 20 years. I’m not about to switch.”

Switching tools will always involve an investment in time. But if you pick the right tool, that investment will pay off rapidly.

So watch for signs of bailing in your own work and career. Consider whether there is a leak that needs to be plugged first. If not, then bail for all your worth. If you have spotted a leak and no one will listen, maybe you need to do a different kind of bailing.

SlickEdit is switching over to a different bug tracking system, so I’ve got that topic much on my mind lately. It’s amazing how complex something so simple can be. I’ve never seen a group of developers larger than three agree on how to do it.

I like the generic term, “change request” for all changes in a system. But it’s very important to know whether it is a defect or a feature request. In my lexicon, a “defect” is something that doesn’t work as spec’ed; a feature request is a request to alter the intended behavior. Overall, I prefer the word “defect” to “bug”. “Bug” sounds kind of cute. “Defect” is a harsh, painful word, which is exactly what I want associated with any part of the product that doesn’t work properly.

Depending on who you are talking to, they either don’t care about this distinction or they care greatly.

Customers generally don’t really care which it is. They just want the behavior changed. To them, it is a defect as in “defective”, and they don’t care whether it was spec’ed wrong or implemented wrong—it’s just wrong and they want it changed. Am I any different about the products I use?

As a product manager, I care greatly about this distinction because they tend to address different groups. Defects are typically the chief cause for dissatisfaction with a given product. Generally, customers wouldn’t have bought the product if it didn’t have the features they wanted, but key defects are sometimes discovered only after you’ve purchased. Certainly, if you have many obvious defects they will prevent new customers from favorably evaluating your product. Further, defects in a program add to the burden of development, slowing work on related capabilities.

Feature requests add new capabilities to the system. Though these are beneficial to existing users, they primarily want the existing set of capabilities to work as well as possible. New features are a means to broaden the product’s appeal. They can also provide incentives for customers to upgrade or participate in maintenance programs that include free updates.

Developers are also passionate about this distinction, but for a different reason. For them, the concern seems to be that a defect is considered a personal affront to their ability. I’ve spent more time arguing with some developers whether a change request was a defect or a feature request than it would actually take them to fix the problem (though, not at SlickEdit, of course!)

Balancing priorities for defects versus feature requests is one of the most challenging tasks a product manager faces. There are different voices pulling you in different directions: sales, marketing, customers, and developers. All have different things they want to accomplish in the next release.

At SlickEdit, we try to strike a balance that gives as much as we can to each group. Each major release contains new features that we think can improve how you write code. We also try to knock out as many defects as we possibly can.

« Previous PageNext Page »