Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Wed, Sep 26, 2007 14:03 EDT

|
Posted by: Esther Schindler in Best Practices Topic: DevelopmentBlog: You're the Boss
Current Rating: |
be. (I'm also sure that you're scribbling off an e-mail message to your application development managers to ask how quickly your shop's bugs are fixed.)
One difference between the results may be the survey respondent. The developers on the ground, writing the code, are likely to have different opinions than do their managers. For example, managers have a different idea of proper process (or, depending on viewpoint, CYA requirements); in the Forrester/BMC study, 45 percent of respondents required more than an hour to create a problem report. In the open-source community, a bug report could be a casual conversation in an IRC channel with the developer responsible for that code module.
Another issue is the granularity of what's considered a problem. Developers, by nature, think tactically and with great specificity ("the calendar doesn't display right in IE; the fields are overlaid instead of in an ordered list") compared to a manager's strategic viewpoint ("transaction speed slows down when the database has over 100,000 records") or the users' vague view when passed through a manager's translation mechanism ("Accounting says it doesn't work right; please fix").
Plus, one must consider the number of people and departments involved. In a typical enterprise environment, a developer who's trying to reproduce a bug might have to interview testers, users, vendors, developers. She might have to, oh dear, attend meetings at which bug fixes are prioritized and sometimes postponed until "the next round." Given that the EDC survey asked the developers themselves, the bug reporting and resolution process may be more streamlined. An open-source programmer who finds a limitation (such as the calendar not working right in some browsers) is often the person who fixes it; there's a lot to be said for personal power.
I find the whole thing absolutely fascinating. But then, I'm a fool for any kind of analysis of what developers are doing (when they aren't playing foosball or annoying spouses who slaved over a hot stove, that is). Another example, just in passing (and because it showed up in my inbox at the right moment) is the results shared by Sixth Sense Analytics, which aggregated and de-identified data about its user community. Says their site, "This data allows you to understand patterns and trends and serves as a representative basis for benchmarking your performance goals." Neat-o.
Do you see any other reasons for the variation in experience? What other lessons might developers and managers learn from these reports?
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?
What is the resource for bmc - forrester research?
Burcu