Software Development Beliefs

• Solutions Team
• Programmers' Canvas Pattern

• Work Experience
• My repository of solutions

In over 20 years as a programmer (since 1981), I have yet to become an expert in any single area. I am not a J2EE expert. I am not a .NET expert. I am a generalist who has strong practical experience who can swim to almost any level of detail.
No programmer should be an island. Developers should enjoy sharing their talent and knowlege.

Ask questions. What customers ask for is not necessarily what they want.

Search Open Source repositories for your idea before coding. Sometimes existing code can provide useful insights. Peer reviewed Open Source is better than starting from scratch. Even tangential projects can be enlightening.

Time is your enemy. The complexity of the task at hand isn't your biggest problem. Most problems can be solved quickly 80% well enough. You can't buy time. Your competitors are probably ahead of you already.

Teams rarely have time to generate detailed design documents before writing code. Get something down on glass - a plan - initially. Let the code evolve as it insists. Code and design are not independent entities. "Write once, refactor many times" is essential and unavoidable.

The following tools are essential: bug tracking (e.g., Jira), testing, wiki (e.g., Confluence), source control (CVS), blogs (wordpress), diagramming (Visio), IDE (Eclipse or Visual Studio), monitoring (Nagios).

Dynamic languages such as Perl and Python are fabulous but it's worthwhile to invest in Java and even C++ for long-term projects

Build and test often. Developers should have private sandboxes and common test beds.

1. Code
2. Test privately
3. Copy to public staging area
4. Check in

Always use Source Control, even if you're the only programmer

Testing is more than half the effort. Test all scenarios including exceptions before releasing to QA.

Populate tables with millions of records of dummy data before releasing to QA.

Developers who check in broken code irresponsibly should get a warning, with termination as the consequence of the third offense.

Features should not be held hostage by releases. Once Feature A is ready to go, let it go. Immediately. Feature B can wait.

Failure to release enhancements in a timely fashion results in locked doors. It may be a slow death, but death will come.

Troubleshooting problems in real time under pressure is a nightmare scenario. Create a wiki/knowledge base along the lines of:

1. Problem
2. Probing
   • What steps were used to troubleshoot the problem?
3. Solution

There is no time to test everything. Leverage tools, such as Nagios, to monitor the system.

Pick a sesssion randomly every few minutes, logging queries and their durations. Review the logs periodically. Use Nagios to check for runaway queries.

There always comes a time when you have to sacrifice your personal life for a deadline. After making the deadline, do your best to rebuild your neglected life and body. Even learn some new tricks.

---