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.

Pocket PC and Movie Viewing

I have a Pocket PC and the other night decided that I would try saving an episode of Futurama onto my SD card so that I could watch it on my Pocket PC. I have a TV tuner card on my computer that records and saves it as mpeg-2 files. The Futurama episode that I saved was about 550mb. I downloaded TMpegEnc and converted the file down to about 100mb (mpeg-1). I was then able to load the file into Movie Maker and edit out the commercials, and save it to a Pocket PC compatible file. And then finally save that file to my SD card. So all this sounds cool right, well not really. It took me 4 hours to convert the 550mb file down to 100mb. Then it took me another 20 minutes just to load the file into Movie Maker, which split the file into 150 different clips. That took me about another 1/2 hour to build the storyboard, drag all the clips down and in order while editing out the commercials. Then it took me another 15 minutes to create the movie from Movie Maker. So in less then 6 hours I was watching a 1/2 hour episode of Futurama.
I have two thoughts on this. One, computers need to get faster. When we can edit a 2GB file easily then we will have a good video-editing machine. Second, why doesn't the manufacture of my TV tuner card have the ability to save to a version that I could then view on my Pocket PC. They have the ability to save me a lot of time.
Well I did, in fact, find that I could save from my TV tuner directly to an mpeg-1 file. It was not the same as the 100mb file that I mentioned above, it was about 300mb. But it is easier to deal with, and saves me the 4-hour conversion.

The Rule of 3

I think Dan has some good ideas. I like this blog because software is an iterative process. You cannot expect to build the perfect software package on the first try. I disagree that it takes three iterations as a rule. It may take more iterations or less iterations depending on the complexity and the client feed back/input. If you get good help from clients when building your application you may get it right on the first try. However, this is a rare case because clients usually only want things that fit into their own personal workflow and that may not be what other clients want. Leaving your software to be a custom solution when you wanted a commercial application.