Anti-Patterns and Worst Practices of Software Development

1. Anti-Patterns and Worst Practices Steve Smith, MS Regional Director, MVP http://SteveSmithBlog.com | http://CodeProject.com

2. Why Anti-Patterns?Is this just one big rant? You may be wondering What’s in this talk for me? What exactly will I walk away with if I give you an hour of my life?

3. “Those who fail to learn from the mistakes of their predecessors are destined to repeat them” – George Santayana

4. How We Learn…

5. ContextIs King

6. Don’t Repeat YourselfSteve Smith Duplication is waste Repetition in logic calls for abstraction Repetition in process calls for automation …the DRY principle provides fundamental guidance to software developers…

7. Beware the ShareUdiDahan The code review that I had felt so ready for came as a rude awakening — reuse was frowned upon! It turns out that I was missing something critical. Context. The libraries of shared code I created tied the shoelaces of each foot to each other. When applied in the right context, these techniques are valuable. In the wrong context, they increase cost rather than value.

8. Be MindfulLittle mistakes can make a big difference

9. Principles of Mediocre programming

10. Fast Beats Right (FBR)Principle of Mediocre Programming It is always more important to deploy something that appears to work, than to spend time ensuring “correctness” a.k.a. “cowboy coding” or “duct tape programming” It’s OK: When a hard deadline is looming, or for throwaway apps or spikes. Prefer: “Continuous attention to technical excellence and good design enhances agility” – Agile Manifesto

11. Feature CreepPrinciple of Mediocre Programming Projects built using Feature Creep never, ever have release cycles that complete appropriately. Just when the end is in sight, someone adds just one more feature they are desperately in love with. It’s OK: When the added scope is a critical bug fix. Prefer: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” – Agile Manifesto

12. Assumption Driven Programming (ADP)Principle of Mediocre Programming Assume the user will only use your software the way you mean for them to. (Psychologists call this false consensus bias.) Of course it should be obvious to anyone how they’re supposed to use the application, so it’s the user’s fault if they do something unexpected.

13. Assumption Driven Programming (ADP)Principle of Mediocre Programming It’s OK: When you are the only user. Prefer: Practice defensive coding. Watch how users attempt to use the software. Treat handling the unexpected like any other feature.

14. Telemarketer Principle (TP)Principle of Mediocre Programming The best way to retain control of what your code does is to manage exactly which objects it uses and what calls it makes at all times. It’s OK: In simple and small applications. Prefer: Follow the Hollywood Principle: “Don’t call us; we’ll call you.” The Dependency Inversion Principle can be used to correct this kind of code.

15. Telemarketer Principle

16. Anti-Patterns

17. Static Cling Pattern (SCP)Anti-Pattern The easiest way to add functionality or track state is via static/global methods and objects. The Singleton Patternis also your best friend! It’s OK: In simple and small applications. Stateless operations can also be performed via static methods. Prefer: Dependency Inversion Principle. Your code should depend on interfaces, not static calls which cannot be injected. Static methods are death to testable code.

18. Static Cling in Action

19. Static Cling Removal (Step 1)

20. Static Cling Removal (Step 2)

21. Vestigial Structure Pattern (VSP)Anti-Pattern Don’t remove code that’s no longer used just in case it’s needed later! If you’re really brave, comment the code but leave it in there. It’s OK: If you honestly don’t have source control.

22. Vestigial Structure Pattern (VSP)Anti-Pattern Prefer: VSP is often a symptom of a muddled architecture, where it is difficult to tell where one feature begins and another ends. Use source control. Delete unused code; if you end up needing it, recover it from source control.

23. Flags Over Objects (FOO)Anti-Pattern Instead of using objects, polymorphism, or delegation, it’s much faster to just add a flag to a class and expose it. Who needs inheritance? It’s OK: If you are constrained from creating additional child types. Prefer: Tell, Don’t Ask. Instead of checking a flag before performing an action, tell the object what to do and let it polymorphically do so.

24. Flags Over Objects

25. Flags Over Objects

26. The God Class (TGC)Anti-Pattern If reuse is good, then reusing one class everywhere in the application is ideal. Strive to create one class to rule them all, capable of doing anything and everything your application might require. It’s OK: In very small applications and spikes. Prefer: Follow the Single Responsibility Principle

27. Worst Practices

28. Found on Internet(FOI)Worst Practice Search engines these days are smart; obviously the first blog post found that appears to solve the issue at hand must be the best approach based on our collective wisdom. Get it to compile and move on. It’s OK: If you really do understand what the code is doing.

29. Found on Internet(FOI)Worst Practice Prefer: Write a spike solution to ensure you understand the code. Write some tests that confirm the code behaves as you expect. Review other approaches – are you asking the right question?

30. Premature Optimization (PO)Worst Practice All code written should be optimized for performance, even if the resulting design is less clear or elegant, or if the code in question is nowhere near the critical path for the application. It’s OK: Optimization is OK when warranted; premature optimization is by definition not OK. Prefer: Define performance requirements. Write tests that validate these requirements are being met. Do not optimize unless these tests fail.Identify bottlenecks; don’t blindly make “fixes”.

31. Copy-Paste-Compile (CPC)Worst Practice The feature you’re working on is nearly identical to one already in the system. Just copy, paste, and get the code to compile and you’re done! It’s OK: In throwaway code (spikes, one-time migration apps, etc.) Prefer: Keep your application code DRY. Refactor common code into shared modules when it makes sense to do so (avoid introducing excessive coupling).

33. Copy Paste Coding Atomiq Wheel View (GetAtomiq.com) Identifies duplicate code Outer ring comprises project files Blue lines are duplicates between files Red lines are duplicates within files

34. Copy Folder Versioning (CFV)Worst Practice When really big changes are imminent, there’s nothing like creating a copy of the current code folder to reassure you that you can always roll back. It’s never OK. USE SOURCE CONTROL

35. Golden Hammer (GH)Worst Practice Your favorite language, framework, library, or tool can do anything! Wield it with confidence, and ignore anybody who tells you another tool might be better suited. It’s OK: When you really do have nails that need hammering. Prefer: Become familiar with a variety of languages, tools, and frameworks. Keep an open mind as you approach problems.

36. Shiny Toy (ST)Worst Practice Did you hear about the latest beta (tool/language/framework)? I’m sure it will solve all of our application’s problems. It’s OK: In spike solutions, and/or for your own learning. Prefer existing and well-known tools and patterns to unproven ones for production use.

37. Reinvent The Wheel (RTW)Worst Practice We can build it better ourselves. No matter what “it” is. We don’t trust anything that was Not Invented Here. It’s OK: When “it” is core to your business and/or application. Prefer: Know and use your application framework (e.g. the .NET framework). Share knowledge within your organization. Learn to make reasonable build vs. buy decisions when appropriate.

38. The Big Ball of Mud Architecture Wins the prize for MOST POPULAR “architecture” By default No clear separation into logical layers

40. More Lessons Learned

41. Don’t Be Cute With Test DataRod Begbie It was getting late. I was throwing in some placeholder data to test the page layout I'd been working on. I appropriated the members of The Clash for the names of users. Company names? Song titles by the Sex Pistols would do. Now I needed some stock ticker symbols — just some four letter words in capital letters. I used those four letter words. It seemed harmless. Just something to amuse myself, and maybe the other developers the next day before I wired up the real data source. The following morning, a project manager took some screenshots for a presentation...

42. Don’t Build SQL From Untrusted InputsXKCD Wisdom http://xkcd.com/327/

43. Be Mindful of DateTimesXKCD Wisdom Avoid Depending on DateTime.Now Avoid Comparing Times Between Time Zones Don’t Make Assumptions About the User’s Date Format Preferences http://xkcd.com/376/

44. A Few War Stories Some more tales from experienced programmers…

45. Know the PrincipalSteve Smith Who’s Paying For the Project? How directly do you communicate with the stakeholder(s)? Lessons Learned: Be sure you are meeting the needs of the principle. Avoid middlemen if possible. Deliver value early and often. 10 months is way too long to work on a project without a usable release.

46. Premature OptimizationDave Sussman Not just optimized performance… Lesson Learned: Clients don't care about how technically perfect your solution is and you shouldn't focus on the tiny details; get it working first, then refactor if necessary.

47. Ripple LoadingSteve Smith Avoid naïve Active Record pattern Example List Articles Get list of IDs For each ID Fetch the article Fetch the articleContent Fetch the author Lesson Learned: Test with realistic data.

48. Ship “Good Enough”Wally McClure Avoid Analysis Paralysis Build the simplest thing that can work Lessons Learned: Solve the 90% problem first, then solve the next problem, and then the next problem, but don't waste time on a problem to a level that no one really cares about. Startups don't need to spend weeks on a problem that has a simple solution and don't need to overcomplicate the solution.

50. Write mostly

51. Logging

52. 17 GB

53. 200M rows

54. Write mostly

55. Logging

57. Contact Steve Smith http://SteveSmithBlog.com @ardalis on Twitter ssmith@codeproject.com Dev Resources: http://CodeProject.comAdvertising: http://LakeQuincy.comAgile Dev: http://NimblePros.com