I attended a presentation a couple days ago by Udi Manber, Vice President of Engineering for Google core search. Manber demonstrated why search is difficult, giving interesting example queries such as “how many calories in a pound,” for which the answer is 9000 trillion, since calorie is a unit of energy and pound a unit of mass, enabling the use of E=MC^2 to calculate the answer. While it’s the “right” answer, it’s more likely the searcher wanted to find out how many miles he would need to run to burn off that last Whopper.
In this query and many others, it would be easy to fix it to provide the right answer—hard code it to assume the food/weight interpretation. But that Band-Aid does not address the millions of similar issues and it makes the code messy where piece-by-piece a mountain of Band-Aids grows. Manber said the team often wishes they could just hard code a search result, but that no engineer at Google can move a ranking—they have to actually fix the algorithm—and that this limitation enforces a certain discipline in the development.
In numerous industries ranging from aviation, to automobiles, to power plants, discipline is enforced upon the organizations by the nature of the lifecycles of development. There is no v1.0, v1.0.1, v1.0.2, v1.0.3 in rapid succession, no “just change it on the website” concept. The cycle time of software enables rapid innovation and adjustment but it also allows for a lack of discipline in the development. How does your organization find the right tradeoff before speed and discipline?
