Top 10 Things to do on a software project (err 9 things...I got tired).

I have been a software professional for about 15 years and I have lead and/or architected a number of them. Here is a list of the top 10 things to do and/or avoid. Please add to the list if you are so inclined.

1. Define requirements in a declarative fashion. Never give a dissertation about why. You can do this in a supporting document if required; however, the requirements themselves should concisely dictate what is "Required" (regardless of the methodology you follow). I recently had the pleasure of looking at a 77 page requirements document. The intentions were good but it was almost impossible to design a system from it.
2. Requirements are not about implementation: Always keep implementation details out of your requirements document....enough said.
3. Understand the business. Often times developers/programmers just want a spec and code to it. Although important, go to meetings with the business sponsors/customers and understand their needs. Doing so gives you insight into what they are trying to accomplish and better enables you to satisfy their needs and grow as a professional.
4. Never underestimate what it takes to roll-out/implement a system. If you have a complex data-driven system, gathering data can take a large amount of time and must be accounted for in your project plan and conveyed to management. Underestimating this can kill a project.
5. Always pick a small highly-competent team over a large army. Larger teams require more communication and the management of the communication is much higher as you add more people to your team. A friend of mine made the analogy of using the Navy Seals versus the Army (also consider brook's mythical-man month "Adding manpower to a late software project makes it later.").
6. Sell your system. Whether you work in an IT department of a large corporation or a software vendor, selling your system is key to your success. Good software houses spend a large amount of their time and money selling their software and keeping their customer's happy. IT departments sometimes forget that they too must sell and evangelize their products (competing budgets, teams et. al).
7. Provide vision. Selling your system requires a vision, a problem statement, the solution and the costs and benefits of the system. Also, most complex systems have a life-cycle that defines what it will look like in each stage of its development from infancy to maturation. If you follow best practices and define a tiered architecture, you can also provide a vision as to how a collection of libraries and services can grow to become the basis for many projects.
8. Documentation is about communication: This shouldn't be a problem for most developers :). Many processes have a set of documentation to be completed. But often times there is also a lot of latitude in how deep you can go with your documentation. The problem is "when is enough enough". Years ago while working on my first UML project and I was trying to determine what this balance is and my VP said that documentation is about communication. You must convey what your team requires to get the job done and then support the system. Smaller highly competent teams means that many/all of the members can make the leap of logic to fill in any gaps.
9. Don't bother documenting your entire API by hand, use documentation generators. C# provides the /// construct that enables the auto-generation of your API. There are also a number of tools out there such as NDoc and DocumentX that further refine documentation generation. (including your database). This isn't a substitute for a design document that defines the process you are designing but don't bother with all of the tactical implementation details and documenting every method/property signature ad naseum. They get out of date so quickly. Instead, invest in one of these tools and auto-generate API docs on a periodic basis.

-Mathew Nolton