Why Johnny Can't Write

Well, there are several factors in the way:

1) Magazines, particularly print ones (more so than online, but online pays less) have limits on sizes. Too much information either is weeded down to too little information, or packed down into too dense a read, even over a good lunch break. Few writers want to make the commitment to a series of articles on a topic, since they have the concern that halfway through the series, their day-job will take over and they'll never be able to come back to it (i.e. David Geary and PTRPH's plans for a 4-part JFC/Swing series, terminated when he switched to doing web apps instead of desktop/applets).

2) Too much time taken, on the part of both editors and writers, to repeat the basics. Often, even in JDJ, I've seen articles that go back to square one on a topic; many "Model 2 MVC" web app articles spend the vast majority of the time re-explaining MVC in JSP than actually doing something productive. JDJ's sister XML magazine is even worse in this respect, constantly spending at least 2 issues a year re-explaining XML or SOAP or Web Services or whatever buzzword for the umpteenth time.

3) Domains are limited for generic examples. Do we need yet another "web store front" example for combining databases and web apps? Right now, the internet seems to be entirely composed of blogs and web stores because any other domain one might write about is either too limited for generic extraction and application (oh, and a web store isn't?), or too proprietary to the company's core business, leading to other

4) Proprietary issues. Often the writer finds his hands tied due to his contractual obligations with his day job. He may think his solution-x to some problem-y is spectacular and innovative and all that, only to find that his desire to publish on it is hampered by his company's desire to keep that technology or approach a trade secret, or an even more valuable patent.

These factors all limit what people can write about, and thus creates the current situation of everybody writing about effectively the same things over and over again.

One of the things seriously missing in the IT literary world is that of how to evolve products/projects. Everything a relatively new programmer sees is either the "brain-dead demo/example", a few lines of code that may or may not be useful or right once he cuts-n-pastes it into his own code, and the "framework from hell" (Struts, Jigsaw, J2EE EJBs, Cocoon, to name a few) apps that consist of thousands upon thousands of lines, with little clue in the way of corp memory of how the app/framwork ever got that big in the first place.

The alternative is the Best practices approach, made famous by Meyers's Effective C++, and recently a big part of O'Reilly's J2EE-related works. But even then, those are small examples, put into an artificial context, that show a little cleverness, but no real serious thinking. The trick to the reader of those works is to actually remember the damned thing once the situation actually crops up in his own work.

Sadly, this rarely happens, just as it rarely happens that someone will look to reusable libraries like Jakarta Commons or other online code archives before going and writing his own Component to do such-n-such. The programmer simply can't remember everything he's read about anymore...

John Lakos's Large Scale C++ Software Design (AWL, 1996) is a good example of what I'd like to see, but its focus is too heavy in C++ idiosyncracies to be generically applicable (i.e., dealing with templates, duplicated generated code, makefiles, namespace collisions before namespaces became standard).