I enjoy watching This Old House, Baking with Julia, and Julia Child and Jacques Pepin Cooking at Home. In addition to learning how to fix things around the house or occasionally preparing a delicious meal, I understand that these masters have a reason for just about everything that they do. The title of this article is a bit cheeky, but I am serious about my belief in the results my “recipe” will reliably yield. The individual elements are not all my own, but like every master carpenter or chef I have gleaned some of the best ideas from peers and my own experiences.
Paul’s Perfect Project
7 to 10 competent developers (may substitute 3 competent developers for 3 smart people willing and motivated to learn)1 competent project manager
1 competent architect
2 trained testers
1 database expert
1 technical writer
1 graphical artist
1 to 4 competent programmers1 great software development tool, preferably Visual Studio .NET
1 versioning tool, like SourceSafe
1 testing tool, NUnit works well here
1 modeling tool, preferably Rational XDE (may substitute Visio or Together here)
1 project scheduling tool (Microsoft Project works here)
1 reliable database tool (optional)
1 data modeling tool (use if a database is desired)
1 written project plan with clearly stated goals
1 adequate budget of time and money
2 tablespoons of empathy for users
10 teaspoons of patience
Dash of users
In a large, open room with great computers, Internet connections, and email add all developers. (Make sure to remove all cubicles.) (Send the project manager to some remote place; provide the project manager with a checkbook and a willingness to sign checks.)
Mix users in with the project manager, architect, testers, and the technical writer taking copious notes. (Note: Project managers are not permitted to make technical decisions.)
When the riskiest and most challenging aspects of the project have been defined, begin designing a solution. Adjust the solution as the users change their minds or begin to understand their problem to a greater degree. (By tackling the hardest part first you will likely have to address the greatest obstacles, mitigating risk earlier, rather than later, in a project.)
Testers may begin implementing a testing plan at this point.
Complete a written project plan, ensuring that the objectives of the project will meet the users stated and implied goals. (Begin spending money liberally early. Waiting later for a big push is likely to lead to missed deadlines.)
Solve the general problem with a UML model first, as it is easier to change a model than it is to change a program. Solve the general problem in terms of interfaces. This leads to the greatest number of options and flexibility. (For example, Marshal-by-reference objects in .NET Remoting really depends on interfaces.)
Begin prototyping a presentation layer as the users will unlikely be able to make sense of any code, and the presentation layer makes it look like real work is getting done. Use a graphic artist here.
Design a solution, preferably one that is analogous to some physical process that is easy to explain and understand. Design classes that capture essential aspects of the problem domain. Implement a façade layer that constrains interactions between the presentation layer and the solution to clearly defined objectives. Coding use cases in the façade works wonders here.
Code for 3 to 6 months adjusting the schedule accordingly to changes in the understood problem.
Implement automated tests and run liberally. Build and deploy regularly.
After you have a key working aspect of the system that has been tested thoroughly, plan to show to user. (Sandbag here. Do not promise what you already don’t have. In other words, under promise and over-deliver; not the other way around.) When the project completion is assured, ring the dinner bell.
Plan on spending at least half of your time in the presentation of the meal. (In other words allow at least 50% of the total schedule for fixing bugs and setting the table, promote your successes and don’t try to conceal missteps (every one recognizes lumpy gravy), deliver bad news early (“dinner will be another half hour, here are some hors d’ oeuvres, have another cocktail”).
Make the whole event lively, fun and entertaining. Casual attire is a must.
Summary
Every meal prepared for the first time takes some experimentation. There will be mistakes during the invention process. Unfortunately, software developers seldom have the luxury of serving a mistake to happy diners. It has to be right before it can be served. This means that your team will make mistakes trying to perfect the total meal. Be tolerant of this potentiality; learn from mistakes and try to do better and adjust as you go. To paraphrase a famous quote, “you may have a quick omelet with runny eggs or a good omelet but it takes as long as it takes.”
While perfecting your meal remember that Sophocles said that none love the bearer of bad news, but Sophocles never developed software. In software development there is always bad news; don’t shoot your messengers or they will stop sending you reliable messages. Part of Bill Gates’ genius is that he wants bad news to travel faster than good news. Or put another way good news will keep but a fire in the kitchen needs immediate attention.
Finally, from my experiences a fun environment is a must for creative people. Agree or not, software developers are some of the most creative and imaginative people on the planet. Building software is as much art as science and will be for many years to come. If you are surrounded by people in suits and cube farms, then creativity is probably suffocating in a constipated bureaucracy. And, besides, it is difficult to get sufficient blood to your creative brain with a constrictive leash around your throat.
About the Author
Paul Kimmel is a software architect, writer, and columnist for codeguru.com. Look for his recent book Visual Basic .NET Power Coding from Addison-Wesley. Paul Kimmel is available to help design and build your .NET solutions and can be contacted at pkimmel@softconcepts.com .
# # #
