Crunch came to an end last Friday and I'm reflecting on the way this cycle ended compared to others in my career. I find myself missing writing desktop and server-based applications and their distinct ends. I wish for the the real sense of closure and accomplishment that comes with releasing a product.
Web applications, like Salesforce, Google Apps, and now Photoshop, have a development cycle much more like the old custom built IT application running in a lumbering insurance company. There is no definitive end of a development cycle because the product doesn't end or even pause. The product is a service depending upon subscriptions for revenue and like all subscriptions, suffers from customer churn. The service must continually evolve as customer's needs evolve or people consider moving on to a competing service. The development cycle can only come to a good deployment point and then almost immediately begin working on the next service evolution.
Many developers would argue that a constant development cycle is true for all products. That finishing a release of a desktop application is followed by working on a point release or a service pack. They are right of course: there is always more work to do from deferred bugs and new support issues. The difference is the urgency of the point release and the lull as people figure out the high priorities for the new release.
Web applications may not have this lull. They may follow a 6 week Agile-styled iteration cycle, which means that the iterations are planned well ahead of their actual start. This project planning keeps the feature and bug queues filled at all times so development always has work. The short period of the cycle, 6 weeks in our example, means that the product plan can still be reactive to customer needs in the next iteration, without having to dramatically shift priorities in the current iteration. This regular development and release process keeps development moving forward at all times with no break.
A positive outcome of this cycle should be that the pace of development remains nearly steady through the year. In practice, pace changes from one iteration to the next depending on the urgency of a bug fix or a feature and staffing levels. A good pace is critical in any development organization as too fast a pace means that people are working very long hours and too slow a pace means that people are bored from the lack of work. My ideal pace is where I am coding around 5 hours per day. A book called "Peopleware" helped quantify it further, in the first hundred pages, by describing "Brain time vs. Body Time." The idea is obvious, you can only concentrate and produce effective code for a certain number of hours per day and then everything goes down hill. A developer may be there for 8 hours and produce 4 hours of high quality work and the other 4 are buggy or ill-conceived. Five hours for me is about right, but only because I like coding for that amount of time, I am not saying that the code produced during that time is good. It wouldn't shock me that the quality of my code declines as the day goes on.
The core problem is that there is no significant finish line or amazing achievement when you are developing incremental improvements. The sense of accomplishment either fades too soon or is not there at all.
Releasing a desktop or server application has an indelible sense of closure: the release is done. I may have had to go through a long crunch and worked very hard to release it, but it finished and there is time to catch a breath and feel like something significant was accomplished. There is a finish line.
The scale of the project clearly impacts the feeling of accomplishment. A short iteration's worth of features and bug fixes is no comparison to 6 months or a year's worth of effort to release an application regardless of it being managed in a waterfall or agile scheme. It's exciting to release a big project.
0 comments:
Post a Comment