The build process was compile from your own machine and copy it the network, with any developer free to release any code they wanted. Which would sometimes step over the other developers uncommitted code.

We had two environment's

Development used by both developers and testing.

Production

Exceptions had no details or context to help track down problems.

We had a very small and painful bug tracking system.

We would commonly be related to #1 type model above.

Over the few years that I have been here we have made many changes.We now have:

We now have three people dedicated to QA. ( 7 Delphi Developers, 1 Database PL/SQL developer, and 1 Analyst)

We have end users still testing with the time that they have. But we now have better management support to get additional time needed.

We have a few automated tests, and a few more unit tests, but we really could use many more.

Our build process runs every hour through Final Builder, alerting us with email when someone checks in bad code.

We now have 4 environment's

Development (Dedicated to Developers only)

TEST where users get first look

QA a final look before production usually with data refreshed from production

We have a better bug tracking system, but still not nearly as nice as some of the home grown solutions I have used at past employers.

We are now some where between the #2 and #3 model's above.

Every release we ask what can we do better? We try to learn from our mistakes and implement solutions to prevent problems. We release a new version of our software nearly every month, so we are continually improving, and quality has improved in many ways in the past few years.

However, today I feel awful!

We put out a release on Friday morning last week. I don't think I have ever had a release go bad as this one has. Today we are still working on fixing major problems that were caused by the release.

Some of which would have been caught by better testing.

Some of which would have been caught by better management of the information coming in about problems. (i.e. it was reported but not acted on!) Since, I usually manage this information, it's the reason I feel awful.

Of course like all systems some of them would have taken an unreasonable amount of testing to find.

So I have been thinking, it's time to go back to and look at quality in new and different ways.

I have been making a list for a while that specific to our product on ways to improve quality. Several items on the list are general enough to share with others.

Build a health check system detects common/possible problems that can be run daily in each environment's, which is very database specific. We have scripts for all of these, but not an automated way to run them.

Tables without primary keys

Missing Synonyms

Invalid Synonyms

Tables without indexes

Missing Grants

Disabled Constraints in Oracle

Tables that have not been analyzed recently.

FK Constraints without index on child table (table level lock will be placed on the parent table if these are found)

Invalid Database Objects

Plus several that are specific to our schema, i.e. constraints that can't be described in meta data.

Under a multi-developers coding configuration:- review / update / improve corporate coding guidelines regularly.- avoid branching of code if it's not absolutely necessary.- comment "bugfixes" in the code twice: once in the unit header and once on place of the modifications. Form of comment should follow guidelines.- VCS check-in should always be labeled with bug (or enhancement) ID and short description.- review the specification twice before coding and always request detailed information if something is not 100% clear: wait for clearance! (Hmm... it's an obvious one ;).- PROHIBIT development of any new function 2 weeks at least before release deadline => avoid slipping deadline.- FREEZE bug fixing development, but for Prio 1 bugs.- Update your tools - hence update your knowhow about dev technology - reading blogs regularly helps out :)- Build the skills of the programmers up !

this list isn't exhaustive, though.

One important point I'd like to highlight is:Review / analyze the past development periods !

Using a ticket system (Tic@re, Bugzilla...) allows to statistically evaluate the way your code is produced.- how long does it take to fix how much bugs of prio 1, 2, 3?- which modules of the software are bug sensitive (business critical)?- which modules are razing most of the bugs?- how much bugs will be reported in the final phase before release?- ...and so on ...

e.g.: this kind of analysis could lead to the conclusion that one of the main module should be refactored from the scratch.

Loïs

p.s. :I used to work for an indian ISV 2 years long. The up to 20 developer teams there have a "twice-a-day 15 minutes long all together meeting in the corridor" session.And it was great !Information flow is really important!- point out "who needs help?".- sustain allegiance and kinship through "What are you doing in your cubicle all the day long?"- more efficient suggestion sharing.- communicate weak points and strengths....