> However if you're likely to have millions of people depending on your code, which will
> alwso be modified by other people, then you had better have a good process as well.
A good process means nothing. Understanding why a process wants you to do something
is what's important. Checklists are bad. Making sure the right things get done is what
is important. Writing a test plan isn't important. Making sure you have good test coverage
is important.
I have been writing code professionally for over 20 years now. I have been at a handful of
different companies, and gone through a few handfuls of various processes (2167a was
the first one I had to use coming out of school). I've worked on very large projects and
very small projects.
For small to the small side of medium projects, it comes down to the people
working on the project, period.... In my experience, a standardized process doesn't
effect the success of a project either way. If you have a good project lead, and good people,
you will have a "process" or a somewhat standard way to do things. It doesn't have
to be documented in a formal document. But it will be there even if you don't realize it.
Large projects are a mess. You need a standardize process as painful as it is. One that
allows you to integrate early and often. The first thing you need to realize that the % of
incompetence rises the larger the project. It's easier to hide in a large project. It's easy to
hide in a process that generates a lot of information. You have to identify problem areas
in interfaces, and people, early and often..