Alleged AntiPatterns

AntiPatterns is a great book that describes a number of development techniques that are known to be counterproductive, and yet are very commonly utilized in practice. The book claims to be about software development, but I think that 90% of the AntiPatterns it documents are common, and equally counterproductive, in the VLSI field as well.

This page lists a number of additional practices that are alleged to be AntiPatterns. Someday I might muster the energy to actually document them as such. (Since one of the criteria for AntiPattern-ness is that there are at least three known instances, please send me an email if you can help me substantiate any of them.)

Object-Oriented AntiPatterns

1. Failure to analyze
2. Failure to design
3. Designing few complex classes instead of many simple classes
4. Failure to use Design Patterns
5. Using Design Patterns incorrectly
6. Using Inheritance instead of Composition

C++ AntiPatterns

1. Using Dynamic Binding instead of Templates
2. Using Pointers instead of References
3. Not using the Standard Library
4. Using Friend Classes
5. Using Stdio instead of Streams
6. Downcasting
7. Not using const and mutable
8. Writing Code that is not Exception-Safe
9. Not using Namespaces
10. Using Comments instead of Code

Management AntiPatterns

1. Purely Functional Organization
2. Purely Product-Oriented Organization
3. Hiring a Failed Team Intact
4. Managerial "Name That Tune"
5. Accelerating Milestones
6. Tolerating Hackery
7. AYSO Mentality
8. Delegating Comprehension
9. Not Promoting from Within

Configuration Management AntiPatterns

1. Editing generated files
2. Forking
3. Release without regression
4. Not using a static isolation methodology
5. Overemphasizing code coverage metrics
6. Poor specification

Anders Johnson, last modified $Date: 2002/02/05 $