Comments (0)

By Krishna, March 8, 2010

Stephen Forte makes what he thinks is a case against having “rock-star” developers in a team. You can read the post, but, in short, there was a programmer “John” on his team who picked coding arguments with the rest of the team. The final straw was that John burnt the whole team by directly moving his changes to production without going through the QA process and bringing down the site.

Stephen’s example is not very strong. A great programmer, by definition, should be someone who also understands and advocates good build and deployment practices. John was not such a person. It is also quite possible that a lower-grade programmer could have made the same error if they were under pressure from some management big-shot. You have to blame the incentives here.

In any case, these kind of train wrecks are easily preventable. An analogous example is locking the door if you are in the bathroom. Yes, people should knock before they try to enter it. But you cannot force everyone to follow such “best practices”, especially what is foremost in their mind is not the prospect of causing embarrassment to another person. Instead, what you can do is prevent someone from causing damage if it is really important to you.

So with respect to production servers, the simplest solution is to lock down access and grant it only to people who have a stake in following the process. This small group usually includes the system administrator responsible for the box, the project manager (or team leader, as the case may be) and the QA manager. All others, especially programmers, are more motivated to say that the work is done than to prevent any damage because of a mistake.

I am actually not in favor of providing access to the lead programmer, either, even if they are very experienced. The path should go through QA, who test the build or patch on a Test server that is as similar to the production server in terms of capability, environment and data as possible. One QA person is in charge of delivery and they sign off on releasing the build.

In a smaller organization, there will some overlap between roles, but do ensure that the person in charge of QA has the responsibility and sole authority for releasing code to production. That person should be independent of any influence by managers to speed up delivery of projects before adequate testing is done.

The other step is to be absolutely uncompromising about crossing management lines. There has to be one person (whatever the title) who has the authority and responsibility for accepting tasks for the development team. I am using those 2 keywords again, but what it means that only one person can accept a new task from someone outside the team, and once they accept it, they are fully responsible for it. This person maintains the backlog and if any manager wants to circumvent the hierarchy and talk directly to a developer, they will own it including breaking the schedule of other managers, crashing the servers and so on. And also, perhaps most important to them, that the task would be dropped without notice once the backlog manager learns about it.

Now, Stephen defines a rock star developer as “someone who, while talented, thinks that they are the ultimate guru and that everything should be done their way.” As I see it, you have hired a manager when all you needed was a programmer who can follow instructions. There was already a manager (you!) on the team. John doesn’t belong. His personality is such that he should be leading the team and swimming or sinking with the decisions he makes. But he probably doesn’t have the necessary resume to land that role in any company yet. In the meantime, he is a nightmare on the team because he tries to manage his peers. That is the real problem.

The difficulty in avoiding such hires is that during the hiring process, the rock star developer is sometimes indistinguishable from the talented, easy-going developer. Both are bursting with energy and ideas, some of which are actually pretty good too. You only learn the full extent of their behavior after a few weeks. The easy-going developer is comfortable with accepting authority and there is a give-and-take with respect to ideas. The rock star developer doesn’t understand why compromises are sometimes necessary and is quick to condemn differences in opinion as stupidity or evil. We all do the same to some extent, but the rock star developer’s condition is almost pathological.

The obvious route is to let the developer go, but if you don’t have a choice (in the short term), then one way to handle them is to divert them into tasks that require heavy lifting in research and development. They are now isolated from the rest of the team and the day-to-day grind, but they are kept extremely busy because they have to deliver something that works. This is something that I suspect rock star developers like, because they get to play the full court from analysis to recommendation. However, ensure that you have set the right parameters for accepting the outcome of the research so that you don’t get a recommendation that you will be forced to reject, thus exacerbating the problem.

Comments (1)

By Krishna, November 26, 2009

From the Domain-Driven Design Site:

[A] great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems. Developers have cultivated their skills.

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.

Those of us with a software background have a tendency to get mired in the technical details of implementation. All of those discussions around the duct-tape programmers and unit tests and inversion of control. In some ways, it is a good debate to have. But they are just tools to do the actual work, which is to provide solutions to real-world problems.

And in the real world, there is enormous complexity. If you take a business application, there are so many rules and constraints demanded by various departments in the organization. Ignore software for a moment and think of any organization you have worked in. Remember the employee manual? That is just the start, isn’t it? There are so many other de-facto rules for inter-personal or inter-group coordination because of organizational history, etiquette, bureaucracy, etc.

Then there are outside rules by government and standards bodies, to name a couple. The sheer volume of these rules makes it very difficult for any one person to truly understand them all, let alone the inconsistencies and relationships between them. To make matters more complicated, these rules are changing always. Not everything all at once. But one rule here, one standard there – this month, that month. And your requirements keep shifting ground. There is never a fixed target.

That is the real reason why building software is complex. And it is not going to be solved simply by having a better tool or process which only help if you have somehow managed the complexity of the problem. Sometimes, the real-world complexity is, in fact, too difficult to manage. And the best you can do is take a small piece of the problem and try to solve it. Or maybe you can influence the real world to get rid of a business need like, say, end some silly bureaucratic process, and avoid the need to build a complex piece of software.

Comments (0)

By Krishna, November 23, 2009

Jurgen Appelo publishes a list of delegation checklist items from Johanna Rothman and Esther Derby

Is the risk factor of delegating this work adequately addressed? [...]
Do the people have the skills to do this particular kind of work?
Do the people have the right format for the work products to use?
Do the people have the tools necessary to be successful?
Do the people know what the results should look like?
Have you set the boundary conditions for the work (e.g. budget, time, resources, quality)? [...]

This is all very good, but it seems to be more plain-and-simple managing than delegating. Say you are a manager. You have a project with discrete tasks. You have people to do the tasks. You give them the tasks. The checklist above would be exactly the same.

Delegation is a little different. The tasks that you delegate are the ones that you are best able to handle, but assign to someone who is less capable. They may, in fact, have never done such a task before and so usually do not have the skills or knowledge to do them. So delegation is about teaching another person something new. Therefore, it has more risk than the typical task you assign to your team members.

In the short-term, delegation can be risky and it can result in work of low quality and other problems. In the long run, you will have more capable and well-rounded individuals in your team. So there has to be an element of leadership in delegation that looks at the big picture.

Comments (0)

By Krishna, September 15, 2009

I.M. Wright’s post on risk management is worth reading:

Software engineers do this all the time. They come up with a development schedule, unexpected issues come up, and they end up being late. Instead of informing their managers of the delay, they avoid facing conflict, rush the work, sacrifice quality, and slip the schedule, all with little control or visibility. It’s the opposite of what managers should want, yet those same managers insist on following the schedule precisely. Why? Because most managers and engineers don’t distinguish between the two types of scheduling—meeting a commitment and managing risk.

I did find the conclusions of the post a bit unsatisfactory because Wright wants to eat his cake and have it too. He wants developers to inform him about slips in schedule so that he can maintain his high-level commitments. The problem is that developers continue to be reminded about those commitments that they are afraid to reveal small slippages. It doesn’t matter whether the slippage is with low-level tasks only.

As I wrote about in a post about quality and deadlines, project timelines loom larger than quality problems. Time overruns are more visible and they are in the present. They are given great importance and most managers base productivity judgments on who meets their deadlines. If you insist on a deadline, you will frequently find developers working like crazy to meet them, regardless of whether they can actually meet it. Many feel that they are letting you down or that they are somehow incapable if they admit that they cannot meet the deadline.

So just insisting on getting updates is not going to do the trick. The project mentality has to change and for that, first, you have to trust and have to be able to trust your team and vice versa. When you trust your team, you know that schedule slippages are not the fault of the developer, but because of a genuine mistake in understanding the requirements or estimating them. When they trust you to be understanding, they will not fear you in bringing things to your notice, because they know that you will be working with them to resolve the slippage.

In this scenario, you will get to know of any minor slippages before they even happen. The developer knows when a task is getting more difficult for comfort. If you get jumpy each time you hear of schedule problems, the developer is going to keep mum and dig harder, sometimes to no avail. On the other hand, if they find you genuinely cooperative, they will tell you immediately and that gives you time to resolve your commitments sooner.

You have to make this explicit at the beginning. Explain to the developers that commitments can be negotiated if new information comes sooner than later. The farther the deadline, the easier it is to change them. Remember that estimates are, by definition, educated guesses only and there is no shame in changing them if facts determine otherwise.

And then, walk the talk. Your behavior (words and action) will determine whether the developers trust you enough to trust you with the truth.

Comments (0)

By Krishna, September 14, 2009

I understand what Glen Alleman is trying to do here when he insists that you can pick all three of time, budget and scope, but he totally misses the point:

Put these estimates into a schedule, sequence the work. See what you get. Don’t like the outcome? Adjust One, Two, or Three of the variables and repeat the process.

Repeat until all three variables balance – fit into the acceptable norms of acceptance.

The big problem is, as they say, when everything is a priority, nothing is a priority. When push comes to shove, as will in any project, what will you give up on? Are you ready to go past the previously agreed upon timelines? Are you willing to allocate more money? Are you going to scale down your requirements for the release?

For example, if it is an “Industry Conference” you need to release for, you cannot adjust time. If you are a startup, your money is probably fixed. If you are trying to overthrow an established software player, scope cannot be changed. The whole point about TBS is that something cannot be compromised (at least not readily) and you need to give up on the others.

Same goes for “time, cost and quality”. The biggest danger about compromising on all three parts of the equation is that you may end up with something that is of low quality at a price nobody is willing to pay released at a time when no one is interested in buying it.

Projects that do such compromises go on for way too long, have their most important features gutted (because they usually take more time) and cost more money anyway. It is like what Jack Welch used to say about budgets. There is a compromise between the person who asks for it and the person who grants it, but neither are happy at the end. The asker didn’t get enough to do the work and the granter feels that they paid more than they wanted.

Comments (0)

By Krishna, September 13, 2009

Stephan Schmidt explains how doing several projects in parallel is counter-productive because of the high overhead costs involved.

Projects must be tracked much longer, more documents are produced and must be tracked. All those status messages aggregate, flow upwards toward upper management, clog thinking and time. All those status messages flow to all stakeholders. Each increment per status update is small, much smaller than when working in serial mode.

Doing many projects in parallel creates a management problem, which is perhaps the most difficult one to solve. Every organization, in one form or other, has a pyramid structure with fewer managers compared to developers. When you have more projects going on, you are putting greater pressure on the managers who then become huge bottlenecks.

And that is the good news. Where things go completely off the rails is when the managers start making hasty decisions to ease the situation without putting enough effort. Most of those decisions come back to bite them in the most nasty way possible.

Practically, it may be difficult for a company to shun such parallel execution of projects. Opportunities have a habit of raining down on you instead of conveniently coming one after the other. And even if you are ready to reject and postpone some, there will be circumstances when you just have to take on work you hadn’t planned.

But there are ways to be prepared. One is to ensure that projects that are getting completed stay completed without your team being interrupted by customer service issues. This requires a greater focus on testing, user documentation and project hand-off to customers. Doing this for every project ensures that you will not have another parallel activity on your list.

Another step (as Schmidt showed) is to parallelize the tasks in your existing projects. Have milestones which are reasonably separated from each other and then ensure that you work hard to meet those milestones with proper quality. Also budget time for customers to do acceptance testing and provide feedback, which will introduce additional tasks in your projects.

A temptation with so many scheduled tasks is to get them finished sooner and get them off the list. But this can backfire if quality is compromised. Therefore, you must re-emphasize to the project teams that quality must be prioritized over deadlines at every step, because reduced quality will mean additional work.

Comments (0)

By Krishna, September 2, 2009

Suppose you are about to sign a contract with a company and you send the contract to your lawyer to see if everything is okay with it. You get a reply back saying that the contract is perfect and you don’t need to make any changes. You later get a bill for the time spent by the lawyer. What would be your reaction?

I have a feeling that you would be disappointed and perhaps a little upset at the lawyer, wondering why you would need to pay him if he couldn’t find anything wrong. It is unlikely that you would accept that the document was perfect. You may suspect that the lawyer was incompetent or that he was not totally honest about reviewing your document in detail.

Now, for a second, consider that the lawyer did do his job properly. Perhaps he had a checklist with 50 items that he compares every contract with. And for some reason, this particular contract passed every item on the checklist. And so he had no reason to object to the document. Apparently, the lawyer of the other company also knew his job properly and had prepared an even-handed contract.

With this knowledge, your anger may be a little assuaged, but you are still unconvinced. Surely nothing can be perfect in this world. Surely there should be some mistake, some loophole, some trap that the lawyer must be missed. You make a mental note to try some other lawyer the next time round.

Suppose that instead of having an “All’s Clear” reply, you had a different lawyer who sent you a list of 5 items that had to be fixed. Unknown to you, the lawyer approaches every contract with a question, “How do we bend this contract into my client’s favor, even if it is useless to him?” With experience, he can raise all kinds of “questions” within a couple of minutes and still bill you a considerable sum.

But what you don’t know doesn’t matter to you. You seem to have got some results for what you paid. Even though the first lawyer was actually more ethical, hard-working and diligent, in your perception, the second lawyer is much more productive and provides more value for money.

The moral of the story is that perceptions matter a lot more than you think. If you cannot demonstrate value for your work, people will question how much effort you are putting in, even if you are working hard and sincerely.

Output matters. If your output does not seem to match with the effort you say you are putting in, people will question your effort. This is one reason why code refactoring can be a challenge in some organizations, because the effects and benefits are difficult to understand and visualize.

Frequent deliverables and builds help. They show progress. They show activity. Functionality that may take a long time to achieve should be broken down into smaller, faster goals, even if the total time may be longer. This allows people to see achievements and keep the faith.

Comments (0)

By Krishna, August 30, 2009

The most important person in your professional life is the person who your manager is beholden to. In a large organization, it is simple to identify this person: it is your manager’s manager. In a smaller company, it could be a C-level person or a customer.

You see, the thing is that your manager is driven by two things: intrinsic motivation and external pressures. If your manager was only driven by internal impulses, your product would be driven by priorities that make sense: greater product quality, better work-life balance, consistent processes, calm work environment, etc.

But internal priorities are not the only thing in real life. There are budgets and timelines that must not be exceeded, people that must not be displeased, reports that must not be forgotten, bugs that must never be visible and so on. These are things that have a direct relationship to the stability of your manager’s job.

Managers insulate you from those external pressures, sometimes knowingly, but sometimes unknowingly because they are just focused on getting things done that they don’t have the time to explain to you what is going on in their world. But just because you don’t know about it doesn’t mean that you are not affected by it.

It makes sense for managers to share some of these pressures with their team members and for the latter to try to gain an understanding of what the manager is up against. This helps them work towards not only the real goals of the project, but also the goals as defined by other stakeholders that cannot be quite put on some project mission statement.

Comments (0)

By Krishna, July 9, 2009

A project operates most efficiently when the division of labor within the project is done effectively. In simple terms, this means

1. Every person works on tasks that will maximize the benefit to the team.
2. Even if they are good at other tasks, they focus on tasks that bring the greatest value.
3. They delegate those other tasks to people who could do them less expensively.

For example, even though the software architect in your company could be the best coder in the company, you don’t want her to sit all day long writing HTML code. Her talents are better used in design and architecture. So although there are several things she could do better than anyone else, she is used in the tasks that bring the greatest benefit to the organization.

Unfortunately, at an individual level, many miss this point. They spend their time being busy in tasks that could be easily delegated to someone else. Usually, the reason given is that they are the best at that particular task and/or if they give the task to others, it would not be done perfectly.

In reality, this results in a huge opportunity loss. By taking on such mundane tasks, the person is unable to spend time on more value-added jobs that has greater benefit to the project and organization.

Most people do this because they are scared of failure. What if the delegated-to person messes up the task? In my view, that is only a valid excuse if there is very little room for failure. For example, if you (as a manager) have to make a presentation to a big prospective client tomorrow, it is not a good idea to simply rely on a tester – you probably should do some smoke testing yourself.

On the other hand, in many situations, you have the ability to tolerate some failures and have time to train people. And that is where you should start delegating tasks. Yes, there will be mistakes, but you can point that out. If you have a person who has the ability to learn from their mistakes and follow processes, things will get better over time.

Comments (5)

By Krishna, July 7, 2009

In my previous post on software quality, I said that it was wrong to argue that quality lowers cost without talking about transition costs. There is also another dimension that we must consider, which is the calendar time taken for deliverables. In the long run, higher quality results in more deliverables or less development time or both. But in the short run, you will see deadline overruns and you have to be prepared for that.

Regardless of what is actually more important, time overruns are usually treated as a bigger problem than cost overruns. Missing deadlines is an immediate problem. It is in your face. It is very objective. In contrast, cost overruns require greater analysis and deviations can be smoothed over or explained away unless the variations are very large. So, meeting deadlines is usually treated as the most important objective for a team.

When you meet an immovable object, you have to give way. If deadlines cannot be changed or compromised, then something else will have to be gone instead. This should be best accomplished by reducing the feature set for the deadline release, but sometimes, at the individual level, quality takes a step back. Sometimes, the reduced quality may be imperceptible, but over time, it adds up to a poorer system that is less maintainable and less extensible.

If you want to fix this, it is necessary to change the emphasis from “meet the deadline” to “meet the quality standards“. First improve quality, and only then examine productivity issues. If you try to improve productivity first, quality may decrease and also reduce net productivity as the team is pulled into fixing quality problems.

But as I started saying, when you try to improve quality, you will initially see a reduction in productivity as the quality activities take more time. There might be refactoring that takes time away from new development. So here is where the project manager has to show leadership by avoiding compromises on quality while the clock keeps ticking. She may have to buy more time for the team to improve quality. It may be tough sometimes with external deadlines looming, but that is what is required for quality improvement.