elusivemind

Development is a tricky business. Whether it's application or web site development, there are always challenges that developers face while creating things for clients. Clients change their minds from the original designs, they see things they hate about their design once they get to use it, and the ever-present threat of scope-creep threaten the deadlines of even the most well planned projects. At the end of the day, most developers can't say no, so they end up over-promising on deadlines and accepting more work beyond the original project scope which leads to more trying to be done in the same amount of time.

I was reading an article on one of my favorite blogs, Coding Horror and came across this article which has caused me a bit of conflict. At the heart of the matter is the philosophy of shipping software and the topic raised a very important question: Is it better to ship unfinished software on time, or deliver a "perfect" product significantly late.

One the one angle, my experience with the Myth project and the lessons I took from it (at the expense of the original developers) were that you cannot ship alpha quality software as a release. The original Mumbo Jumbo development team was tasked with creating the third Myth game with a 12 month timetable. The task required converting the Myth rendering engine to an OpenGL format, and replacing the sprite-based modeling system with a true 3-D environment based on 3D Studio Max. With the deadline approaching, the development team and publisher made the decision to ship on-time (in October of 2000). The end product was hopelessly incomplete with numerous creative and code related bugs, some of which have not yet been corrected.

Upon release, the entire development and creative team was fired. What isn't immediately clear is whether the development team's end product was the cause of their termination, or if the publisher had planned to terminate them at the end of the project anyway. What is known is that the finished product received very little attention from marketing and was dropped entirely shortly after the holiday season.

On the other angle, I was involved with a project with the goal of developing an entirely revamped Drupal web site as an upgrade to an existing Drupal web site with a new layout, design, content delivery system and management workflow. By the time I was put on this project, it had been in planning and development for 18 months. The work took a lot longer than anticipated and the champion behind the project left to pursue other professional challenges. Because the project was only 40% to completion at that point, it was discontinued by the company. The delays in the development (caused by development and in-office politics) ultimately lead to frustration on the part of it's champion, and the project died when he left. In this way, an "endlessly extending" deadline lead to the project not being completed at all.

Then in the middle I was involved in a high profile project for a major institution. The deadline for the project was November 1. As the deadline approached, the employees were given major incentives to put in additional hours in an attempt to get the product ready to ship. Despite these best efforts, the web site was only marginally ready to go live on the deadline date. Negotiations with the client allowed us to push back launch 7 days, and then another 6 days beyond that. The result was a much better end product. While not perfect, the site and related ecommerce solution were usable and intuitive and refinements could continue to be made through the update process after the launch was complete.

The result of this was an extremely happy and satisfied client who spent many days singing our praises post launch before launching into a list of changes and updates, most of which were widely known.

So the lesson here is that it's ok to push deadlines. I believe that delivering "crap" just to make a deadline is not the best policy. Honesty in dealing with clients on deadlines and offering them the opportunity to elect a sub-par on-time launch versus a quality late launch will usually result in the development team having more time. This is, of course, assuming the project had received attention to that point and time wasn't wasted by the development team during the process.

In the end, you can't launch something that isn't usable. It leads to client disenchantment, negative attachments to your brand and reputation, as well as a large amount of stress that typically filters down from the upper levels of management down to the development team. Within reason, new deadlines should be negotiated based on unforseen obstacles, additional tasks requested outside of original project scope, or quality control issues that should be addressed before even the client sees them. Doing so will only get you fired - something that we all want to avoid!