Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open-Source Development 'Faster, Better, Cheaper'

Posted by michael on from the plan-for-success dept.

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

2 of 150 comments (clear)

  1. Ironic by Anonymous Coward · · Score: 5, Interesting

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

  2. There are some reasons for formal processes... by Anonymous Coward · · Score: 5, Interesting
    We're working on a complete re-do of an existing product. The first version was nothing more than a gui demo, but marketing said "can you make it do this", and "can you add that", and so on.

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