The rules in this article are outgrowths of my years of development experience – most of them building full web applications top to bottom. Something to keep in mind about saving time as you read is that when you save time you win in two ways. First you win with the money you save from not having your developer working for the saved period of time. Second you win by having your development completed sooner, thus negating whatever opportunity cost you would have realized had you not saved the time.

Rule 1 - Implement rigid naming conventions

Put simply, if a developer can name it, there should be a naming convention for it. The naming convention should include prefixes (where applicable), character case, and singular or plural form definition. Abbreviations should be used as little as possible – ideally never. Lastly, tables, stored procedures, web pages, variables, etc., should be named using the names of the concepts they represent. This allows for the code to read like a book and the ability to track concepts, like the concept of a user, from the html to the database. For instance, I might have a webpage that allows users to manage their information named manageuser.aspx which calls the GetUser function with the variable userId in the UserManager class which in turn calls the at_sp_GetUser stored procedure with the @userId variable, which does a select query on the at_User table, restricting on the field named UserId and returns the data.

Rule 2 - Don’t comment code

This builds on Rule 1. If your naming conventions are implemented correctly, there is no need to comment the vast majority of your code because any developer will be able to tell what the code is doing just by reading it. By having names for all of your concepts (like “users” mentioned above) and fully typing them out in all of your tables, stored procedures, web pages, variables, etc., your code basically comments itself. As with almost any rule, there are exceptions. Code that is very involved and complicated or hard to read should be commented, but the more closely you follow Rule 1, the fewer of these scenarios you will have.

Rule 3 - Copy, Paste, and Replace

This builds on Rule 1. If your naming conventions are implemented correctly, when you are creating code for a new concept, you will be able to copy and paste similar code for an existing concept, do a find and replace to change the old concept name to the new concept name, and have a large chunk of development done within a few seconds.

Rule 4 - Don’t use objects for concepts that already exist in your database

Traditional object-oriented programming calls for modeling all of your application concepts like users, companies, sales, etc. as objects in the application layer. Given the new development paradigm demanded by web applications, it does not make sense to remodel your database in objects. Read the tech article "Your database IS your object model" for more detail on why traditional object-oriented programming is obsolete.

Rule 5 - Don’t write unit tests

Yes, unit tests give you code coverage, but at what cost? The fact is that unit tests take almost as much time to write and maintain as writing and maintaining application code. If you have a solid development process, errors will be drastically reduced by virtue of the development process itself. The small number of errors that are not caught during development should be caught during your application testing. If it so happens that an error makes it to your live environment, you are building on the web – you can have a hotfix out within minutes to hours from error identification. The likelihood of an error making it to your live environment due to not writing unit tests is the risk that must be calculated against the cost of spending almost twice as much in time and money due to writing unit tests. Additionally, as we all know, even if you write unit tests, you will still probably end up with an error or two in your live environment at some point. However, as with almost any rule, there are exceptions. Unit tests may be worth the time and effort for mission critical portions of code that simply must not ever fail under any circumstances, such as billing code that could literally cost you money every second it is broken.

Rule 6 - Use a standardized, componentized architecture for your web application

This means architect your application such that you have standardized processes of writing code that can be replicated across your application concepts. For example, all of my web applications have a DataAccess namespace. The purpose of all classes in that namespace is to interact with the database. Functions in those classes simply make stored procedure calls. This gives me a couple of development time savings. First, when I want to create a new function, I can copy, paste, and replace (see Rule 3 above) an existing function, change the variable names, if necessary, and I have my new function. Second, since I am not using inline SQL, I don’t have to recompile every single time I want to change or update my queries. This represents a standardized process for writing code that can be replicated across application concepts. Although the development time saved from this one standardized process applied to one application concept are relatively small, you can imagine how it adds up when you factor in many different standardized processes saving time over many application concepts.