Apply today for a FREE subscription to CIO Magazine!
Wed, Sep 26, 2007 14:03 EDT

|
Posted by: Esther Schindler in Best Practices Topic: Development Blog: You're the Boss
Current Rating: |
Programmer spouses get used to it. We call the developer to dinner. "I'll be downstairs in a minute," the programmer says. "I'm just fixing this one last bug." Dinner turns cold. So does the spouse.
Software development is far more than the process of designing great applications that give their users joy. It's more than writing elegant code that, to the trained eye, is a work of art. A huge amount of software development time is spent in testing for defects, and fixing the problems once they're found. Ideally, the bugs are found before the application gets out the door, but — as we all know too well — many are found only after the software is deployed. The users report the problems...
...and then they wait.
Or do they?
According to a survey commmissioned by BMC and conducted by the consulting division of Forrester Research, the average time to resolve an application problem is 6.9 days for enterprise developers and 6.7 days for software vendors. Ten percent of those problems take 10 days to solve, says the report. Developers spend just over an hour documenting the problem; and, if given that hour back, they'd use it to create enhancements to the application they are working on.
BMC wants you to conclude, somewhat unsurprisingly, that BMC Identify's AppSight problem resolution software can help developers see where problems lie (and thus spend the rest of their time fixing the problem, and annoying their spouses by not showing up for dinner). It's a reasonable conclusion (the product plug, I mean, not the dinner dispute), and I applaud any tool that helps developers find bugs, particularly if they're in an application I need to use. (BMC says it'll soon have a white paper available on the subject, in case you want their specifics.)
But there may be more to it than that, when contrasted with another user community: open source developers. For open-source developers, the time reported between bug reports and the community's response is far, far less.
In its survey, Forrester conducted phone interviews with 150 managers, directors, and vice presidents in charge of application development teams and organizations. They included 100-120 respondents from enterprises with at least 1,000 employees and 50 developers.
As it happens, Evans Data Corporation (EDC) just finished its twice-yearly report, resulting from a survey of several hundred open-source and Linux developers (with some managers, but primarily folks-who-code). The EDC numbers are somewhat different. The average time between discovery and solution of a serious bug, for 36 percent of open-source developers is under 8 hours. Hours. Not days. Not a week.
In the BMC/Forrester report, application development managers said 39 percent of bug fixes take under a day to address; maybe that's not too different on the surface. However, 57 percent of open-source developers say that bug fixes typically take more than two days.
Interesting contrast, huh?
I believe both reports, even though they appear to contradict one another slightly. I'm sure that it does take longer for enterprise developers to fix application software than it takes an open source project to address an issue. And the conclusion (however much my open-source friendly soul might like to say so) isn't "Obviously, open source is better," but rather is a function of the infrastructure: people and processes work differently depending on the environment. I suspect that each community can learn from one another here, though I haven't yet figured out what the lessons ought to
Having worked on both commercial and FOSS code, I agree with your points, but there are several other issues. At each step along the way, the commercial environment is more complicated.
Design: In a commercial environment, I am told what the program is to do. This requires someone to explain not only the general functionality, but also some level of detail. The more miscommunication, the more the program has to be modified along the way. And when programs are modified, there are often ripple effects. In my FOSS project, I knew what I wanted from the big picture down to several levels of detail, and was able to make it modular, knowing that even if I had to change some modules, they would still work with the rest.
Staffing: Every commercial program I have worked on has had some turnover, and in one case the lead designers left. When new people are hired, they are expected to hit the ground trotting. While everyone talks the talk of programming standards, new team members usually introduce different styles that can affect readability. In FOSS projects, team members tend to stay longer and new ones have usually already started looking at the code, so the coding style tends to be more consistent. Also, when you live with an app long enough, you begin to run it in your head. While this is true of commercial developers too, turnover means losing some team knowledge.
Honesty: When I talk to developers (both commercial and FOSS), most of them are totally honest about the limitations, flaws, and poor design choices in the code. But I actually had a marketer prevent me from fixing a bug in a commercial product because they thought they could use it to trick customers into buying an optional feature. Fortunately the next user of the product to experience the bug was our own company--and we had the optional feature running, so it didn't solve the problem--and I was able to go ahead and fix it. I have never found a FOSS project trying to cover up problems.
Intangibles: I work on my FOSS app at home, so if I wake up with a good idea, I can make some notes about it, and maybe even a little code, before breakfast. While it is possible to do this in some commercial environments, based on personal experience and talking to co-workers, I doubt that it happens much there. And if I need a break, I can play the piano for about 1/2 hour and come back with a clear mind. Also, I can expirement with ideas without someone pressuring me to meet some deadline. For example, I spent a week reworking my lock functions at least 4 times before I was satisfied with them.
Finally, there is the pride of ownership. While I am sure that most developers are professionals and act that way, many of us have been thru mergers and layoffs and know what our value to the company is, which puts a damper on the motivation to become totally engrossed in the product. On the other hand, I will always own my FOSS code, and I am ready to discuss it at any level of detail to anyone who will listen.
Later . . . Jim
RenaissanceCore IDS, check it out at:
http://sourceforge.net/projects/renaissancecore
Jimm's observations were cogent, but he underemphasized one of the most important reasons open-source programmers are productive and faster to fix bugs: no meetings.
Our teams are geographically dispersed. Our budgets are low or zero. There's nobody to make us go through the hideous, brain-cell-destroying swamp of petty politics and lethal boredom that is the typical corporate meeting. Meetings are more often rituals designed to establish or maintain authority hierarchies than they are
ways to actually make good design or implementation decisions.
The time an "enterprise" programmer would spend in that swamp, *we* actually get to spend thinking and coding. Loss of the extremely limited utility meetings have in making us aware of requirements is more than compensated for by direct communication with our users through means like bug and issue trackers.
And deadlines. Don't even get me *started* about the effect of deadlines on productivity...suffice it to say that there's empirical evidence that the 'aggressive' deadlines so beloved of managers actually make development take longer than a "wake me up when it's done" policy.
...though to be fair I did so in the context of priority-setting rather than the political process whereby every participant feels that he must "contribute" in order to mark territory. So I'm not actually disagreeing with you.
One could also make your point by saying that the FOSS apps grow and change as the need comes up. That is, nobody creates an old-style "let's write a full requirement document that takes every possibility into account, and design the app for every eventuality;" if you need the calendar to show colors in multiple colors, by golly you can just go ahead and add that functionality. I suppose the Agile community may see this as evidence that *their* baby is prettiest... more than something to do with open-source per se.
So let's take this back to the real world. What could enterprise developers (and their managers) learn from the FOSS community, as they build the software that keeps the company's lights turned on? Or are there things that the enterprise developers get right from which the FOSS community can learn?