1. Accept failures as part of the development process. Corollary a - Never plan to build the most robust long lasting thought out application or to do things the "Right" way. Corollary b - Start programming as quickly as possible.
2. If your target deployment is greater than 5 months, develop your application with future tools in mind
3. If your target deployment is greater than 6 months, develop with future tools (beta versions of tools that will be used).
4. View your application as a set of loosely coupled modules rather than very integrated units. Corollary a - If any of your process maps or requirements documents are longer than 25 pages, throw them out. Corollary b - If a requirements document requires that you read another requirements document to understand it, throw it out.
5. Never have more than 4 people in a meeting.
6. Never have a meeting that is longer than an hour and a half.
7. Do not plan for bugs or exceptions until you are 80% done with development.

Accept failures as part of the development process

The road to success is fraught with failure. Many application development efforts fail because individuals involved are afraid of failure. They spend months planning how to setup the pieces so that it will scale well, it can be easily extended or bug free, easy to understand for the user, satisfy all a users needs etc. The problem with this approach is that nothing gets done. Every one wants to set things up the right way the first time so they don't have to redo things. In doing so, they never get to the point of setting up anything that will provide a visual working context to progress from.

The main key that people often miss in all the confusion is that application development is an evolutionary process not a revolutionary process. Things rarely work perfectly the first time, but it is from these first time efforts that you have a working model to learn from and to sculpt. Redo what doesn't work and don't look back.

Never plan to build the most robust long lasting thought out application or to do things the "Right" way
Surely everyone wants a good robust application that will last for a longtime, but rarely does this happen. Planning for success is just a sure way of setting yourself up for failure. The reason is that if something does not go according to plan - it is human nature to strike everything and say "We Failed". Note this does not mean "Plan for Failure" - but simply don't do stupid things, don't think too much, but think a little.

Start programming as quickly as possible. People tend to wait till they've fleshed out all the details before beginning to program. This might be fine for one shot deals such as operations or building a house etc., but tend to not be the best approach to take when architecting an application for a number of reasons.

1. In order to flesh out a design and see where it works and doesn't work, you need a working model to view so that less technical staff can relate to it. Current case tools satisfy some of that, but do not do it completely, are expensive and just pose another tool to learn to use. A working prototype or smaller scaled version (Proof of Concept), provides a better and cheaper solution.
2. It is often while in the process of programming something that the feasibilty of a key component is discovered. The sooner that you find out that an approach will not work the better - because it is then easier to change other parts before things get set in stone.
3. Business management staff have low attention spans when it comes to non-visual things or abstract concepts. If you don't provide them with something visual to look at relatively quickly, they loose interest fast and forget what it was they asked you to build. "What was that again hmm   What has your staff done for me lately?  Why do you need all that money in your budget?"   Dilbert says it all.

With that in mind - it is good to balance out your programmers if you can. Some programmers are good at producing output quickly, or generating mockups which may not be most efficient or the best coded while other programmers write really tight code that is fast efficient and easy to understand, but seems to take forever for them to write it. Programmers that are fast at outputing code should be put on the task of developing the prototype. The term I like for that is stalling for time (until you've got the real stuff). This keeps your low attention span coworkers content while providing a visual context for your other staff to work with.

If your target deployment is greater than 5 months, develop your application with future tools in mind. If your target deployment is greater than 6 months, develop with future tools (beta versions of tools that will be used).

With the rate of change in the computer information industry tools of yesterday become passe within a year to 2 years. For a large application, the last thing you want is to spend a lot of effort designing and programming with tools/languages that are already obsolete or incompatible with newer tools by the time you are ready for deployment. Your friends will laugh at you. The IT server department will despise you because it doesn't work on their new-fanged server they have. The programming staff will resent you for keeping them in the dark ages because programmers hate programming in obsolete things and like to experiment with new things - if nothing else but for job security.

Even though the tools of tomorrow are not out there now when you are developing, it is important to keep abreast of them with magazine articles etc. to minimize as much as possible on developing apps that will be incompatible in the next release or so.

E.g. For example in Java - you have deprecated methods - stay away from them as much as possible because as the name suggests they may not be there in the next release.