Comments (0)

By Krishna, October 2, 2009

Hope you had the time to read through all the essays linked to in yesterday’s post about the reactions to Joel Spolsky’s article “The Duct-Tape Programmer”. Here is my take on it.

The use of the words “Duct-Tape” was only chosen by Joel as a flame bait, as he admits on his Twitter feed. Joel has a history of using colorful terms (like “architecture astronauts“) to represent concepts (and get reactions) and this was just one of them. People need to get over the post title and look at what he was trying to say.

What Joel intended to say (I presume) was, “Program with the tools and technologies you know instead of choosing exotic and less-understood technologies and methodologies“. That is a sane, non-controversial statement that you can apply to most software development, because it reduces the risk of failure by using unproven software components.

Joel is also right in pointing out that many programmers are afraid to say “No” to the latest stuff because they are “too afraid of looking stupid“. Programmers are proud people and they hate to admit that they don’t know something. They are also eager to try out new things. When you have a person in the team strongly advocating something new, they want to investigate it. That doesn’t necessarily mean it is going to fail, especially if the new technology is helpful. It is just that nobody knows any better until they try it.

But Joel is wrong in saying, “any kind of coding technique that’s even slightly complicated is going to doom your project“. That is too broad a statement and, taken at face value, it essentially justifies learning nothing new. Every new technique always comes with a learning curve that you have to get through to master it. The issue is: How much of a learning curve is it and what is the cost-benefit in terms of development speed?

For example, take a technology like ORM (object-relational mapping) or a better unit testing framework. You can build a perfectly working application without them and using your existing tools. And you could also build one using them, but let’s say you have to learn. You may be able to save time in the long run, but you have deadlines to meet. So what do you do? Well, if the deadlines are further off, you could make an effort to understand the technology and see if you are comfortable enough to use it. On the other hand, if your release dates are very close and non-negotiable, maybe you should try experimenting on another project. Maybe learn it in your spare time so that you are ready to use in your next project.

As for the reactions, on a second reading, I felt Uncle Bob’s take on it very even-handed. Cedric launched an unnecessary attack on Uncle Bob, but he had some other good points about Agile inflexibility (To self: future post perhaps). As for linking Joel with StackOverflow, Jeff Atwood, not Joel, deserves most of the credit. Also, don’t forget that StackOverflow used some of the latest technologies (ASP.NET MVC and Linq-to-SQL) that the developers were not familiar with when they started coding. Now, they did go past the initial deadlines that they had set, but despite great transparency about what they were doing, no competitor emerged.

Now, Joel’s post is surprising in the context of FogBugz. The thing is, FogBugz has been around for a long, long time (since 2001). But Joel continues to write “Shipping is a feature“, almost as if he is paranoid about some competitor of FogBugz. And he frequently writes about people who talk to him about some new stuff, with his description of the guy with the coffee mug in hand coming to his office sounding a bit too detailed to be fictitious. So is this some kind of internal FogCreek debate about the existing FogBugz design?

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 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 (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.