I had a funny situation recently that really illuminated the value of self-hosting... also known as "eating your own dog food" (not my favorite expression but one everyone seems to use).
My team recently created an experimental Ajax web application. It got cool enough that I thought the broader team could start using it to support some of our day-to-day work. So I pinged the IP address to a colleage in Zurich and asked him to check it out. A few minutes later he pinged back with a message "looks good, but it took three minutes to load". My jaw dropped, because on my computer it loaded darn-near instantaneously. The problem was that in my development environment, the HTTP messages where traveling between components in the same laptop, whereas in my Zurich colleague's case, the same messages were traveling from Zurich, Switzerland to Raleigh, North Carolina, USA - across thousands of miles and many network hops. Our cool new application was now a red item on the "architectural issues" list, as in:XYZ app - load time unacceptable over wide-area networks (owner: Bill)
So we spent a couple of weeks re-thinking the architecture to package the application in such a way that reduced latency, resource size, and made resources more cacheable. This led to a greatly improved performance.
While we were doing our performance work, I got a friendly note from one of our project leaders saying that he'd been to a Rational Development Council meeting, and another group talked about an Ajax application they were creating, which by all reports was impressively performant. My project leader suggested that I meet with the other team to find out what steps they'd taken to achieve such great performance.
I scheduled the meeting, and in between scheduling and having the meeting, my team completed the first part of our afforementioned re-design and achieved the afforementioned performance improvements. I finally had the meeting with the other team with the "highly performant Ajax application". When I told my story about crappy load-times across the Atlantic, they said "Hmm, we've never really tested our application over really wide areas". We proceeded to spend a good bit of the call discussing the performance engineering steps that we'd
taken in the past several weeks to improve our
So the moral of the story is that because we wanted to use the app to do day-to-day work, and because our team is geographically distributed, just as many of our customers' teams are geographically distributed, it forced us to experience real usage patterns, where people do not
always sit in the same building and in some cases do not even live on the same continent. Our realistic usage illuminated a serious design flaw and got us on the project's "red list" for a number of weeks, which was very strong motivation to get creative and deal with the performance problem. Not to mention that it was just plain embarrassing to have an application that was slow to the point of not being usable in Zurich. The other team, which had not yet tried to self-host their application, got kudos for their performance, but it was based on an unrealistic usage assumption (always running in a local network) that would not have held up over time.
Self-hosting in a realistic manner is invaluable for smoking out unrealistic usage assumptions as early as possible. As the agile wisdom says, you need to locate and attack the nasty lurking problems, rather than letting them quietly fester.[Read More