Border
Author: Bruce Grant, Jr. (BX)
Published: November 8, 2009
The Last Mile of Software Delivery
This article delineates the many tasks necessary for releasing a high-quality software product that are often overlooked during software planning phases.
I've been running a software development project for over a year. I have learned a very important lesson at great personal expense... The last mile of the race can often take the greatest effort. We all know the 80/20 rule in that 80% of the effort is often wrapped up in 20% of the code. However, on this project I failed to take into account all the tasks necessary to get the software out the door into a production release.

Below you'll find a list of the core activities I didn't allocate enough time for. Each time I plan a project, I'm going to return to this list and make sure I've left enough time.

  1. The Last Mile
    Tasks that are often overlooked or inadequately scoped during software planning.
    1. Quality Assurance
      We focused heavily on automated testing including unit tests from the ground up as well as automated functional testing of features. I honestly thought that as a result we would need very little QA at the end of the project. I was dead wrong.

      The fact is that you never have the time to create complete automation tests in engineering. Inevitably, corners get cut. On this project, our unit testing percentage is phenomenal and still it's not good enough to catch everything.

      So, the lesson learned here is to leave the standard 30% of the overall project duration for QA testing and to fix what QA finds even if you do everything "right" with your automated unit/functional tests in engineering.
    2. Documentation
      I knew we'd need doc and I spent a great deal of time in the first phases of the project creating it. I am committed to doing all that's necessary to create high-quality software and documentation is a big part of that. So, what happened?

      I didn't put enough time in to continually return to the documentation and update it. I failed to take into account the fact that other divisions of the organization would not really give me their time until the product seemed nearly complete. So, I did the grunt work up front to try and get input from operations and QA early in the project, but they weren't really providing all the feedback for the documentation at that point.

      They weren't because it was difficult to see the vision of the product so early in the project lifecycle and because it's human nature to put things off until when they have to be done. As a result, the documentation was lacking key information and that feedback came in the 11th hour. The lesson learned here is the allocate time throughout the project for documentation and to have a documentation sync-up task near the end with enough time on the task to get the feedback from the rest of the organization.
    3. System Integration & Irrational Exuberance
      I knew I didn't want to suffer the failures of past projects where I'd seen managers fail to take into account the time necessary to integrate with the other parts of the system. So, I delineated the touch points between the various system components right up front and had meetings with the stake holders of the other teams. I thought that was good enough and it clearly wasn't.

      It takes a lot of time to get teams to coordinate with each other. I didn't allocate enough time to repeatedly follow-up with the other teams and track their progress on the integration points. I thought that because I'd followed up a handful of times over a period of months that the work necessary would get done. I was irrationally exuberant about the process.

      In the future, I will need to constantly track these other dependent tasks and send out weekly or bi-weekly updates on their progress to all levels of management.
Comments
Be the first to add a comment.
Add a Comment
User:
Anonymous (Login or Create Account or Help)
Border