Re: Process

[Owen Taylor <otaylor redhat com>]

Kyle Olsen <jedimstr gifttree com> writes:

> I've been developing intranet/internet applications for several
> years now, and I'm beginning to see this discussion follow an
> abysmal trend, and that is not following a development process.
> No, we should not be talking about languages, etc. yet. We shouldn't
> be talking about how to implement things, either - no talking of PHPLIB,
> SQL, Perl, Python, or whatever.
> 
> We aren't at that stage yet.
> 
> There is a well-defined process used throughout all kinds of development,
> and it works:
> 
> 1. Project specifications
> 	By this I mean define requirements. This is an iterative process, so
> 	you don't have to try to think of everything all at once.
> 2. Code design
> 	This is where you *design* the basic workings of the application.
> 	You still haven't decided upon a language/back-end yet. You're
> 	just deciding *how* it should work.
> 3. Prototyping
> 	The first hard part. :) Pick a small part of the project, and make it
> 	work. This stage of the process is, of course, the one where you
> 	decide what language, etc. you're going to use.
> 4. Test the prototype
> 	Make sure that things are going as you expect them to. Identify an
> 	irregularities or design flaws, and work them into the project
> 	specification.
> 5. Code, code, code
> 	Based on whatever prototype worked for you, code the project.
> 6. Initial Debug.
> 	This and step 5 are intimitely intertwined, and iterative steps.
> 7. Celebrate
> 	Yay! Now you've deployed your first usable version, and you move
> 	on to the last step, which is horribly iterative and exhausting and
> 	generally leaves you wondering why you ever started messing around
> 	with code in the first place....
> 8. Maintenance/Revision

To throw a contrasting argument into the mix, I believe that this is
false view. Succesful development is incremental and even anarchic. 

Yes, you need requirements, and design, and prototypes, and testing,
and debugging, but the process is not a linear progression from one to
the next, and you better have some idea whats going to happen down
the line or your design will be a failure.

I would strongly advise the web team to just dive in and start working
on all of these things at once, and not get caught up in debating
process.

Wait, I'm just doing that...

Anyways, talk is never wrong, unless it is not accompanied by actual
work. We just need somebody to start working on writing down the
goals and requirements as we go along.

                                        Owen