Slashdot Mirror
Open-Source Development 'Faster, Better, Cheaper'
David Hart writes "Faster, Better, Cheaper: Open-Source Practices May Help Improve Software Engineering --
Walt Scacchi of the University of California, Irvine, and his colleagues are conducting formal studies of the informal world of open-source software development, in which a distributed community of developers produces software source code that is freely available to share, study, modify and redistribute. They're finding that, in many ways, open-source development can be faster, better and cheaper than the 'textbook' software engineering often used in corporate settings."
These guys are trying to formalise open source development practices and write a new textbook for corporate software engineering. Here's the catch, open source development models work because they are informal, because their is no pressure other than that of your respected peers.
When they're done they may like to do a little research on 'irony'.
The (mid-level) programmer involved just added feature after feature, worked many long nights and weekends and ended up with an unmaintainable nightmare of custom software for the major customer.
I was asked to help with some new features, took one look, and said to myself "no way I'm working on this mess" and spent some time coming up with a more generalized architecture [1].
This time around, the first thing we did was get marketing requirements. We turned this into a functional spec, sent it out to marketing and project management to be reviewed. After that they are going to sign their goddamn names on the goddamn front page of the functional spec, and we're going to build it. If they say "but we need x", we (the engineers) can say "should have thought of that earlier, we can try to get it into the next release in two months [2].
I know it is kind of a CYA [3] approach, but a paper trail puts the pressure on marketing and product management to GET IT RIGHT.
So, sure, the scratch-my-itch[4] kind of development comes up with some very good stuff, but the old-fashoned waterfall (requirements-> design-> implement) keeps people honest (or at least points out what parts of the company need to do a better job).
One more (slightly unrelated) point. Get the GUI in front of marketing as quickly as you possibly can! Those guys can't think unless they have something to click.
-- ac at home
[1] I know it sounds vain. Actually, I'd worked on teams designing very similar systems twice before, so we'd thought out a lot of the details already, so it was easy to see the common vs app-specific parts.
[2] I realize that if a big customer wants feature X by next tuesday we'll have to do it, but it ends up being a failure of marketing and product management, not engineering. We're the heroes, not the villians.
Plus we've got a pretty good idea of how the customer is going to use the system (since we've got one version out there now), so the software will do a lot more than just what's in the functional spec.
[3] Cover your ass.
[4] In some part this project is one. After going through two design phases and having both projects cancelled, I really wanted to put the basic platform together and prove to myself it would work. (So far so good).
if you are a developer, you don't get paid.
Well, yes and no. I've worked on a number of open-source projects where I got paid. I'm doing this right now. The explanation is simple, and fairly typical in my experience.
What happened was that we needed something, and there was an open-source project that had already developed a good part of it. So we grabbed the source, did a bit of testing to find out what worked and what didn't, and started implementing the parts we needed that weren't there.
The GPL made it fairly easy to convince management that we had better give our improvements back to the open-source archive. But they didn't grumble too much about this. We would just point out that they had got a big portion of the software for free, and saved both money and time as a result. The only decent thing to do is to contribute our improvements, so we should do it even if we weren't bound by the GPL. And we are bound by the GPL, so we'd better give back our improvements. I don't recall any PHB really objecting to this.
The simplest argument to most management types is of the form "You're getting the work of N programmers, but you're only paying the salaries of M of them." And you're getting free testing of part of our product. You can occasionally reinforce management cooperation by casually mentioning "Hey, I just synced our changes to the FOO package, and found that someone else had just added the BAR portion that we were planning to do." This gives your management the warm, fuzzy feeling that they're getting something for nothing.
The only real problem is that you need to draw some fairly solid lines between the open-source portion of the code and the proprietary code that you're writing for the company. But in most cases, this is fairly straightforward. You just keep the source in separate directories, put your changes in the most appropriate place, and keep in touch with the rest of the open-source crowd to make sure that you're not starting a branch.
In many cases, of course, contributing to the open-source code wasn't in the original plan. The official plan was to just use a package from some archive. But sometimes we discover that the package doesn't quite do what we want. With open source, we can fix the problem. We give our fixes back, of course. Then we mention it to management, who invariably just shrug and go on with something more interesting. If there is any discussion, it can be cut short by saying something like "That package saved us several months of development time; spending a day fixing a problem and checking in the changes is a small price to pay for such a benefit."
Even the dumbest PHB can understand this.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.