After my post on underestimating the ubiquity of data, Jeff Biggar asked me to expand on my predication that prediction that “business practices and marketing will take a back seat to quality and value to society.”

You can see my response there, related to a paper that I wrote last year, but today I’d like to relate this to Willard McCarty again, once again from the narrowed scope of only computing. This is partially for posterity, as his notes greatly overlap with mine, and I’d like to return to them if I ever find myself polishing my paper.

McCarty notes that we’ve seen the “gradual transfer of ability to construct artifact from highly specialized technicians to ordinary users, and the simultaneously increasing technical sophistication of these users”, or DIY computing. This has happened mainly due to three reasons: the regaining of computing unity through networking, the development of operating systems so as to free users from higher-level tasks, and an amateurization in the nature of software (notably the introduction of lower-level programming languages).

These three points provide a premise for the trend of increasingly content-driven computing. When more people are able to create, more are likely to do so when there is a necessary artifact. However, McCarty’s point on operating systems is important as a generalized rule: freedom from higher-level tasks. Rather than many people reworking the same problem, why not standardize the solution and let them worry about other things? The operating system takes you partway there, software libraries and modules take you further. A JavaScript library such as JQuery, for example, lets web developers stop worrying about JavaScript compatibility between browsers by offering it’s own functions, which it then translates properly into JavaScript based on the quirks of whichever browser it’s running in. Ruby on Rails is another web technology that builds on sensible defaults to allow users to skip higher level concerns like full links between their modularized code, full functions for common tasks, or complex server interaction. Consider that Twitter was originally built on Ruby on Rails. Twitter was a very novel concept and – as those who’ve tried it can attest to – is hard to understand in strictly abstract terms. However, Ruby on Rails allowed the creators to create Twitter as a side-project, with time away from their day job, and experience the new concept.