Greg Crisp

The Delivery. Alternately known as “going live” and “shipping it”. The act of completing a product and making it available to the intended user, if such a thing as “complete” is even possible in modern, technology-based goods and services.

I once attended a seminar by Edward Tufte, who pointed out that the technology industry is one of only two that refers to its customers as “users”. This is no coincidence, as many in the trenches of the technology product world have about the same level of caring for their customers as those who work in that other industry.

So many in this business are focused on the “end goal” of The Delivery, yet they fail to miss the point: The Delivery is not the end, it is the beginning. The Delivery is the birth of the product. A successful product has a life beyond delivery, and perhaps even a death.  All of this is what most in the technology business call “Maintenance”.

All that development work you did…

• …on your localhost Web server…
• …in your Integrated Development Environment (IDE)…
• …downloading test code onto demo devices…
• …working with contrived test data (probably skinny test data at best)…
• …probably with less than 2.5 end-users ever in the system concurrently…

…that was like the nine months we all spent in our mamas’ bellies. The real, interesting stuff begins after The Delivery, when you ship.

IDE (Integrated Development Environment):

1. “a software application that provides comprehensive facilities to computer programmers for software development.” – from The Wikipedia
2. Code that helps a human make more code
3. Something that sounds like a birth control device that is uncomfortable when inserted

It is after delivery that you get real people in front of your web site who aren’t aware that if they hit control and the Q key, it will kill their browser before they can save a copy of the document they just wrote. It is after delivery that you get real people holding your device that don’t intuitively understand the big, round circle at the bottom of the screen is what they should press to get back to the home page. It is after delivery that you get real people in your system who don’t know which buttons not to push to prevent your application from failing horribly with a great, big dialog asking if the evidence of your feeble coding skills can be mailed to the OS vendor, where the systems geeks will laugh in derision at someone stupid enough to try to dereference a null pointer without first checking it.

Software Development Life Cycle (SDLC):

1. “a structure imposed on the development of a software product.” – from The Wikipedia
2. A hypothetical five-phase process theoretically used when building software. The phases are typically some semblance of: a) Requirements gathering, b) Design, c) Development, d) Testing, and e) Maintenance.
3. A process created in an idyllic time when people had the illusion that software products are ever truly completed.

In all of the “five phases” diagrams I’ve ever seen, the ever-present Software Development Life Cycle (SDLC), there has been one serious flaw. A flaw in understatement of the full product cycle. Every SDLC diagram I’ve ever seen has maintenance as a small, sliver of an afterthought, taking place shortly after the typically under-estimated “Testing” phase. Others are worse, and don’t include “maintenance” as part of the main cycle, but instead as a separate thing, existing outside of the ‘core’ SDLC. In any case, the PLANNED ‘maintenance cycle’ is typically at best 25% of the overall timeline, and often diminished to as little as 10% of it.

In any IT group, software development shop, or product development team that ever had a successful product (meaning: people actually used it continuously over an extended period), the ACTUAL ‘maintenance cycle’ is much longer than the other 4 ‘cycles’ combined. The maintenance cycle typically also includes several mini-cycles of product development, where new features are added and bugs are fixed. This is true of any product that does not fail in the marketplace, and even of some that do.

What sort of things might you uncover after your product ships? Here are some real-world examples:

• The registration process you spent days designing on the white board turns out to be too complicated. No one gets to the point where they actually put in their payment info.  Or they do put it in, but fail to notice the last “Place order” button, so it never gets processed.
• Your junior developer chose to use their own regular expression to validate email addresses (instead of a standard one).  People whose email addresses have a dot (‘.’) in them before the asperand (‘@’) cannot sign up for your service.
• The Javascript you were getting from your ad vendor in development looks completely different from what you get from their production servers.   Your parsing code made flawed assumptions based on this, and your ads disappear.
• Someone has a contact in their buddy list that has a funky character in the name.  This character, while handled by your message routing software, causes your database server to crash horribly when that customer imports their buddy list from the old service.
• The software that manages your online gambling system has an off-by-one error.  This results in several million dollars in money going to players, when it should have gone to the house.
• An engineer who left the project failed to check for a null pointer before dereferencing its object, causing the system to crash the app server every 7th or 8th time someone logs in. [One of my personal favorites. - G]

I could go one, but you get the point. Many of these would never have been found in a lab. Ideally, they should have been found during product testing, but the level of effort to test this extensively is often cost-prohibitive in the typically rushed product development timeline. It was only by shipping product, and getting it into the hands of real people using it in real ways that these bugs were uncovered. Rather than worrying about it, plan for it. Plan for the full life of your product, not just its gestation and birth. Expect that you will uncover new problems when you ship, and have an adaptive plan to deal with them. More on that soon.

Now, stop wasting time reading blogs, close your web browser, and go make something. Then ship it! Get it into the hands of your customers.  Then make it better, for as long as people want to buy it.