With the establishment of
Web 2.0 many start-ups and companies seem to be developing a new set of web development practices. New ideas about Web applications seem to necessitate new ways of making those applications.
According to a great number of developers, their job is not to develop one
application, but instead to develop two - the public-facing application, and the private application. It is also called the "shadow app" and it helps the company understand how the first application is working. Of course, statistics packages and traffic monitors are not new at all, but these companies are explicitly rejecting any standard, pre-packaged code for this purpose, and are instead asking the questions they need for their specific businesses. The direct connection to the users provided by a
server-hosted web app only gives you more data if you know what questions to ask, and building those questions is often just as important as building the public application itself.
With tens of thousands of site visitors a day, or many more than that, the entire structure of engineering discussions has shifted heavily into the realm of statistics and controlled experimentation. Feature selection feedback loops used to take months or even longer and usually, the arguments about the right decisions were made nearly in the dark. The best software organizations made decisions based only on what customers said they wanted, which is often much different from how those same customers really act when presented with a new feature. With live sampling and testing, developers can see how many clicks the new feature really got.
Many web app start-ups provide
APIs, so external developers can build apps on top of their functionality and data. But there are many companies that build their own public-facing web sites second, by building on top of a web services API they develop first. So, all they have to decide is which of their existing method calls they want to expose to the public. They already know the methods work, because if they didn't, the public web app wouldn't work, either. In addition to "pre-testing" the API release, this also allows a very clean separation of responsibilities. While some developers works on the application's "
kernel," exposed through the API, others work on the "view" the company exposes through its web site.
More and more web start-ups seem to be explicitly opting out of formalized
quality assurance (QA) practices and departments. Rather than developers getting a bundle of features to a completed and integrated point, and handing them off to another group professionally adept at breaking those features, each developer is assigned to maintain their own features and respond to bug reports from users or other developers or employees.
Often web developers and executives provide the support of the web applications. Companies found that the best way to motivate developers is to let them see just one e-mail deriding the bugs in their work and to make them respond to complaints directly.
Following Google's lead, many companies stick "
beta" on their logos and leave it there for months or years. The concept of "beta" as a time period or stage of development has fallen away, and been replaced with beta as a way of setting expectations, or excusing faults, about the current state of the application. But this is just the externally-visible product of all the practices listed above. If you're going to rely on customer reports for QA, you're going to change the operation of the app, however subtly, multiple times a day, and you're going to introduce features to a small set of users, and then take them away at the end of the day - the experience your users will have is fundamentally different. "Beta" is one way of alerting them to the new regime.
About 3rdeye
