Over the last few weeks I have been reading the book 'Rebel Code' by Glynn Moody. Basically its all about the open source movement & tells about the birth of Linux in detail. It is a good read that I would recommend to anyone interested in Open Source software. (im going to read Eric Raymond's 'The Cathederal & the Bazaar' next)

I have read a little about 'traditional' software engineering methodology from books like Sommerville on Software Engineering.

In reading Rebel Code, I got the impression that the pioneer coders like Mr Torvalds, Richard Stallman, Larry Wall & many others did not follow the traditional techniques of software design / developments. The image is created that they just sat at their keyboards for months on end 'hacking' out code!!

I guess this question is aimed at any programmer who has contributed (or contributes) to an open source project.

: do you follow traditional software engineering techniques e.g such as the 'waterfall model' or do you obtain the requirements / specification & design from someone else in the project & just concentrate on coding??
In a project where there are only a few people involved how is it possible to just concentrate on coding alone without any involvement in design decisions??

Thanks in advance

I would say it is about 50/50. Depends on how time critical the task is. I will also say it doesn't matter if the software is Open Source or not. When I sit down to do a project if I have plenty of time to finish it I will go through all the planning steps and try hard to build a well thought out product.

If I am rushed, it usually comes out with much more of a hacked look to it.

Personally, I feel like I should put more design work into my open source stuff because I don't want to release the source to the world and haver everyone think I am a terrible coder bceause it was hacked together as quickly as possible

In the projects I work on, Its more inclusive than you'd think.

When a major design decision is to be made, usually what happens is people discuss it, consider different solutions, even code up examples. Then whats decided is implemented. Whenever your working on some part of the project the design of that particular piece is usually left to you. ( Within the constrains of the overall project ).

Suggestions are usually considered from everyone, non-coding users, can be a big part of this as well ( wishlist items are considered carfully ). I've never worked on something where my ideas about design have not been considered. This is probably why OSS is very good at it. Theirs no manager to force a particular route. If you have real problems with the design, to where it becomes difficult for you to code, then you don't usually stay with that project.

When a project starts, the design and code is usually one person. If people like the design and can see possibilities than they join. If it started out bad, people won't code.

A lot of the code left dangling at places like freshmeat or sourceforge are what happens when design goes wrong, or the originator had an idea, but didn't code ( Which is annoyingly frequent ). people find a better design or a different project. Sure its wasteful, but I think thats why those that do survive are better. Its evolution in action.

QFT bang it together and get it out there The only bugs I really really thoroughly check in that situation is something that might lead to a system or application comprimise. There have been times when I've been given a fairly huge job and had 4 hours to do it.

": do you follow traditional software engineering techniques e.g such as the 'waterfall model' or do you obtain the requirements / specification & design from someone else in the project & just concentrate on coding??"

It's never up to you. Either you are in a company that requires you to use one method or another, or they throw stuff at you so fast you don't have time to eat lunch, let alone write a 500 page spec LMAO. When your marketing director is hammering your boss because you are losing 180k a month in missed opportunity because he needs x, y and z and you aren't done yet, start talking methodologies and your boss will set you up for a shrink appointment and tell you you need more sleep.

It really does depend on your situation. I worked for financial companies for 10 years and they did everything by the numbers. I left that world last year and work for software company now and I have yet to see a "spec" or "requirements" which was printed. Yea I am in heaven.

We use the "stream of consciousness" development methodology. It's awesome. Someone sees something they don't like? We change it. On the fly now done, checked into cvs. Big changes go to the "big list in the sky" which people work on when they get a fire up their ass to do something big. I guess it's the XP method. Rapid feedback change loop. We have a full time docs person that writes user docs and designs their experience in the portal. How she keeps up with us I'll never know but she's awesome. Again, I don't do that. People that do it well? You are gods and goddesses. When user requests slow down, we work on the big stuff and that's when the magic happens. Take care of users first, what you want second. Always remember that and you'll be a success story.

-Viz