You Want IT When?

Why does it take so long to deliver software products? Many stakeholders ask this question during the course of a software development project.  It’s interesting when the developers ask this question because they know what it takes to implement the functionality in software, but in asking that question, some in the organization often fail to appreciate what it takes to deliver a commercial product to market.  From one perspective, they are correct; it shouldn’t take so long, but from a different perspective, the long duration is understandable — even if undesirable.  I’d like to explore the perspectives that explain these differences using a hypothetical delivery.

Example Requirements

You are asked to build an application that will copy files created for the day from your systems to your customer’s systems.  The files need to be converted into a format acceptable to the customer’s application.  Every night the files generated for the day are copied using the FTP protocol to the customer’s FTP server.  The transfer must complete within two hours.  The communication from your systems to the customer’s will be via VPN over the internet.

Why So Long

This should take a couple of weeks at most — maybe even a couple of days. To convert the files, identify an off the shelf library that will convert between the two file types, and to transfer the files, also identify an off the shelf FTP library to transmit the files.  If there’s good public domain software, use that.  To complete the application, identify the files to transfer, call the method(s) to convert the file, and then call the method(s) to transmit the file. Repeat this until all the files are transmitted.

This is reasonably simple.  It shouldn’t take too long to write.  So why may it take a couple of months to deliver this application?  A college student could probably complete this application in a day.

Why It Takes Longer

The algorithm above works in the ideal case, but errors can arise that need to be handled gracefully.   Connecting to the FTP server may fail.  There may be errors in transmission.  Maybe there’s not enough space left on the destination server to transmit all the files.  These are a few of the possible errors that can surface during operation.  At a minimum, the application needs to detect these errors and report on them.

The entire operation needs to complete in two hours.  This requires that the algorithms to convert the files are efficient.  Some analysis is required to assess whether the third party libraries will be efficient enough to complete the work in time.  Depending on the findings, there may be more design work required to meet the applications performance requirements.

The application has to be supported when it goes operational.  Documentation needs to be created for the operations staff to support the application when it goes live.   When errors happen, the operations staff needs to know the procedures for identifying and correcting the various types of errors.  This is necessary if the developers don’t want to be called in the middle of the night every time the application fails.

There’s a dependency to address for this application before it can go operational.  A VPN connection needs to be configured between your site and the customer’s site.  While this isn’t a difficult configuration to set, the network operations team has a large queue of work, and it will take some time for them to get to this task.

The third party libraries need to be purchased.  This requires identifying and evaluating the products, submitting a purchase requisition, placing the order, and waiting for the software to be delivered.   Just these steps alone can take a couple of weeks.  If the software is unavailable for download, this will be a dependency since coding cannot complete until the software is in your hands and installed.

End-to-end testing needs to complete with the customer’s application that consumes the files transferred.  In the ideal case, it’s a day or less of work if everything works well, but if not, analysis and troubleshooting are required to find and correct the problems.

Summary

Too often when stakeholders ask the question, why it takes so long, they naively look at the feature to deliver and rightly conclude it can be completed quickly.  However, there are more requirements to address than the simple algorithm that delivers the primary functionality.  Not only does the application need to work in the ideal case, it needs to handle error conditions correctly.  Performance requirements must be addressed, and depending on the variables, this can add significant development overhead.  There are support requirements and network configuration requirements, which contribute additional overhead to the assignment, as well. 

Many of the requirements that add to the project duration aren’t visible to the stakeholders asking the question, and consequently, they aren’t calculated in their optimistic view of when the assignment should finish.  So if you are still asking why it takes so long, it’s only and FTP application.  What aforementioned aspects of this assignment would you leave out?  Usually, there’s a good reason it takes longer than we’d like and even expect.

If you liked this essay, you may also like the following related posts.

• Reflection: Unrealistic Schedules