Development Central

With all the discussions of software craftsmanship and SOLID principles lately, I’d like to list the guidelines (not absolute rules!) I find most useful. These are listed in order of importance, highest to lowest.

Key Principles and Practices of Software Development

1. Never stop learning. Strive for continuous improvement everywhere. Be passionate about your profession.
2. Source control. Unless you like writing novels in the sand. Check in frequently (but compile and test first). Learn to use branching effectively.
3. DRY (Don’t Repeat Yourself). Remove duplication every chance you get.
4. OOP. Encapsulate. Resist the lure of procedural code. Favor composition over inheritance. Also be aware of alternatives, such as functional programming.
5. TDD (Test-driven development/design). Automated unit testing of classes in isolation is the most useful practice I have learned in the last ten years. Many other practices build on this. Test-first is a major aid to designing usable APIs (you’re eating your own dog food). TDD requires training and practice, but it is a skill worth acquiring.
6. Refactoring. Keep improving code quality. Requires tests to do properly. Make one small change at a time, then test. Best done with automated tools. Leave the “campground” cleaner than you found it.
7. Single Responsibility Principle (SRP). “…a class or module should have one, and only one, reason to change.” – Robert C. Martin, Clean Code. If you end up with small, focused methods and classes that are easy to understand, you’re probably doing it right.
8. Favor simplicity. The goal is not to show how clever you are.
9. Know your domain. Gather clear, testable requirements before you start coding. Get frequent feedback from customers, domain experts, and other developers. Do not “go dark.”
10. DI / IoC (Dependency Injection / Inversion of Control). Decouple your classes and make dependencies explicit to support SRP and testability. Interfaces are your friends.
11. Automate routine tasks. Continuous Integration (CI) is a great example of this. Computers excel at performing repetitive tasks; developers don’t.

Frequent Anti-patterns of Software Development

1. Technical Debt. You will not clean it up tomorrow. Do it right, now. Your future self will thank you. “You can make very short-term gains (days or weeks) by deliberately sacrificing quality, but the cost – human, business, and technical – is enormous.” – Kent Beck, Extreme Programming Explained
2. Premature Optimization. Favor maintainable code over fast code. If you must optimize, profile first to find the bottlenecks.
3. Copy and paste coding. Instead, DRY and refactor to remove duplication.
4. Deploying code that’s not in source control. If everything you need to build and debug the current production version isn’t checked in, you have a sword hanging over your head.
5. Not Invented Here. Avoid reinventing wheels. Rolling your own security/encryption code is particularly unwise. Also consider the source; copying and pasting untested code from the Internet carries risks. Finally, insure the solution is a good fit.
6. Zealotry. Few methodologies work for every team on every project. Consider other viewpoints. Be open to change. Even methodologies evolve.
7. Large classes and long methods. See Martin Fowler’s book Refactoring.
8. Singleton Pattern, static classes, and other forms of global data and/or tight coupling.
9. Not understanding exceptions. Error codes and null return values can lead to unstable code. “A good rule of thumb is that if a method does not do what its name suggests, it should be considered a method-level failure, resulting in an exception.” – Jason Clark, Cwalina & Abrams’ Framework Design Guidelines
10. Unit tests that are really integration tests. Not that there’s anything wrong with integration tests, but you need to understand the difference.
11. Excessive comments. If your code expresses intent, comments are often superfluous. And why comment out sections of code that’s under source control? Just delete it!
12. Using the wrong tool for the job, such as parsing HTML or XML with Regular Expressions. Also, dismissing a tool (such as Regular Expressions) entirely because some developers misuse it.

Remember that the right answer is often “it depends.” Almost everything is a trade-off. Use your own judgment. Think!

Thanks to everyone who reviewed my initial draft, and to Robert ("Uncle Bob") Martin for inspiration.

Comments are welcome.

I have a great deal of respect for “Uncle” Bob Martin. He’s done a tremendous amount to bring professionalism and craftsmanship to software development. I’ve heard him speak, and he definitely knows more than I do. But in this one small area of programming, I think he’s off-target. Decide for yourselves.

Dependency Injection Inversion (Uncle Bob)

Some of the follow-ups:

Poor use of DI versus need for DI (Jimmy Bogard)

Dependency Injection Inversion Rejection (Davy Brion)

Constructor over-injection anti-pattern (Jeffrey Palermo)

I agree most closely with Jimmy Bogard on this (Davy Brion makes some good points too). In Jeffrey Palermo’s post, I side with Alwin in his comment - why not just pass an interface to the factory?

EDIT: Here’s a nice rebuttal to Jeffrey Palermo’s post that discusses better alternatives to Alwin’s solution:

Rebuttal: Constructor over-injection anti-pattern (Mark Seemann)

EDIT: Another response to Uncle Bob:

Rejecting Dependency Injection Inversion (Ayende)

EDIT: And another related post by Mark Seemann:

Dependency Injection Inversion in .NET

EDIT: Yet another interesting post by Mr. Seemann (I think I’ll pick up his book):

Refactoring to Aggregate Services