Comments (0)

By Krishna, November 29, 2009

Anecdotes are dangerous. Scott Koon has one about fixing a doorknob, linking it to the now-infamous Spolksy duct-tape programmer post and writes:

Think about that the next time you reject a new programming tool because you think it might take too long to learn or it’s different. Instead of doing the hacky way you KNOW will work, check to see if there is a more elegant or permanent solution. Because if you aren’t careful, your cheap and easy workaround might end up sticking around in the project long enough for it to become a problem to you.

People keep missing the point. There is a situation where we have bad programmers who use whatever tools they know to get things done. Everything about that situation is wrong because you have bad code – lengthy, mangled, unmaintainable. There is no argument about what should be done to those developers.

The other situation (and what the real argument is about) is the case of an experienced developer who has been successful in the past and who would rather use what is working for them than use something they are unfamiliar with. Because the tool has been successful for them, they do not accept that it may become a problem in the future. An example could be as simple and recent as an ASP.NET developer choosing to continue with WebForms than use the (arguably better) MVC framework.

Choosing to dismiss an experienced developer’s older tool as a “cheap and easy workaround” is a misunderstanding of the situation. The old way of doing things may have been the gold standard a few years/months ago. The new tool may work better, but only for a person who has spent enough time learning it to master its nuances. And there may be many such new tools, each of them making extravagant promises. So we also have the problem of making the right choice.

In a sense, this is the classic Technology Adoption Lifecycle problem, having to do with how fast people accept new technologies.

Technology Adoption Lifecycle (CC Wikipedia)

This was for firms using a particular technology, but it could apply to programmers moving to new technologies. When do they think a particular technology is good enough for them? Or when the current technology is unsustainable for them?

Comments (1)

By Krishna, November 27, 2009

Brilliant post on testing by Michael Bolton (emphasis mine):

Bug Investigation and Reporting (time spent on tests that find bugs)Test Design and Execution (time spent on tests that don’t find bugs)

Module	Time spent on tests that find bugs	Time spent on tests that don’t find bugs	Total Tests
A	0 minutes (no bugs found)	90 minutes (45 tests)	45
B	10 minutes (1 test, 1 bug)	80 minutes (40 tests)	41
C	80 minutes (8 tests, 8 bugs)	10 minutes (5 tests)	13

[...]If we are being measured based on the number of bugs we find (exactly the sort of measurement that will be taken by managers who don’t understand testing), Team A makes us look awful—we’re not finding any bugs in their stuff. Meanwhile, Team C makes us look great in the eyes of management. We’re finding lots of bugs! That’s good! How could that be bad?

On the other hand, if we’re being measured based on the test coverage we obtain in a day (which is exactly the sort of measurement that will be taken by managers who count test cases; that is, managers who probably have an even more damaging model of testing than the managers in the last paragraph), Team C makes us look terrible. “You’re not getting enough done! You could have performed 45 test cases today on Module C, and you’ve only done 13!”

And yet, remember that in our scenario we started with the assumption that, no matter what the module, we always find a problem if there’s one there. That is, there’s no difference between the testers or the testing for each of the three modules; it’s solely the condition of the product that makes all the difference.

The obvious larger lesson here is that if you are going to use metrics, comparing numbers is not going to do anything. You have to be willing to spend the time to understand what is going on. Too often, managers use metrics as a club to hit employees on productivity, something that is enormously counter-productive. As employees find a way to make the metrics towards what the manager wants instead of the needs of the project.

This is also a case for collecting fewer metrics so that you can spend greater time analyzing them. For example, A looks pretty good on test coverage, but there might be the possibility that we haven’t written some necessary tests. Or now that we know C is pretty buggy, we may need to look at the development process – what stage these bugs are getting introduced and why?

In several recent posts, I have talked about the quality versus productivity issue in mature software organizations. Since deadlines loom larger, they are often given higher priority by developers and testers at the expense of quality. And so, managers have to make a special effort to emphasize quality and avoiding shortcuts. Creating productivity metrics swings the pendulum in the other direction. It introduces pressure to get more done instead of getting things done right. So instead, when you evaluate these kind of metrics, stop looking at “finding lots of bugs” or “getting enough done”, but instead at the direction the product quality is taking.

Comments (2)

By Krishna, October 1, 2009

The programming blogosphere exploded to Joel Spolsky’s controversial article “The Duct Tape Programmer” which, as Joel said on Twitter, was meant to provoke people:

Of course, nobody would read that or link to it. So I have to embellish. “Duct tape” instead of “simple, well-understood tools.”

I was planning to write on it, but couldn’t as I was suffering from an earache and unable to open the left side of my jaw. Anyway, let me temporarily link to some of the reactions online. Enjoy while I come back with a response if/when I recover.

• The original article, by Joel Spolsky
• Dare Obasanjo aka Carnage4Life
• Jamie Zawinski
• Uncle Bob (Robert Martin), of Object Mentor
• Cedric at Otaku
• Jeffrey Palermo
• Alan Skorkin
• Mark Needham
• Kirk Knoernschild
• Ian Cooper
• Michael C Neel
• Dhananjay Nene
• Jak Charlton
• Tim Barcz
• Ayende
• Lee Brandt
• Blog Coward (!)
• Russell Ball
• Peter Seibel
• Tim Bray
• Chuck Hoffman
• Scott Reynolds
• Discussions on Reddit and Hacker News

This is probably one of the best discussions (in recent times) about software quality versus delivery times.

If I missed anybody, please add a link in the comments.

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, August 26, 2009

Guy Kawasaki had a series of posts where he called out various types of people (venture capitalists, engineers, marketers, etc.) on untrue things that they are used to saying. There are situations when using a tough word is appropriate, but this is one case where Kawasaki is just wrong. Most people are truthful most of the time. Good business sense demands that you trust them, because if you are always watching out for lies from people, you are in deep trouble.

Now I understand the possible Digg-bait nature of the title. Also perhaps, one may give Kawasaki the benefit of the doubt in that he was talking about “white lies” and attributing incompetence rather than malevolence to each category of people. And that seems to be the case with the set of engineer lies, where Kawasaki says that he has a soft spot for engineers, but you shouldn’t really take them at their word.

I find the list a bit disturbing because it is a clear case of management divorced from what is happening in engineering. Every project requires good project management, otherwise it will only end in problem-hiding and finger-pointing. It is not about assigning a *project manager*, but whether the team has a grasp on the what, when and how of the project at all times.

Let’s take each of the points Kawasaki mentions (Do read the entire post so that you understand his argument):

1. We’re about to go into final testing: If this is a lie, it means that there was no project plan. It also means that there were no regular project releases so that incremental testing could be done and pertinent user feedback rolled back into the product.
2. Even my mother can use it: That is why you need testing by end users, as early in the project as possible. And it can be done on the cheap too.
3. Our beta sites really love the product: If this is a lie, you need to choose a better set of beta sites and people to test the product, and find a better way of getting honest feedback. Whether users will pay for the software is directly related to how much they love the product. How you make money off it is a question for the business owner and the marketing/sales folks, not the developer of your organization.
4. We’d save time if we’d just start the whole project over from scratch: This is probably true in some cases, but the most relevant point is that you have an engineer with the wrong skills. Usually, the engineer who said this does not have an idea of the technology, language or framework used and they express this sentiment because they would be more productive in their specialized environment. Spend time and money to find someone who has worked in the same environment. And if you find such a person and they still say the same thing, then your existing code base really sucks and you probably should start the whole project over from scratch.
5. This time we got it right: I am puzzled why Kawasaki thinks this is a problem. If this is a lie, you have serious trust issues with the engineer.
6. It works on my computer: OK, I grant this. I will probably write a longer post about this point, but it is a more complicated issue than it seems at first glance. The application probably works fine on more than “one computer in the world” and the developer is tired after being through many situations where the user has failed to follow some simple explicitly-stated instructions. One solution is to have customer support people field the calls from non-computer-savvy people first and let through only complex issues to developers.
7. We have great testers and a great bug-tracking system: I suppose this lie is coming from an engineer at a startup hyping stuff to an entrepreneur, because I cannot see that happening inside a company. I would hardly think that this is a common lie even in that situation, but Kawasaki should know better with his experience in dealing with startups. In any case, once again, you need to have testing early in the game, and by testers who are independent of the developers. I believe the technical term is “due diligence”.
8. I don’t know much about sales or marketing: I don’t know what point Kawasaki is trying to make here, but why would you care whether your engineer thinks sales and marketing are easy? I see jokes all the time about programmers and managers, but that doesn’t prevent them from doing their jobs.
9. What I’m doing is scalable: If the engineer is clearly junior and incompetent to answer this question, why was it asked in the first place?
10. This will take five minutes to fix: I grant this too. But this will only be a problem if you don’t have a good testing regiment. If you have frequent builds and you have a well-defined build-test-release cycle, you won’t get this answer.

Most of these “lies” seem to stem from lack of proper testing. If you release frequently and have independent testers, things will usually not get to the stage where management loses trust in the engineers. On the contrary, it will build confidence as new features are rolled out and the system becomes more stable as bugs are fixed. A regularly updated plan would also be good.

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.

Comments (1)

By Krishna, July 2, 2009

There is an argument, which I am very sympathetic to, that quality lowers cost and increases the speed of software development. Unfortunately, quite often, the proponents of this argument miss out a phrase, “in the long run“. And because they do not tell the whole truth, it avoids dealing with real business concerns. It is dangerous because it leads to throwing out the baby (quality) with the babywater (higher initial costs).

The cause, I think, is that people confuses higher quality now with the transition from low quality to high quality. When your software development team is already working at a high level of quality, you are already saving time and money by avoiding rework and having to fix costly bugs. Maintenance is easier. Adding new features is done faster. So things are good.

But when you are trying to move from your present quality level to a higher quality level, there will be transition costs. This includes the time and money spent on quality personnel, training, new processes, documentation, piloting and so on. And even the best of transitions will involve irrecoverable losses because of mistakes made during piloting and tailoring the new quality processes.

As an organization, you need to budget for these transition costs and have an understanding (formal or informal) about the return on investment, i.e., how long will it take for these quality initiatives to start paying for themselves. Such an exercise can also help you accelerate the launch of the quality initiatives that can offer the fastest bang-for-the buck. For example, while both are important, code reviews have quick returns while automated testing has a more gradual return on investment.

So the real argument is, “Improving quality will cost you in time, effort and money, but it is an investment for the future with some immediate, but other long-term benefits. And here is how and when it will pay off.” That is much more meaningful and truthful. And it has a much greater chance of being accepted by a business manager.