This is my first pass at a list of anti-principles, anti-patterns, and anti-practices that make up mediocre programming. Im hoping to refine this list and update this listing based on community feedback, so please leave a comment or contact me to let me know what Ive missed, and Ill gladly credit you with a name and a link if youd like.
Principles
Fast Beats Right (FBR) Its more important to get something done that probably works, or that works right now even if it will be hard to change later, than to spend time ensuring that it is correct or is well designed. This is classic cowboy coder or duct tape programmer thinking, and sometimes management may be OK with dictating that for a given feature or prototype, speed is more important than anything else. However, for typical, long-term projects where someone is going to have to maintain the application for years to come, this can be a very expensive principle to follow.
Preferred Principle(s)
Continuous attention to technical excellence and good design enhances agility Agile Manifesto
(do you have more principles of mediocre programming? Leave a comment below!)
Patterns
Static Cling Pattern (SCP) Static (global) methods and objects are often an expedient way to add some functionality to an application without spending any time worrying about where the right place for it to live might be. Using static methods for truly stateless operations that work only on the parameters passed in and do not have any other dependencies is fine, but problems arise when static methods instantiate objects or call other methods outside the scope of the passed in parameters. Once this has gone on for a while, it can be very difficult to introduce seams into the application to decouple its components from one another it has begun to suffer from static cling. (I first heard this term from Nate Kohari who credited someone else with it but Im not sure who first came up with the term)
Preferred Pattern(s)
Dependency Inversion Principle. Calls to static methods are direct dependencies that cannot be easily injected. Replace them with interfaces and calls to instance methods on injected objects.
More Reading
Static Methods are Death to Testability
(do you have more patterns of mediocre programming? Leave a comment below!)
Practices
Found On Internet (FOI) When faced with a problem, the quickest fix is often to search the Internet. This is a valuable and effective way to research solutions. The mediocre programmers approach to this, however, is to locate the first blog post or forum response that looks like it might be a fit to the problem at hand, and then to cut and paste the code, hack at it until it compiles, and run the application to see if it seems to work. If it does, move on to the next fire. If not, continue hacking until it does or go to the next item in the search results.
Preferred Practice(s)
Spike a solution using the found code and see if it works in a variety of scenarios.
Write some tests to confirm the behavior of the code does what it claims and works according to your expectations.
Review a variety of possible approaches to the problem and try to determine if youre actually asking the right question before jumping on a possible solution.
Premature Optimization (PO) Developers like to write code that runs as quickly as possible. Certainly, performance is one factor in nearly all software, but like all factors it must be weighed against other attributes like maintainability and velocity of feature delivery. The practice of optimizing code before one knows if a bottleneck exists in the current code, or if the actual production performance of the application will not be sufficient without such optimization, tends to result in waste. More often than not, the code being optimized is either good enough as is, or simply is not the bottleneck and thus any optimizations made to it will not impact the actual performance of the application.
Preferred Practice(s)
Get actual performance requirements from the customer and write tests to ensure that given scenarios comply with these performance requirements. Do not optimize unless these tests fail.
Collect actual data on the performance of the application and identify where the bottlenecks are. Spend your time eliminating the actual bottlenecks identified by your analysis, rather than guessing where the problem might be.
Copy-Paste-Compile (CPC) Sometimes an application exhibits a bug or requires new functionality that has already been corrected elsewhere. All that needs done is to locate the correct section of code, copy it, and paste it into the section of code that requires this behavior. Make sure it still compiles and check it in. Another task complete!
Preferred Practice(s)
Get actual performance requirements from the customer and write tests to ensure that given scenarios comply with these performance requirements. Do not optimize unless these tests fail.
Collect actual data on the performance of the application and identify where the bottlenecks are. Spend your time eliminating the actual bottlenecks identified by your analysis, rather than guessing where the problem might be.
(whoa, did someone copy and paste the above and forget to update it?)
Follow Dont Repeat Yourself and move logic that repeats into its own methods or objects. Fight duplication wherever you find it in your code.
Reinventing The Wheel (RTW) Part of an application requires a little algorithm or utility that no doubt someone else has encountered before, but rather than using an existing framework class or well-known industry solution, the developer takes this as an opportunity to write the best XXX utility ever. Its often more fun to write an algorithm or regular expression than to deliver yet another boring business form or report, but reinventing the wheel doesnt add value. (also seen sometimes as Not Invented Here (NIH)).
Preferred Practice(s)
Know and use the framework. If youre a .NET developer, the .NET framework has a ton of functionality in it and is usually a good first place to look.
Share knowledge within your organization. Its likely someone else in your company already has solved this problem.
Quickly estimate the time it would take to build the functionality from scratch, and the cost of your time. See if a commercial tool could do the job for less, and see if management is willing to invest in such a tool.
(do you have more practices of mediocre programming? Leave a comment below!)
Additional References
