Deliver first, develop later
No matter which workflow is chosen by a team, there is one common flaw: the product is shipped only when it’s done.
In this context, it is not surprising that many products fail to be delivered on time. The delivery process is both complicated and random, like any other process which is not automated. By postponing the delivery until the end of the development, developers pass over the risk related to the delivery process and the time it takes to do it right. In order to mitigate the risk of not delivering on time, one should deliver straight from the beginning, before even starting to develop the product itself.
When I work on projects of web applications, I often see customers giving an access to the production server only at the late stages of the development. Sometimes, it happens like this:
Developer: I finished the project.
Customer: OK. Can you publish it now on our server, please? I’ll send you the credentials this evening, and I need the website to work flawlessly tomorrow morning.
Recently, I was working on a project of an ASP.NET MVC 3 website. While staging environment was missing, I was able to do the first delivery a few months before finishing the project. The process was smooth, but it still took me one day to:
Configure the server; create the appropriate accounts, etc. I still don’t understand why, by default, the hosting provider tries to do whatever possible to make it the least secure possible, nor why every customer is convinced that using the administrators’ account and giving its password to everyone is the most exciting thing in the world.
Install the most recent updates for the first time. Thanks to Microsoft, this task alone takes a few hours and requires constant reboots and human presence. Of course, the hosting provider (which is by the way the most popular one in France) has no idea about snapshots. I’m wondering if they still install Windows Server by hand and never heard about AIK.
Setup, configure and deploy the database.
Configure the ability to publish the project from within Visual Studio.
Try to make it work, given that the project has a lot of dependencies, and that the freshly installed ASP.NET MVC 3 on the server is not the same as the freshly installed ASP.NET MVC 3 on a local VM. What a pain.
While I spent one day doing all this stuff, an experienced system administrator could partially automate all this, but would still waste a few hours.
Once done, the project should itself needs to be modified. It appeared that there were a few bugs with the application which existed only on the server, but never occurred on my own machine. Moving from Entity Framework 4 I have on my machine to EF3 was surprising too, since I hit a bug which was solved in the newest version of EF, but still existed in the previous one. Finally, some minor discrepancies were highly disturbing as well, such as the Server Error page sent under a form of a bunch of random symbols, probably GZip with a wrong Content-Encoding response header.
The issue is not exclusive to Microsoft’s world. Every time I had to publish to a production server a website written in PHP, I encountered at least one issue due to the configuration being different or the server using the version of PHP published four years ago.
By postponing the delivery, you postpone both the issues which will arise during the delivery and the work required to configure the server. If you’re given the credentials to the server this evening and the website should be running tomorrow morning, you (or your customer) should take a course on risk mitigation.
While server environment could easily be controlled and duplicated (in order to create the staging environment), the case is different for desktop or mobile software products. When released in the wild for the first time, those products will be confronted to the plethora of operating systems, user’s settings, bad configuration, diverse hardware, sandboxes and environments with restricted permissions, hacks, viruses and human stupidity. Either it’s solid and ready to fight, or it’s not.
You should and you can deliver immediately. All you need is to create an empty project or a hello world, ready for delivery. It will make the customer happy, and it will prepare the seamless delivery process. Ideally, you’re using some agile workflow to deliver on regular basis, so that the customer is up to date on the development progress.
Some people believe that the customers will accept negatively such early delivery. Nonsense. Every person is happy to see that her project is finally started, and that what was primary on paper starts to be transposed into a live website, or a live application which can be downloaded, installed, touched. You can see and feel it, and that’s great.
Functionality doesn’t matter so much. Features change all the time during the development of the project, in all cases.
The most basic Hello World for iPhone is much more valuable compared to hundreds of pages of paperwork describing the architecture and the design of the app, or to the promise “We are working on your app internally and will deliver soon”. Remember that until you deliver, all your work is fiction for the customer, who doesn’t even know if you actually started the job or are still procrastinating and inventing some fancy reasons to now show your work.
This is what is currently done for the Omega project, since the delivery was done first, before the first page was implemented. This allows us to show the progress nearly constantly, while being sure that there will be no major issues when deploying the next revision of the application, and at the same time be encouraged: since there is already something on the server, it means that we are working on a concrete product which already exists, not something fictional which may never reach our production environment.