Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Workflow for Open Source Development

By Opium in Culture
Wed Sep 20, 2000 at 05:58:42 PM EST
Tags: Software (all tags)
Software

Currently being part of a open-source initiative that is funded by a commercial company, and having a long experience with previous companies and closed-source development as well as a long time follower of the Open-Source movement, I have come to the conclussion that the flaw that is keeping the Open-Source movement from truely conquering the world is: Workflow.

...
I know it is hard to accept not to delve into the coding pleasure itself immediately upon having an idea, but the overall process produces better software, and would mean that your piece of code would be better used and that the whole project will have more chances of coming to fruition... We all know those desolate, inactive regions of SourceForge where projects were abandoned to the wind.


I have been browsing SourceForge a lot lately, poking my head into the more active projects and seeing what's going on.

Currently being part of a open-source initiative that is funded by a commercial company, and having a long experience with previous companies and closed-source development as well as a long time follower of the Open-Source movement, I have come to the conclussion that the flaw that is keeping the Open-Source movement from truely conquering the world is: Workflow.

Thus, my suggestion is simple. Taking the base of such Open-Source repositories as SourceForge, there should be added workflow functionality. Let me elaborate:

A module owner should begin first by writing the SRS (Software Requirement Specification) and after peer-review by members of his module and/or by other module-owners he should proceed to devise the SDD (Software Definition Specification) and get it peer reviewed.
Then, he should devise a work-plan which also should be peer-reviewed and assign section of the work to members of the module (Some of these sections might be even spawned into mini-projects of their own, IMHO) and they should do the work.

After the initial coding is done, a code-review should be held on the code (not just by a module owner, but by any other participant as well) and comments collated and voted upon, then either the original coder, or someone else should submit patches to fix the code errors.

After the code is finalized, a testing-specification should be written for it, peer-reviewed and approved, and then carried out by any participants.
This, to many familiar with software development flow, is a standard work practice in any respectable software development company. And it should apply to open-source as well.

The mechanisms for the workflow should not be too difficult for such repositories as SourceForge to implement. The peer-review and project management might be more trouble to create, but will pay off eventually.

I know it is hard to accept not to delve into the coding pleasure itself immediately upon having an idea, but the overall process produces better software, and would mean that your piece of code would be better used and that the whole project will have more chances of coming to fruition... We all know those desolate, inactive regions of SourceForge where projects were abandoned to the wind.
It is also hard to accept that the coding practices employed by closed-source company could have any merit, but while the other flaws of closed-sourced software abound, I believe that work flow is not a flaw but a big plus.

I do not believe this is against the spirit of Open-Source, quite the contrary, I think that the spirit of Open-Source requires that such a processed work flow exists -- but of course in a democratic and truely free way. I think it is a Good Thing.

It also means that it will be easier to delve into other-people's-code (OPC) because you will be able to read the SRS and SDD and figure-out what-the-heck the coder was trying to do. And this way, even if the original contributors abandoned the project, it would be easier, by many magnitudes, to catch up and continue the work where they have left off.

I anxious to hear what the K5 community has to say about my observation and suggestion.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o open-sourc e initiative
o commercial company
o SourceForg e
o Also by Opium


Display: Sort:
Workflow for Open Source Development | 38 comments (35 topical, 3 editorial, 0 hidden)
It is done all the time, still doesnt work (2.44 / 9) (#2)
by maketo on Wed Sep 20, 2000 at 04:33:02 PM EST

What you describe is usually done in commercial projects, however does not guarantee success and often it does not lead to successful conclusion of a project. There are many more issues to deal with when trying to solve wicked problems, process is only one of them. There have been a lot successful free no-plan hacks and there have been a lot of unsuccessful planned-and-reviewed-to-death commercial projects.
agents, bugs, nanites....see the connection?
It's an issue of who does the planning/reviewing (2.00 / 4) (#8)
by marlowe on Wed Sep 20, 2000 at 06:20:42 PM EST

A PHB can screw anything up. But an attention to process will greatly increase the effectiveness of a team of people who are competent designers.


-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
[ Parent ]
Re: It is done all the time, still doesnt work (2.66 / 3) (#13)
by hoopy on Wed Sep 20, 2000 at 08:03:31 PM EST

Isn't your argument similar to the one that "Most people who die in car accidents have their safety belts still on, and plenty of people who don't wear seatbelts survive accidents"?

The idea of process is that when a development team exceeds about 3 or 4 full-time, serious contributors, things like interface specs and up-front design time really pay off.

-Hoopy

[ Parent ]

Re: It is done all the time, still doesnt work (1.50 / 2) (#25)
by maketo on Thu Sep 21, 2000 at 09:41:50 AM EST

My argument was only to show that there are many things to the success of a project, one of them beeing the process. I dont doubt the power of planning, but I also believe in prototyping. And that usually means coding right away ;)
agents, bugs, nanites....see the connection?
[ Parent ]
Prototyping (2.50 / 4) (#14)
by kraant on Wed Sep 20, 2000 at 08:11:30 PM EST

One interesting comment I noticed was that since the developer is the consumer they know what they want. That has a lot of implications as far as design go. Since you have a perfect knowledge of the desired product you can skip a lot of the attempts to find out what the "customer" wants.

What I have found very useful when trying to design a working program is prototyping. Now I'm not talking about the type of prototyping where someone hacks together a VB script and calls it a program. I'm more talking about making an attempt to write the code and then scrapping it and doing a total rewrite.

Just like being the "consumer" gives the developer a good idea of exactly what they want having some experience in creating it gives the developer a much better perspective on what to do and what not to do...

You can get your head around the concepts and abstractions a little better I guess...

So if you want to learn some basic concepts or work on some massive project (either your own or a pre-existing codebase) write a little prototype... It will give you some perspective on why things are/were done the way they are.
--
"kraant, open source guru" -- tumeric
Never In Our Names...
[ Parent ]

Why so much talk? (3.25 / 8) (#5)
by TheDude on Wed Sep 20, 2000 at 05:16:03 PM EST

I realize that planning is a good thing. I don't think that so much planning is necessary. It seems more like you're trying to make Open Source programming into the same type of bureaucracy as the rest of this country operates through. That, imo, is a bad idea.

Of course, if a developer plans how he's going to write the code, what it's going to do, how it's going to get done, etc., the program is probably going to be much better and cleaner than if the developer just gets an idea and starts writing code. However, I don't think that so much planning and talking must take place before the coding starts. I know peer-review is a good thing to have - it makes the code more useful to more people, but I don't think that it's necessary to do all this review before coding starts. Once the coding is started, people should be able to review what's being coded at the moment and suggest things to change/add/remove, but this should take place during the entire code-writing procedure, not all at the beginning.

I just think that Open Source coding is more effective if people get an idea, think about how they're going to implement it, and actually code while an evaluation of the coding is taking place. If everything is decided before coding starts, there's not as much freedom to add/remove components, change the purpose of the program, etc. This freedom to code what you want is why I really like Open Source programs. I just think it works much better to code and review at the same time. Just my 2c.

--
TheDude of Smokedot
Drug Info, Rights, Laws, and Discussion
Visit #smokedot on irc.smokedot.org

Re: Why so much talk? (2.66 / 3) (#7)
by billnapier on Wed Sep 20, 2000 at 05:54:40 PM EST

I partially disagree. While it is true that for a lot of large companies the bureaucracy one has to jump through to get things done can be daunting, it doesn't have to be so. And neither would design process for an open-source project.

I'm a big believer in doing a lot of design work up front, so the coding gets to be pretty simple. At my company, we spend most of our time in the design phase, so that when we get to writing some code, it is pretty much an exercise in changing pseudocode to C. Doing a lot of your design in pseudocode can speed things up because you can ignore a lot of things like perfect syntax, and other things that you will need to worry about when actually writing code.

I don't see why this model couldn't be extened to work for an open-source project. First, a developer would propose some work (which is basically putting together some requirements, though it doesn't have to be as formal). Then the developer would develop a detailed design that would almost perfectly spell out what they would do in the code phase. At this time, people can start reviewing the design, while at the same time the developer can start converting the design into code. If any design suggestions are made at this time, it should be relatively easy to change the design since there shouldn't have been a lot of code written yet.

For some projects, the design doesn't have to be as detailed, but would still allow for peer-review of the design, and will also give later developers on the project at least a head-start into figuring out how the code is structured.

But I could be wrong.

Bill

[ Parent ]
Re: Why so much talk? (2.50 / 2) (#19)
by TheDude on Wed Sep 20, 2000 at 10:37:36 PM EST

At my company, we spend most of our time in the design phase, so that when we get to writing some code, it is pretty much an exercise in changing pseudocode to C

Now that I can agree with. A long design phase is definitely a good thing. That way you don't have to completely rewrite your program later in order to change design issues or capabilities. This design phase would do much good if carried over to Open Source projects.

What I don't like is that if people get stuck forever in design mode, or get bogged down with too many details in design mode, they take way too long to actually start coding. They may never start. They won't get as large a user-base to help code, make patches, give ideas, early in the design process. I think that it's much better to be working on the design, planning the design, and writing the code at the same time. That way you can give the program a good design while modifying the actual program's code as many times as you want simultaneously.And you won't have to be awake for a week straight doing it all yourself.

--
TheDude of Smokedot
Drug Info, Rights, Laws, and Discussion
Visit #smokedot on irc.smokedot.org

[ Parent ]
The way its done... (2.50 / 6) (#6)
by smoog on Wed Sep 20, 2000 at 05:46:25 PM EST

I'd be inclined to believe that a lot of the more successful open source projects are started up by people with a fair amount of software development experience. They realise the importance of clarity in design, overall objectives, etc BUT they don't formalise the process as much as commerical projects.

I'd also raise issue with the statement that "workflow" produces better software, if this was the case we wouldn't see the deployment of so much badly designed software, such as Apache, Linux, Bind, etc. Yes, there is a lot of rubbish out there - but the gems are worth it.

Another reason not to have so much red-tape is that people write software because:
1. they're interested in the area
2. its fun
3. its a break from their job
4. there's an itch, they scratch it

With regards to Open Source "conquering the world", thats a weak statement - Open Source hasn't merely "conquered the world" - its created the world as we know it - its reinvented the world - its given us the Internet.

Hackers Don't Like To Work During Their Free Time. (3.57 / 7) (#9)
by Anonymous Hero on Wed Sep 20, 2000 at 06:26:46 PM EST

Having worked on a few group projects in my limited experience writing software it has come to my attention that a large majority of developers not only dislike proper software engineering procedure but are incapable of practising it due to lack of knowledge.

Now that said, this article seems to have been written by someone who hasn't yet figured out the what's and the why's of Open Source and for this I suggest reading Eric Raymond's The Cathedral and the Bazaar.

Unlike commercial software, Open Source software is conceived, designed and written by the consumer of the software. This means that it is overkill for a developer to write a Software Requirement Specification or a Software Definition Specification for software he/she intends to use. The purpose of an SRS or an SDS is primarily to facilate communication between the customer and the software developers, when the customer is the developer this point is moot.

For example, it is highly unlikely to the point of ridiculousness that if I want to write myself a webcrawler or some other application that simplifies a task for myself, that I'd write a Requirements document for myself. Open Source software is usually written by one or more hackers and satisfies an immediate need the hacker had. Releasing the source occurs later to enable people to share in the fruits of the hacker's labor and/or to stop people from reinventing the wheel.

Of course, it is understandable that a project that is being directed by a commercial entity wishes to take the professional approach to Open Sourcing their project but this should not be used as a means to cast aspersion on development projects that are merely the hobby horses of a bunch of hackers.

Re: Hackers Don't Like To Work During Their Free T (2.00 / 2) (#11)
by maketo on Wed Sep 20, 2000 at 07:58:48 PM EST

This leads one to a possible conclusion that many a (wanna-be) software author today only authors software to gain fame and glory (and probably) money/employment benefits. Hacking for hacking itself - is it still there?

We live in an environment burdened with success stories and cheap exposure to media for everyone only highlights these stories and makes many people question their capabilities and worthyness. Thus the urge to do something that everyone else will see. How did that one go - art for the art itself? ;(
agents, bugs, nanites....see the connection?
[ Parent ]
Re: Hackers Don't Like To Work During Their Free T (none / 0) (#35)
by Simon Kinahan on Fri Sep 22, 2000 at 11:56:11 AM EST

Its true that many existing projects are essentially just written to be used by the author's, and other technical people who can communicate informally, and more efficiently, without doucmentation.

However, if we want open source development to grow into the areas currently dominated by commercial entities, where the customer is usually a non-technical person, some greater degree of documentation and process would probably help. How formal this needs to be, I am not sure.

Simon

If you disagree, post, don't moderate
[ Parent ]
Hackers Don't Like To Work During Their Free Time. (2.00 / 6) (#10)
by Carnage4Life on Wed Sep 20, 2000 at 06:27:04 PM EST

Having worked on a few group projects in my limited experience writing software it has come to my attention that a large majority of developers not only dislike proper software engineering procedure but are incapable of practising it due to lack of knowledge.

Now that said, this article seems to have been written by someone who hasn't yet figured out the what's and the why's of Open Source and for this I suggest reading Eric Raymond's The Cathedral and the Bazaar.

Unlike commercial software, Open Source software is conceived, designed and written by the consumer of the software. This means that it is overkill for a developer to write a Software Requirement Specification or a Software Definition Specification for software he/she intends to use. The purpose of an SRS or an SDS is primarily to facilate communication between the customer and the software developers, when the customer is the developer this point is moot.

For example, it is highly unlikely to the point of ridiculousness that if I want to write myself a webcrawler or some other application that simplifies a task for myself, that I'd write a Requirements document for myself. Open Source software is usually written by one or more hackers and satisfies an immediate need the hacker had. Releasing the source occurs later to enable people to share in the fruits of the hacker's labor and/or to stop people from reinventing the wheel.

Of course, it is understandable that a project that is being directed by a commercial entity wishes to take the professional approach to Open Sourcing their project but this should not be used as a means to cast aspersion on development projects that are merely the hobby horses of a bunch of hackers.

Hmm... I agree with the post. (4.50 / 8) (#12)
by hoopy on Wed Sep 20, 2000 at 08:00:21 PM EST

I work for a software house now, and have done about a year of hardcore commercial coding. We were ten guys in an office, doing a startup, and this was my first commercial programming experience. I've done lots of coding in high school, and do stuff "for fun" now in my spare time, but I'd never really thought too much about requirements docs, high level and low level design, etc.

After a year of doing intense, serious coding with a group of other developers, I can't imagine how anything can effectively get done *without* project management. When I sit down to scratch my itches, I find myself thinking about design and features and modularity and such, even though the temptation to "just start coding" is so great.

I think one of the big reasons why OSS works so frequently without such a process is that effective project management is all about efficiency, with software quality and such being minor points. A piece of closed-source software with effective project management and proper process may get produced in only a month, whereas an OSS one (even with college-aged kids putting in tons of hours in their spare time) may take months and months. Most of the speedy development efforts are "headed up" by a few top-notch coders, with only minor contributions from other people. When you're the customer, and you don't have revenue riding on the successful release of a product, efficiency isn't such a big deal - an extra hour spent debugging some poorly designed interface doesn't affect if you can pay rent two months down the road.

The bottom line is that if you sit and think about what you're doing before you do it, chances are that there will be fewer bugs, the code will be easier to maintain and debug, and you drastically increase the ability of others to understand the code.

Whether or not OSS needs full-flegded UML and SDSs is a minor point. If it's a large project that wishes to be well-maintained, it will need a group of people just to manage things like release dates, features that make it, design reviews, etc. The misconception that the "Bazaar" model of development should ignore good process is like saying that a contract/freelance architect doesn't need blueprints.

It doesn't matter if you're building a cathedral or a shack. You need a plan, and, for large projects, that involves feature specs, design docs, and design reviews.

-Hoopy



Re: Hmm... I agree with the post. (3.83 / 6) (#18)
by mihalis on Wed Sep 20, 2000 at 10:09:16 PM EST

It doesn't matter if you're building a cathedral or a shack. You need a plan

But that's the whole point, if you're just building a shack you do NOT need a plan. You really can get together a pile of wood and nail and just start, and if you've got any talent or particularly if you've seen other shacks or built them yourself you will end up with some kind of shack. I know this because I've done it.

Now if the point was to get shelter, then perhaps the shack today is better than a small bit of cathedral next week. Especially since you can glean some general structural knowledge from it for a bigger more ambitious shack next week. Not to mention a quick shack on site allows you to keep your tools dry and have a cup of coffee in out of the rain. What that has to do with software is now beyond me.

Now if it also turns out that you weren't sure you needed a cathedral, well, you've saved yourself a lot of money.

Of course, if you really do need a cathedral, well yes, a design is good. I think that most successful cathedrals were built, however, using a lot of knowledge from a long history of previous less ambitious structures.
-- Chris Morgan <see em at mihalis dot net>
[ Parent ]

Re: Hmm... I agree with the post. (none / 0) (#34)
by Simon Kinahan on Fri Sep 22, 2000 at 11:45:18 AM EST

If you've seen shacks before, its true that you don't need a plan to build one. Thats because you have a kind of implicit plan in your head that says what a shack looks like. You can see this if you set out to build a shack with someone else: if you start building without discussing it, its possible one of will start on a frame structure, and the other will start on a structure with load bearing walls, and you'll end up with an unstable mess. Its necessary to agree what kind of shack you want before you start. You need a plan, even if its only to do something like the last shack you built.

The "real" purpose behind all the documentation thats produced in many commercial software projects is to ensure that all the people involved are working within the same conceptual framework, and have a common idea of how the end product will hang together. The software engineering disasters I've seen - and believe me I've seen a few - have all come about because this common understanding was lacking, either because the people involved never realised it was needed, or because they thought they had it, but their abstract ideas were never accurately reflected in the code, probably because they were never made sufficiently precise.

Of course, this is not the commonly accepted view of the purpose of documentation, and what I'm suggesting can be done with a much lighter process that many places have. See, for example, the ideas behind Extreme Programming. Many managers seem to regard documentation as a deliverable in its own right, that is set in stone early in the projects, and as an instrument of control that allows them to measure progress and performance. Developers working in this kind of environment spend a lot of time and effort finding ways to subvert the "process" and do their jobs properly, and its experience or rumours of this kind of thing that creates the ambient antipathy to documentation. To me, thats a testament to the tenacity and professionalism of developers in the face to bad management, but its also a testament to the importance of process: sometimes the best process is one that accepts that requirements and designs change and tries to track them, but that is still a process.

Within this framework, you can see why many open source projects get away with no official documentation. Often, they are doing things that have been done before, and these previous implementations serve as a reference when design questions come up, so explicit documentation is never needed. Similarly, unofficial documents, such as the archives of mailing lists, the logs of IRC sessions, or ad hoc documents addressing specific issues play the role perfectly well.

Simon

If you disagree, post, don't moderate
[ Parent ]
Re: Hmm... I agree with the post. (none / 0) (#38)
by mihalis on Mon Sep 25, 2000 at 11:10:36 PM EST

I like the ideas in Extreme Programming too.

My team works a bit like that actually, but with some notable exceptions.

We don't program in pairs, but who knows, once I get them to read it too perhaps they'll want to try it.

We do work on the pressing problems first, we deliver often, and we even refactor. If that sounds impressive, we have to refactor because the initial code base was a POS.

We don't do any documentation really, and we also don't have the kind of regression tests Kent Beck advocates, nevertheless I'm passing the book around and we're close enough in attitude that perhaps we could go for it full-bore on our next project. I'd certainly like to do away with the little isolated cubicles plan our furniture is currently arranged in.

One thing he sort of hints at is the need to give up trying to integrate certain types of personality into teams if they wont learn to behave (e.g. coding standards). I would LOVE to get that kind of choice...
-- Chris Morgan <see em at mihalis dot net>
[ Parent ]

Stemming problem? (3.83 / 6) (#15)
by Stargazer on Wed Sep 20, 2000 at 09:01:14 PM EST

While reading others' comments on this story, an idea came to my head that I'd like to see commented on.

I don't think it's a point of much debate to say that free software has issues with poor -- or, at least, inadequate -- documentation. Many projects -- especially the kind that you will find abundant on SourceForge -- are lucky to include the generic './configure && make && make install' README, with a small TODO and AUTHORS.

This is a problem in and of itself. I wonder, however, if it has any correlation to the lack of workflow described above. A project which lacks the most basic documentation is not going to have an effective workflow.

Perhaps this problem could be partially, if not fully, amended if people took their most basic documentation seriously. A thoroughly-developed and -explanatory README (or file to that effect) could aid developers in placing the direction of the software. A healthy TODO would serve as a road map for the most effective way to go in that direction, by explaining what changes the code needs to get there.

Some people seem like this suggestion is doomed to be a failure. I'm curious, however, to see if the solution is actually much simpler than that: better documentation overall.

-- Brett



Be grateful for what you have (1.00 / 1) (#28)
by marlowe on Thu Sep 21, 2000 at 12:56:32 PM EST

Most commercial products I've come aboard on don't have anything as tidy and reliable and ./configure or even make install. Build processes are an ad hoc mix of scripts and makefiles that don't manage dependencies properly and that frequently break.

Or even worse, there's some proprietary GUI-based thing that doesn't scale well or that's loaded with annoying little bugs. Such as Visual C++ or Tornado.

-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
[ Parent ]
I disagree... (4.25 / 12) (#16)
by XScott on Wed Sep 20, 2000 at 09:55:16 PM EST

I think there are a couple of problems with this suggestion. Some are social: People who write free software frequently do it for fun. Formal PRD (product requirements documents) and what not aren't fun at all. If I'm giving the world my free software, I'll do it my way. If I document the code (possible but not my top priority), I'll let you in on my thinking. If you don't like the result, you don't have to use it. I mean it was a gift in the first place, and you're welcome to improve it in your own way. Here's the source.

The bigger problem though is that I don't believe formal design helps that much. I've worked on problems that have been documented to death before any code got written. They had just as many bugs as the "Write a rapid prototype, and start from scratch" ones did. A better design usually resulted from fleshing out the issues with a prototype and making notes along the way. When you're beating through the problem, you keep in mind how to avoid that in the next (non-prototype) revision.

The piece of code that I've written which I'm most proud of started out as a quick hack to solve a problem. Several revisions later it was a very elegant algorithm (IMNSHO) built into a very useful library (also IMNSHO). I could never have designed it from day one to become what it did. I didn't even really understand the problem until I faced off with it in code.

Now with commercial development (especially at some of the startups I've worked for), there is a real problem with PHBs wanting to sell everything once you show them the prototype. Free software can avoid this problem though because there isn't likely to be a PHB screwing things up. I'll release it when it's ready. Go away marketing person.

Some problems really do require a formalization in the design process. You aren't going to get a good ACID database or a good SMP operating system without a lot of forethought. I certainly wouldn't launch a space shuttle with prototype code. The debugging process would cost lives. Most applications though would come about more quickly and more robustly with a prototype and rewrite model. Fortunately that's the more fun way to work on them too. It's only when management feels they aren't contributing enough that they introduce all this process into the problem.

Formal design docs are a distraction.

You bring up lots of other things though too. Code reviews are a good thing. I've never worked at a company that had the discipline to pull one off. Oh no, the schedule is slipping - Can the reviews. In an open source project though, the maintainers should be head code reviewers. Everyone else should feel free to be critical, and no one's egos should get too badly bruised. Aweful lot of "should"'s in this paragraph.

I guess if it's your project and you're maintaining it, go ahead and do what you think is best. You'll probably attract fewer contributors if you demand they follow a painful process (I can't bring myself to say "workflow" in a sentence). Remember also in those desolate, inactive regions of SourceForge are lots of projects that have plenty of documented ambition and absolutely no code. I guess that's the open source equivalent of corporate vaporware.

Deep down, I guess I believe the best software comes about when an Evil Genius Guru up in his tower gets things rolling then a bunch of people sign up to the philosophy and extend and debug the hell out of the initial creation. Good things like Linux, GCC, Perl, Python, (name your favorite open source project here) came about this way. I also think the best software stays alive when the Evil Genius Guru is prudently able to start from scratch once in a while. This as opposed to the more common reinvent the wheel every month strategy.


-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
Re: I disagree... (1.33 / 3) (#17)
by mihalis on Wed Sep 20, 2000 at 10:02:06 PM EST

Thanks, I really struggled to write a response to this, but we have yours instead, which is better anyway. My gist was like yours, but I kept feeling like inserting personal history in as a way of justifying my statements, but of course arguing from authority is the wrong way to go.

Cheers,

Chris Morgan
-- Chris Morgan <see em at mihalis dot net>
[ Parent ]

Are You Sure? (2.66 / 3) (#22)
by pwhysall on Thu Sep 21, 2000 at 03:16:35 AM EST

"Formal design docs are a distraction."

I disagree. When you have a system of any complexity at all, if you want it to work, then you're going to need designs and functional specifications. The reason for this is that as a system grows in size, comparing what it actually does and what it should be doing becomes very difficult if you don't have any specification to test against.

Testing is what separates good projects from bad projects. Testing is vital, because it's proper testing that finds bugs. And *proper* testing isn't really possible without a specification to test against.
--
Peter
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
CheeseBurgerBrown
[ Parent ]

Re: Are You Sure? (3.33 / 3) (#24)
by richieb on Thu Sep 21, 2000 at 08:18:50 AM EST

The problem with functional specs and requirements is that often they are not really known or understood at the time your start development. In fact, you can't really understand the problem deeply unless you implement at least one solution.

That's why Extreme Programming is such a nice approach. It gets you to working code ASAP, for the parts of the system that you know how they should work. Rather than spending 3 months trying to analyze and design the ultimate solution, you design and quickly code partial solutions (by quickly I mean two to three weeks) and then you can apply the experience gained for the rest of the problem.

Often you'll find that when users get their hands on the system they will discover that the "must have features" were not really that "must-have" or they will think of new things, that didn't occur to them before they started to use the system.

The other nice thing about XP is pair programming. Pair programming is instant code review...

...richie
It is a good day to code.
[ Parent ]

Unified Software Development Process (2.50 / 2) (#30)
by seamus on Thu Sep 21, 2000 at 02:11:29 PM EST

I'll start out by saying I've just skimmed through a co-workers book on Extreme Programming, so I really don't know *that* much about it...

Have you looked at the Unified Software Development Process? I think that it occupies a space somewhere between Extreme Programming and something quite a bit more traditional (for lack of a better word). It suggests a more "traditional" style of development: Requirements, Analysis, Design, Implementation, Test. But in a fast cyclical nature. That way you start with a functional core and build outwards. This is nice because you've got the ability to quickly prototype (and notice where things are potentially horribly wrong in your design), but you have enough formality to show a project's goals, status towards those goals, and definite plan to reach the goals. This is nice for large distributed projects, but not as pressing for a "scratch an itch"-type project.

Hum, I don't think I've given the best possible description of this process, but it's certainly worth a look. I believe that three of the "Gang of Four" came up with it, you can find a book on it under the title "The Unified Software Development Process", by Jacobson, Booch, and Rumbaugh. That back cover is horribly buzz-word filled, but it's an interesting read.

Also, I thought I'd interject (back to the original article) that there's no one fixed process that's "best". It seems that every project I've worked on ( as a commercial software "engineer" ) has had a different development process, tailored to fit its requirements. Code-and-fix is a great process for those quick hacks, it's not going to go away. And it's the right process for some projects. The same can be said for any other model and their respective "good" project types, so there's some danger in enforcing just one development process on all software projects.

Extreme programming seems to be a descendant of code-and-fix, with the addition of formality (the test-harness requirements). I'm curious, though, to see how well Extreme programming would do in regards to GUI development. At work we haven't found any good tools that can automate the testing of a GUI-based program... which kind of eliminates Extreme Programming from this set of problems -> the need to have incredibly solid tests indicates that you'd need a lot of trained monkeys clicking on windows in order to properly test the software.

Anecdotally: I worked on a truly horrendous project that was the result of changing requirements: The problem with functional specs and requirements is that often they are not really known or understood at the time your start development. A customer couldn't give us exact requirements, so we had to forcibly drag them out of him in a very formal process, to avoid a near-infinite development time frame. Once we had a nice formal design document, everything went together very quickly. Before the design document, chaos reigned. So there's a time and place for everthing. Knowing when to use a particular process is a very valuable skill.

[ Parent ]

Re: Unified Software Development Process (none / 0) (#36)
by ppanon on Sun Sep 24, 2000 at 02:54:34 PM EST

A minor quibble:
  • Jacobson, Booch, and Rumbaugh are the three Amigos, who co-developed UML.
  • Gamma, Helm, Johnson, and Vlissides are "The Gang of Four" who co-wrote Design Patterns, the book that popularized the concept of design patterns.

    [ Parent ]
  • Re: Unified Software Development Process (none / 0) (#37)
    by richieb on Mon Sep 25, 2000 at 10:16:24 PM EST

    A customer couldn't give us exact requirements, so we had to forcibly drag them out of him in a very formal process, to avoid a near-infinite development time frame. Once we had a nice formal design document, everything went together very quickly. Before the design document, chaos reigned. So there's a time and place for everthing. Knowing when to use a particular process is a very valuable skill.

    Extreme programming encourages a conversation between the developers and the customer throught the development of the product. If a customer thinks of some feature he'd like, he ask the developers how easy or hard and how costly it would be to develop. He can then decide whether to add it to the requirements or not.

    Conversation will be a lot more meaningful if there is a system that you can play with and try things out.

    Extreme programming also advocates putting the system into production as soon as possible. Being in production (the so called "maintanence mode") is the natural state for software systems. Development is the unusal state.

    ...richie
    It is a good day to code.
    [ Parent ]

    There are degrees of formality. (2.00 / 1) (#27)
    by marlowe on Thu Sep 21, 2000 at 12:49:35 PM EST

    And there's a tradeoff between time spent designing and time spent implementing.

    One size does not fit all.


    -- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
    [ Parent ]
    Re: Are You Sure? (3.50 / 2) (#31)
    by XScott on Thu Sep 21, 2000 at 04:36:47 PM EST

    Certainly you need a specification of some sort. You wanted the program to do something right? But how formal does that specification have to be? The fill in the forms and submit to a strict procedure style of specification is tedious, and I doubt the extra formality involved is of any use to anyone besides a paper pusher.

    Test cases make for much better testing than specifications. If there is a way to automate pumping a couple thousand test cases through your code you'll find all kinds of good bugs. (I was in just this position in writing a replacement for a legacy system. I had a full archive of all transmissions made with the old system and could use those to test my new one. That found a LOT of bugs quickly.) Adding the ability to script a system that otherwise doesn't need scripting might be justified for just this sort of bug finding. (It's tough to automate testing a GUI application without scripting of some sort.)

    How would you test with a specification? You can't feed the spec to the code to chew on. You're back to reviewing things by hand (ineffective since you wrote it by hand), or generating the test case that you really wanted in the first place.

    You mention that as the system grows in size that comparing what it is doing to what it should be doing becomes very difficult. True without a doubt. How does the formal spec solve this problem though? I'd guess that the problem of verifying correctness grows quadratically (exponentially?) with the size of the code. Breaking things into distinct modules and defining clean interfaces between the modules is the solution to this problem. That hardly require more than a well documented header file which got it's design on the white board though. The PRD or MRD or whatever is just to make management or marketing happy.


    Side note... After reading this thread, I finally broke down and bought the book on Extreme Programming last night. I don't have any strong opinions on it yet, but part of the reason I never bought it before is because the title is so silly. (The other reason is because computer books are so damned expensive. Even the thin ones.) The book looks interesting though, and I pretty much agree with the big bullets on the back cover.


    -- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
    [ Parent ]
    Re: Are You Sure? (1.50 / 2) (#33)
    by pwhysall on Thu Sep 21, 2000 at 07:08:56 PM EST

    It's hard to write good test cases without a spec.
    --
    Peter
    K5 Editors
    I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
    CheeseBurgerBrown
    [ Parent ]
    Good idea (maybe?) (2.25 / 4) (#20)
    by Dacta on Wed Sep 20, 2000 at 10:54:20 PM EST

    Some Free Software projects do have a project plan and formal design. For instance, most of the Apache projects have some degree of planning, even if they don't have the formal support software you are suggesting.

    The problem with all that software is that it presents a large barrier to entry. Sometimes it isn't just more fun to code, it really is easier.



    Some considerations (2.40 / 5) (#21)
    by khallow on Wed Sep 20, 2000 at 11:48:07 PM EST

    First, I think the process should depend a lot on the scale of the program. It may be quicker to code a small program and then bend it to fit a standard.

    A related problem is the issue of code reuse. I don't recall where this has been pointed out, but it is clear that too much open source code is duplicated. Project designers should consider whether their code should be packaged to allow reuse (e.g. as a library). What is good news is that most code is modularized so that makes code reuse possible. I think that enlightenment (and its libraries) on top of gnome on top of X window is a good example of code reuseability.

    Stating the obvious since 1969.

    Xtreme Programming (3.50 / 6) (#23)
    by ntagonist on Thu Sep 21, 2000 at 07:36:02 AM EST

    Funny that nobody mentioned it, but personally, I like the practises from "lightweight methodologies" such as Xtreme Programming way better than formal design and specification.

    In all the time I have been programming, I have seen people either always make extensive designs up front, or not designing at all and diving into the code straight away. I have done both but I found that if I did no design, my code became a mess, and if I did a lot of design, my code became a mess and the design sucked.

    So, realizing that I am unable to come up with good designs up front, I usually do a bit of design, write the code, change the design, refactor the code, and so on, until I'm finished, always taking little steps at a time. In the end, the design and the code don't look anything like the design and code I started with, but that's okay.

    A while back I found out about Xtreme Programming (XP), and realized that I had been following the same kind of practices for quite a while. I also learned a few new tricks, such as doing automated unit tests. While I don't like everything about it, Xtreme programming is like a middle ground between following no formal rules and following rigid bureaucratic procedures.

    So how does this apply to open source projects? I guess that depends on which practices you wish to integrate. For example, you could make a rule that submitters are only allowed to commit a piece of code if they have written a set of good test cases for it, and that they have run all unit tests to verify that their submission doesn't break anything.

    You could also use something similar to the basic XP planning mechanism, which is based on "user stories". Each story describes a feature and is awarded a difficulty rating by whoever is supposed to implement it, which determines how long it will take to build. Every iteration of the product (2 to 3 weeks in a commercial environment) you decide which stories to build. This becomes the specification for your product's next release.

    I hope this is clear since I tried to summarize about two hundred pages worth of text in just a few lines ;-)
    mp3.com/mothergoose

    Re: Xtreme Programming (2.00 / 2) (#26)
    by scottj on Thu Sep 21, 2000 at 11:54:58 AM EST

    I'd like to second the Extreme Programming suggestion with the caveat that you should be aware this is a lightweight methodology that arose from Smalltalk practioners. Several important aspects of programming are inseparable from the Smalltalk environment, and are not really considered in the Extreme Programming methodology. So mix it together with a healthy understanding of design patterns, application frameworks, and the GNU programming suite and you're on your way.

    [ Parent ]
    A couple of thoughts... (3.33 / 3) (#29)
    by S1mon_Jester on Thu Sep 21, 2000 at 02:07:07 PM EST

    First and foremost...the reason why those design docs are done in the first place is primarily to increase communication among the developers, testers, etc so everyone has a crystal clear idea of what the code is supposed to do, not to guarentee that the code is bug free. (It does help to resolve design bugs...but it's the clear communication and understanding of what the code is going to do that resolves those, not the design docs themselves).

    And, contrary to what you may believe, those design docs slow down production of code. It's okay, it's supposed to...businesses are correct that it costs them LOTS of money to test code that is not completely understood...the cost of slowing down is nothing compaired to the money they would be wasting if they were testing code they didn't understand completely.

    Now...back to your point. It's important to understand the function of the design docs (to increase communication) to determine if the Linux community has a problem (lack of communication) that this would address.

    In this area, I think your both right and wrong.

    Currently, on a project-by-project basis, a lack of communication does NOT exist (IMO). I can go to the VIM website and talk directly to the designers and ask any and all sorts of questions regarding the design of VIM. Furthermore, there is the multiple mailing lists, message boards, faqs and other stuff that these teams use to increase communication among their members. These teams do not have a lack of communication on what software is supposed to do. (In fact, they may suffer from too much communication.)

    But, I think your right in that a distribution, or Linux as a whole, lacks this level of communication. There isn't a standard ways of handling security (not enough are using Nobody), and a general consenses regarding even the use of the major directories under /. is still debated. (Not to mention libc5 vs. glibc and package managers and...)

    However, these areas are being addressed, abeit slowly, with the Linux Standard Base and LinuxDoc (sp?). So, even for these, the issue of communications is already being addressed, without the need of SDSs and SDDs.

    So...without a problem, the idea of using SDSs and SDDs kinda falls by the way side.

    Yes (2.00 / 3) (#32)
    by DJBongHit on Thu Sep 21, 2000 at 05:35:25 PM EST

    When I first wrote PowerShell, there was no planning whatsoever. So while the program works, the code base is such a hideous mess that just the thought of making a new version makes me cringe. I'm going to do a full rewrite soon with more planning and design, and it should be a lot nicer then.

    ~DJBongHit

    --
    GNU GPL: Free as in herpes.

    Workflow for Open Source Development | 38 comments (35 topical, 3 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!