Patrick Cauldwell wrote a brilliant post recently about the guiding principles for running your software development projects. It runs the gamut from how to know when a piece of code is ready to be handed off to testing, to good techniques for categorizing trace levels in your code. There isn't a single point on his list that I don't agree with. Some I have a stronger propensity to than others. For instance, "Continuous Integration" is deal breaker for me. If there's no CI for it, I won't work on it. Others, such as "Buy, not Build" do not evoke such a strong reaction out of me, but I do still believe that they have their place in this list.
There are a couple of things that are missing from Patrick's list though. Here's what I would add:
- Build for Maintenance
- All code should be built with the maintenance team in mind. If you can't adequately argue that you'd be able to understand it in 3 weeks time, you need to rework it so you would.
- Pragmatic and appropriate verbosity in naming will always make the situation more understandable for the maintenance team
- You are the maintenance team. Immediately after you write a line of code, you are in maintenance mode. Don't write it if you don't want to have to fix it.
- SRP
- All code design should be done with the Single Responsibility Principle in mind.
- SRP will make achieving 90% code coverage much easier and more attainable.
- Do not write code to accommodate possible future changes. Write code that adheres to SRP, code to the interface and have good test coverage. Those three things will make your code easily accommodate future changes.
- Coding to Interfaces
- Always code to interfaces
- Interfaces hide the actual implementation from the consumer of the code. This goes a long way to allowing for fast changes to your code base.
- Fail fast
- Provide your developers with the ability to run the application's test suite quickly and easily on their local machines. The faster that these run, the more that developers will run them. The more that developers run the tests, the faster they will know about breaking changes.
- Stabilize developer tasks while they are working on them
- Change is inevitable. In some situations change is a daily fact of life. Be open to allowing the customer to change their mind.
- Don't be feeding developers constantly changing specifications while they are working on writing code. Hold the changes back until the developer has had time to stabilize their code, then feed them to him/her. They will be more productive this way.
- Be pragmatic when holding changes back from developers. If the change request is very large or very intrusive you may get more benefit from stopping the developer before they get to far.
Are there any other things that you'd add to this list?
posted @ Wednesday, June 13, 2007 6:26 PM