Unfettered Blather

May is the anniversary of my technology career. Going on nine years now and entering the management fold, I wanted to revisit the rules I created for software development 2 years ago while I was still in consulting.

1. Don’t panic
2. Write the best code possible within the time frame given. If you have lots of time then your code should be excellent. There is nothing wrong with writing functional if not optimized software if you are on a tight schedule either. The customer only cares about the end results.
3. Work to meet all deadlines, even if they are unreasonable. Do everything in your power to make a deadline on time.
4. When a deadline is not reasonable, point it out to management. They may not change the deadline but at least if you miss it then you can say they were warned.
5. Coding standards should be adopted and strictly enforced. They make the codebase easier to maintain and will often help less experienced programmers from making simple mistakes. The simple mistakes are always the hardest to find.
6. Ask for what you need but make do with what you have.
7. Nobody “owns” code. Anyone should be allowed to make improvements to code when they are able.
8. Changing code because it was not written “your way” is not the same as improving it.
9. Every team should adopt or develop a methodology. Senior developers and team leads should observe what is working and make it a formal practice.
10. When you have downtime, write documentation, make notes on potential code improvements, and maybe refactor that kludge you introduced two releases ago because you were in a hurry.
11. Refactoring should only be done if there is an obvious benefit. Moving around code, making minor changes, or even doing optimization should be avoided if it may break an imminent release. Refactoring is good, but timing is everything.
12. Cut-n-paste is a fine tool but should be used with care. A majority of your programming effort should not involve cutting and pasting code.
13. Don’t underestimate the power of good software design.
14. Develop a personal methodology to get yourself from requirements gathering to the final product successfully. Coding should be the majority of your effort but you shouldn’t code without a plan.
15. If the application is functioning as planned but the customer doesn’t like it, then the application is a failure. I don’t care how brilliant your code was.
16. Technology choices should not be made based on bias or resume building. The most appropriate technology for the job should be chosen.
17. Act with integrity. Gave credit where it is due, blame no one else for your mistakes.
18. If you are going to miss a deadline or a problem arises, be quick to notify someone that there is a problem.
19. If you make a mistake, your first action should be to fix it. Laying blame or trying to cover your rear wastes time. In the long run you’ll look better if people see you acting quickly to correct your actions. The only people who never make mistakes are the ones who never do any work.
20. Don’t say “I don’t know”. Say “I’ll have to look into it”, “I don’t have any experience in that area”, or anything else that indicates to your client and/or customer that you will make an honest attempt to get some more information.
21. Don’t say “I can’t”. What it usually means is “I won’t”. Nothing is impossible. It’s always a matter of how much time and how much money. If the customer has an unlimited supply of either, then the only thing stopping you is you.
22. Assume that QA will find a problem no matter how thoroughly you unit tested. If QA doesn’t find any problems in your code, then assume something is going to fail spectacularly upon release.
23. When someone finds a problem in the system, assume it is your fault and investigate all possible causes in your code. Laying blame and pointing fingers should not be your first reflex. Besides, it’s a lot easier to lay blame when you already know it isn’t your fault. If it is your fault, maybe you can fix it before people start pointing fingers.
24. Diversity is a good thing. If we were all the same we’d all make the same mistakes.
25. The worst person to find mistakes in your code is you.
26. No one ever became great at their job by never being challenged.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.