I'd disagree that there aren't "best practices". They may be very abstract, and it can be hard to determine whether a particular practice is "best" or not, but I think it's possible to contrast two practices and decide which is closer to "best".

For a few examples:
1. Separate presentation layer from processing layer whenever possible.
2. Isolate routines that retrieve data from external sources into separate modules, so that if either the data source changes, or if the processing layer changes, effects on the other side are minimized.
3. Document all functions, subroutines, variables, and constants.
4. Define variables and constants in a single location for consistency.

And so forth... these kinds of "best practices" transcend most languages and should make it easier for anyone coming behind to tell what's going on.

The problem, of course, is that these are low-visibility practices whose benefit is mostly "avoiding negatives"; that is, if it's done right, you won't see it at all, but if it's done wrong, here come the kludges. So the "payoff" is hard to document until long after the effort is made.

I'd be very interested to know if anyone has really found a way to be successful in large (say, the size of redesigning the transaction processing system at Citibank) software development projects. It seems like I never hear about one that has produced software with the desired functionality, on time, and within budget. Or is it just that those who succeed do so quietly, while failures tend to have public and expensive consequences?

If someone could develop a standard method for approaching these projects that produced successful results almost all the time, I've got to think that it would be the software engineering equivalent of finding the Holy Grail.

Kevin, I think your examples are excellent. I also think they support Bob's point that those who refer to "best practices,"...usually mean "basic professionalism" - the bare minimum that's to be expected to demonstrate simple competence.'

Isn't CMM supposed to be the holy grail of (software) project mgt ? Carnigie Melon's Capability Maturity Model - with various levels acknowleging the various needs for "micro-managment"

I'm speaking off the cuff, as I have not ever been involved in a CMM aware project. Closest I've come is Oracle CASE (designer) - Model based software generation - albiet not project mgt

I've found that when it comes to system design and implementation, success is the result of understanding what the end result needs to be rather than what business wants or expects. I realize a statement like this lends creedence to the Business vs. IT dilemma, but in our company that's just the way it is.

My group is proactive on systems integration and we achieve this by talking to our customers, finding out what they like and dislike about the current system. Based on the information provided, along with infrastructure capabilities and need for improvement (dollars earned or saved) we design and develop new software for our users.

For the most part this is done without the participation of management on either side other then to approve the project from the IT side. Many times, business management does not know new software is on the way. With this approach we don't have unrealistic requests and a minimum of red tape to deal with.

This autonomous approach allows those that use the software and the people that develop it to interact directly and the water stays clear. We have an overwhelming success rate with our implementations and an almost perfect internal customer satisfaction record. For systems that do not have a user interface, such as behind the scenes batch processing systems, we upgrade our own systems on our own schedule and keep things smoothe.