back

Here are some of the more interesting lessons learned from working in multiple large corporations and for the smaller groups as well:

• Balance Optimistic or Pessimistic code.  Fully optimistic code means that the programmers have assumed that everything will always work. They assume that the database is always available and that every database interaction will return a result when desired. In the real world, there are times when the database is down and other data problems happen. So the optimistic code fails and the users see ugly error messages or worse.

  Fully pessimistic code has tons of extra lines which test every database interaction -- slowing down every page. The best code is balanced to be ready for the most-common causes of failure.

• Have a Common Library.  Successful teams have a common library with short function names for the functions they use all day.
   
• No Duplicate Code.  Every keystroke saved is money in the bank!
   
• Have a Code-standards Document.  Define the naming conventions and programming standards for the team.
   
• Prepare For High Traffic.  The code needs to be optimized as it is created in case the site or business is successful. Count on success. Preparations include the ability to have all images on an alternate server, caching database hits, and load balancing with multiple servers.
   
• Create Administrative Panels First.  Many projects have the site administrative panels created toward the end of the project. Usually, a massive amount of time would have been saved if the admin screens were created in the beginning.
   
• Standard Issue: Do You Use In-line SQL or Stored Procedures?  If the project has unlimited funding and time (some do) then use Stored Procedures since they are faster and provide higher security.  If you have deadline or funding problems, use in-line sql and only create Stored Procedures when there is a performance benefit.
   
• Create an Audit Trail -- Install History and Log Tables at Beginning of Project. There almost always is trouble. If the tables involve money, then at least with triggers and log tables, you have a way to point to the source of the trouble and a way to reverse the transactions.
   
• Use a Debug Table to Track Behavior. It is impossible to know when things fail when there are thousands of users unless you track the start and end of their transactions.
   
• Personalize.Store user preferences and experiences so when they return to your application, they feel as though they have not left. Save the user time and increase their comfort level!
   
• Prepare for Design Changes. They are coming. Make it easy to add buttons or pages to an application.
   
• Do Not Rely on Automated Processes and Supplied Tools. The supplied tools are often quite elegant.  But if they fail in the middle of the process, you have to start them over at the beginning and you have no idea when they failed.  Specifically, for data migration or transfer tasks, it is sometimes better to have an actual piece of code to do the work!
   
• Be Willing to Break Rules.  Some of the best applications are ones that do not follow all the so-called Best Practices. But be sure you know what the rules are before you break them and of course let management know about the issues!
   
• Having a backup plan.  Expect the worst to happen, because it will.
   
• Three Kinds of Code.  There is code that benefits the customer, code that benefits the programmer, and code that benefits no one. Our goal is to have no code that benefits no one, and a balance of the code for the programmer and the customer. For example, if it is going to take the programmer hours or days to write code that will save the customer a few seconds, then the customer gets to wait a second. And if the customer will have his experience greatly improved by the programmer working a few more minutes, then the programmer should do it :)
   
• Agreement to Argue Until Clarity is Reached. Often, people will not offer their input because a supervisor is autocratic or difficult. Projects fail because the team members were reluctant to voice their opinions. The best designs happen as a result of people brainstorming or discussing (sometimes resembling arguing) until the best course of action is found.

  It is important to be able to discuss things until the best course of action is found.
   

• Watch Worker Body Language.  When you walk into a programmer area and see people on the edge of their seats, typing like crazy, it means that these workers are very productive, time is passing quickly for them, and their "struggle factor" is low. When they are sitting back in their chairs staring at the screen, the opposite is true. It is probably normal to be in the "struggle mode" while designing something or learning something for the first time. On some projects, people spend massive amounts of time struggling.

  The Team Leader or Project Manager must ensure that the team is making the best use of their time.