[Dev] Re: Fwd: [Process] Core team process

[John Anderson]

Hi Michael:

I'm struggling with an answer to this questions. For me it's not as 
simple as do we do UML/USDP, Extreme Programming, or some other 
programming "philosophy".

UML -- yes in small doses, but not the whole enchilada.
Extreme Programming -- yes, but no two people entirely agree about what 
it means.

I'm pretty passionate about how to develop software -- as an industry 
we've got a long way to go. Off the top of my head, here's a quick 
partial list of things that I think are important:

Continuous releases and daily builds
Rather than put a bug in the bug database, first try to fix it. Don't 
code first and ask QA to find bugs.
The engineer who wrote the code is mostly responsible for QA.
No code is finished until the unit test is finished.
Good design results from getting something going quickly, followed by 
lots of quick iteration.
The best architectures evolve for a long time.
Code reviews are a regular part of development.
Difficult parts of code are best done by a team of two people working 
closely together.
If you see a new bug while doing something else, drop everything and 
jump on the chance to fix it. It just make your life easier down the road.
It is possible to eliminate all bugs from many subsystems and you should 
use techniques that make it possible, like monte carlo simulations and 
exhaustive checking code whenever possible.
Complexity is your enemy -- the sooner you learn the smell of too much 
complexity, the better.
Simplicity is your friend. Don't fall for a really cool fancy algorithm 
unless you know you need it.
Buzzword technologies often become religious. The only thing you should 
be religious about is happy customers and they don't care about buzzwords.
Don't build elaborate systems unless you know you need them.
Research existing open source project to make sure the code you need 
isn't already available.
Never write a slow program.
By the time your project is finished your competitor's project will be 
way better than you think.
Price is only one feature of software. It's often not the most important.
 From the user's perspective, simple things should be simple and complex 
things should be possible.
Automate releases.
Use source level debuggers.
Use IDEs
Don't write makefiles unless you have too.
Measure then optimize.
Always spend at least 10% of your time learning new things.
Use multiple languages, programming environments, operating systems and 
programming methodologies until you are comfortable with them and learn 
to appreciate the benefits of different approaches.
Use the best tools, even if they are expensive.
Optimize variable names for maximum clarity, not minimum typing.
It's OK to make mistakes. The only thing that isn't OK is to not learn 
from them.
Don't leave code commented out unless it's clearly explained.
Approach each piece of code you write like it's final finished code. 
Don't leave loose ends to clean up later because you'll never have time 
to clean them up.
Never code an algorithm that you know won't work in the final product 
either because it won't scale, run fast enough, or will have a rare 
failure case.
All successful products have a life longer than you can conceive. Files 
and processors will grow by factors of 10,000 -- make sure your design 
can accommodate change.
Don't code the first algorithm that comes to mind. Try to examine all 
possible approaches and choose the best. Get someone to review your 
approach before coding.
Don't put band aids on bad code, rewrite it. At first is seems hard, but 
after you've done it awhile you'll find successive rewrites go much 
faster than you thought.
When you work on someone else's code, don't leave it in worse shape than 
it came to you. Ask the original author to review your change.
No bug is impossible to fix.
Get to be good friends with a programmer, designer, or writer who's 
better than you.

I could go on a lot longer, but I'm getting way too carried away. I hope 
you see it's not as simple as UML or extreme programming.

John Anderson

Mitch Kapor wrote:

> Can you give me a short answer to this?
>
>> From: "Michael R. Bernstein" <webmaven at lvcm.com>
>> To: OSAF Process <process at osafoundation.org>
>> X-Mailer: Ximian Evolution 1.0.8
>> Subject: [Process] Core team process
>> Sender: process-admin at osafoundation.org
>> X-BeenThere: process at osafoundation.org
>> X-Mailman-Version: 2.0.13
>> List-Help: <mailto:process-request at osafoundation.org?subject=help>
>> List-Post: <mailto:process at osafoundation.org>
>> List-Subscribe: 
>> <http://lists.osafoundation.org/mailman/listinfo/process>,
>>         <mailto:process-request at osafoundation.org?subject=subscribe>
>> List-Id: Process Discussions <process.osafoundation.org>
>> List-Unsubscribe: 
>> <http://lists.osafoundation.org/mailman/listinfo/process>,
>>         <mailto:process-request at osafoundation.org?subject=unsubscribe>
>> List-Archive: <http://lists.osafoundation.org/pipermail/process/>
>> Date: 08 Nov 2002 11:44:37 -0800
>>
>> One of the things I'm curious about (and which will affect how the
>> community interacts with the core team) is what process does the core
>> etam ascribe to and practice?
>>
>> Is it UML/USDP? Extreme Programming? Something else?
>>
>> Cheers,
>>
>> Michael Bernstein.
>>
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Process" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/process
>