Postmortem Document

The following is from the book "Coder to Developer" by Mike Gunderloy.  I found if very interesting because I am currently working in an environment where projects often get handed off from one group to another with little documentation from the people that actually wrote it.  I think this type of document would be very useful. (Although I am not sure that I could be disciplined enough to write it for every project.)

The purpose of the postmortem is to record the lessons that the teamor the manager learned in the course of building the software (or thethings that they wish they has known before they started).  A typicalpostmortem might include these sections:

• Overall description of the project
• Who was involved on the team
• How the projects' scope and features changed from initial design to final ship
• A list of things that were done well during the project
• A list of things that could have been done better
• A list of the tools used, along with en evaluation of their quality
• A list of tools that team members wish they had had available
• A list of important project documents with their location
• Recommendations for the next project: How can things be done better?

Coder to Developer

I have just finished reading "Coder to Developer". I found it to be a very enjoyable book. It is a book about all of the different tools and skills that a good developer needs to take a software project from beginning to end. I liked it because although the author uses a .NET sample project throughout the book, a lot of tools and skills could apply to any project. The author did a lot of research on this book (or acquired it from real world experiences) and lists many alternative tools ranging from open source to big expensive commercial tools. He also lists many invaluable web sites that are excellent resources for developers.

Reorganizing

“We trained hard…but it seemed that every time we were beginning to form up into teams we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralization.”

- Falsely attributed to Petronius Arbiter; more likely Robert Townsend

Project Task Scheduling

I just read Joel Spolshy’s page on software project task scheduling. He has some really good ideas. I like the idea of scheduling time for vacations, debugging, integration time, and scheduling some buffer time for tasks that took longer or for the tasks you didn’t know you had to do. I also like what he has to say about never letting managers tell programmers to reduce an estimate. In this article Joel also has some very convincing arguments of why you should actually create and manage a task schedule.

Bye Bye to Mr CIO Guy

Bye Bye to Mr CIO Guy is cool. I laughed then cried (literally). We are living in a changing IT world. I believe that the tech industry is changing to the next level. We are moving away from building applications that manage data on the network to building applications that access data in a wide variety of ways (Example: web, blackberries, application, via web services). We are moving to a more real-time world with instant access from anywhere. We are moving to model that is more diverse. And unfortunately, as the song says, industry is trying to cut cost, outsourcing to cheaper countries. The issue is the bottom line. Companies are tired of software taking too long and paying for features that don’t quite meet acceptations. I believe that this will separate the software developing men from the software developing boys. We are emerging into an era where software must be built cheaper and easier. I believe that technologies like code generation tools (see Code Generation and CodeSmith) and testing frameworks (NUnit) will help in creating software faster and more reliable. We still have a long way to go before we have the software we want at the cost we want. But there is a lot of advancement taking shape.

If only someone would come up with a Rapid Application MAINTENANCE tool.