March 2009 Archives
Publishers take heed: If you don't have the content, the readers won't come.
As a publisher of developer-related content, I spend a significant amount of time researching technical topics, and I also spend time evaluating how others reach the content we publish. It turns out that an overwhelming percentage of our audience reaches our content via search.
Not by browsing to a site directly and seeing what's new.
Not by clicking links in newsletters.
Not by clicking links on other sites.
Not by clicking links in RSS feeds.
Through search.
Because this is DevX, you can be pretty sure that the searchers who land here are developers looking for specific pertinent developer-related content—in other words, they use search the same way and for the same reasons I do: It's the fastest way to find what you need.
But for publishers what this means is that the old adage "Content is King" is more relevant today than ever. It also means that branding is becoming increasingly irrelevant. For example, despite the presence of search boxes on most modern sites, people rarely use them; unless they know the information they need was published on a particular site, they gravitate toward one of the major search engines instead. That's because it's usually a waste of time to search a specific site when you're interested in information rather than presentation; the information might be anywhere on the web, and you're far more likely to find it quickly by searching the entire web rather than a single site. I do browse—but only when I'm not looking for something specific.
Reaching content through search also means that site organization isn't particularly important. I rarely care, notice, or even see whether publishers arrange their material by language, technology, publish date, author, or whatever other categories they might think readers want. Browsing is slow and inefficient. Searching is fast and—with the right search string—produces near-instant results.
However, while organization isn't usually pertinent, presentation is. Because the goal is to find and absorb material as fast as possible, I tend to avoid sites that hinder my searching by being unusually slow, prefaced with popup ads, or that use any other marketing technique that's intended to get my attention, but usually just results in my looking elsewhere. Again, content is king. If the only site with the information I want has irritating marketing, I might suffer through it to get to the content. However, if there are multiple sites with the information, I'll find one that's less intrusive. With the size of the web today, most information appears in multiple locations, so I rarely have to endure in-your-face marketing or poor presentation. The result is that I don't much care where the information is, just that I find it.
The cold hard fact is that for the past few years, I've rarely even given the URL in search engine hits more than a cursory glance—I'm interested only in the content. Sure, for technical content the combination of the search hit text and the URL usually tells you whether you're about to view a blog or a tech site, but frankly, I rarely care. If a link looks like it has the content I'm after, and it's not on my list of sites with poor presentation or bad marketing, I'll hit it, regardless of the branding.
I suspect I'm not alone.
- Advocates of traditional software development approaches, such as waterfall and V-Model, are myopic bureaucrats who worship detailed specifications and denigrate the code necessary to build those specs.
- Agile development practitioners, on the other hand, are logical pragmatists whose only goal is to build what the customer wants.
In a parody of the Apple television ads where a hapless businessman personifies a PC and a know-it-all hipster portrays a Mac, Ambler and Quatrani debated the relative merits of traditional and Agile development models. Ambler, the practice leader for Agile Development at IBM, played his Bizarro doppelganger: a staunch traditional model supporter (the PC). IBM Rational Evangelist Quatrani portrayed an Agile proponent (the Mac). The results were much like the TV ads: the brain-dead PC always played the fool.
Watching Ambler mock the traditional approach was good for a few laughs. He sarcastically advocated detailed specifications with complicated models that an architect could throw over the wall to the "programming monkeys," who he joked are good only for writing code exactly to spec and documenting every detail as they go. All the while, Quatrani countered with Agile's iterative, test-driven process, where stakeholders are involved and the spec evolves as the team targets working code for each iteration.
In the second half of their talk, Ambler and Quatrani traded comedy for statistics, presenting some data to validate their pro-Agile satire. Based on surveys of Dr. Dobb's Journal readers (i.e., developers), the data compared the project success rates and effectiveness of the Agile and traditional development paradigms.
Considering the source—people who may have an axe to grind against a model that elevates the architect specialization while relegating developers to "programming monkey" status—I took the survey results with a grain of salt, but they still revealed some interesting tidbits. For example, the vast majority of modeling is performed by sketching on a white board or paper rather than by using software-based modeling tools. Also, while Agile came out ahead in most categories (surprise, surprise), the traditional model had a higher success rate in distributed development. Ambler admitted that Agile teams don't know how to do distributed Agile yet, and claimed the available tools aren't helping them.
The traditional-versus-Agile debate is nothing new, of course. Six years ago, an editorial by the DevX editor-in-chief at the time titled "Are You Passing the Requirements Buck?" prompted vehement rebuttals from a DevX author and even Scott Ambler himself. Since then, DevX has published editorials on the thorny developers-vs.-architects issue, from the polemical (David Talbot's "To Software Architects: Serve End Users, Not Your Egos," December 2004) to the conciliatory (Andy Schneider's "Bridging the Divide Between Developers and Architects," July 2006).
I sat in on Ambler and Quatrani's keynote to get a sense of whether cooler, more pragmatic heads had prevailed. I ended up more entertained than informed, and left with the impression that the debate remains as religious as ever.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |










