Things that you should insist that your programmers NEVER do

I am not a real developer – I only play around the edges and keep up with the basics – but I think I’ve found a few “truths” that project managers should use when managing development projects. I pull a lot of advice from two authors: Jeff Atwood and Joel Spolsky who work together on a project called Stack Exchange. Their opinions are not universally loved but I’ve seen internal development projects that could have been much more successful if our developers had followed these rough guidelines:

• Functional Specs are Useful: Quite a few developers hate specifications – hard to write, hard to read, hard to use, and rarely useful. For many technical specifications, these developers are extremely well justified. Joel Sploksy offers an alternate view of specifications that is far more useful. By creating a written description of what a program is supposed to do (a functional specification) instead of how a program is supposed to be built (a technical specification) you get the chance to provide useful information to your developers. Read Joel’s multi-part description how to do that, then read The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper, and start writing documents that actually help your development projects
• Internationalization from the Beginning: Over the past two decades, every business article, magazine, web site, and book has been talking about how the world is flat and every business is competing on an international playing field. So why do I keep finding software that won’t install in a Japanese-language Windows PC? Why do websites turn 日本語 into ??????? Even though you don’t see need to support international languages now, you can make sure that your developers don’t shut the door early. I recommend that you start your development effort with a requirement to support multiple languages and force them to explain why they shouldn’t. I’m sure there are legitimate reasons for English only but make them justify it.
• Real Testing Hurts: When developing on your own laptop and connecting to a server that is down the hall, you are sitting in an almost perfect environment. Don’t let your developers test in a perfect environment – you won’t learn anything. For example, if you want this new application to work over the internet, you had better test it over the worst connection you can find. As Jeff Atwood points out, performance of your application in the real world is a make-or-break moment. You should make sure your developers run things in high-latency, low-bandwidth, sub-optimal environment or you may be in for a big surprise later. The internet is not new and the internet is not an optimal network.
• ASCII Text is NOT Enough: I think all developers need to read this article from 2003 about how to handle text. Even though the internet enabled, international business era is old news, it is surprising how many different systems mange non-ASCII text. Even my iPhone 4 occasionally takes a Japanese language website and renders it as some odd collection of wingding symbols. In addition to the point about internationalization of installation, make sure that your custom development doesn't manage non-English input. After all 田中一路様 is unlikely read mail addressed to ????????
• Things Break – Handle It: When you are working with complex systems, you have many different points of failure. It is a given that during the life a particular system that some key part will fail and it is up to your developers to handle it. To quote the Netflix developers “Each system has to be able to succeed, no matter what, even all on its own. We’re designing each distributed system to expect and tolerate failure from other systems on which it depends.” That particular team took it to extremes but since they were designing a massively mission critical system, it was worth it. When starting your development project you need to explain to your developers how much robustness you need for this project. If you let the developers pick you may not be happy with the results since they are likely to look at it from the “how hard is that to program” level and not the “how important is that to the business” level.
• Size Matters in Development: Test data is more dangerous than you might think. It is common for developers to use a very small set of test data in the database and run all tests against that smaller database. However, if your final system is going to massive, multi-server, multi-site, thousands of users then you had better make sure the pre-deployment testing is performed on a larger system. Jeff Atwood has a great explanation of the risks and how to avoid them that you can probably just hand directly to your development team.

Please post your own comments and feedback here. I'm interested if developers disagree with me on this.