At my current position and the previous one, I’ve worked on shrink-wrapped Rails application that are meant to be installed onto an enterprise-customer’s network. For want of a better name, I’ll call this an enterprise rails app. This is the dark matter of the Rails installations – we don’t know how many there are since they are only seen by the enterprise users. But I think there are a lot of these enterprise applications and I’m beginning to see some differentiation from the customer-facing sites that we go to every day.
Release Cycle
At a consumer-facing site, you can push small updates on a daily basis. The users see a gradual evolution over time. Contrast this with the enterprise Rails site, where each version goes through months of development before any customers see it – and its a big jump when they do. Hopefully the big jump is in the right direction – an improvement – but its hard to guess right every time.
Development Cycle
The development process for the two types of sites reflects the developer’s needs. An enterprise app only needs to be perfect once or twice a year, when it is shipped out the door, whereas a consumer-focused site needs to be bug-free every single day for every single user. This leads to radically different development strategies. For a consumer-facing site, the agile processes of making small fast changes with solid test coverage is about the only way to stay sane – lack of tests means unexpected late-night debugging while user’s stare at a fail-whale. Enterprise developers, while they may talk about TDD and agile, have no need to actually practice it since they have months to fix issues that creep in.
Death by a thousand Demos
The final area where this difference in process manifests is in how the business needs mesh (or don’t) with the development team. As a vendor to an enterprise-level company, we’re expected to periodically provide a “demo” version of the site to display at trade shows. This demo-ware needs to look like the final product and work, at a cursory level, like the final product – but it doesn’t need to actually work in a full and complete way. Smoke and mirrors is the name of the game when creating demos.
A consumer-facing site has no demos. What you see is what you get. It either works or it doesn’t – you can’t hide your failures from the user.
Developer Practices
Given the disparity in business requirements, its no wonder there is a huge difference in developer practices. When end-users are always using your site you have little choice but to use best-practices: test everything, keep all the tests passing, leave little development debt. When the end-users won’t see it for many months its easy to get lazy (I’ve done it): let the development debt pile up, rely on QA testing since you didn’t take the time to write automated tests, hope QA will catch all the bugs – but pay the price in rework and bug fixing long after you thought you were long done with with writing that code.
I’m curious to see whether this dichotomy will ever change. Maybe it already has somewhere. As one of my favorite authors says: “The future is already here, its just not evenly distributed”.