Taking the Status Quo for Granted

Software developers often take the status quo of the software industry for granted, aiming no higher in their solutions than the standards set by their community.

Let's take web programming as an example. In order to build web applications for clients or companies, most developers out there strive to master the standard web technologies: XHTML, CSS, Javascript as well as a back-end programming language+framework such as Java+Spring or Ruby on Rails.

However, once developers are comfortable enough with building web applications, they often seek ways to increase productivity and quality of work (performance, reliability, security, ...) through changes in software development processes and/or technologies.

As far as software technologies though, I've observed that developers too often only think of improvements that are incremental and within the box of what they normally do as opposed to outside the box.

What are some examples of in-the-box thinking?

• You have to program in two languages, one on the server and one on the client, in order to build a web application successfully.


• Despite your best efforts in adhering to web standards, you ought to spend time dealing with many browser-dependent issues while in the midst of building business web applications.


• You have to think about the low-level HTTP protocol details every time you build new business features in order to map them into service requests according to the web resource-oriented architecture.


• You have to code URL history management for Ajax calls yourself (with the aid of some library like YUI Browser History Manager or Really Simple History) to ensure that the back button and bookmark-ability are not broken in your shiny Web 2.0 application.
  

Having listed a few examples of in-the-box thinking, one may wonder "What is the box exactly made of?"

The box is made of all the currently assumed constraints that seem unchangeable, such as available development technologies, team values, and quality standards set by the client.

How do you think outside the box?

Thinking outside the box is an exercise in which people temporarily drop some (or all) of the assumed constraints and imagine how things would go about instead in that alternate reality. It is an exercise in creativity and imagination, and while it may yield some ideas that are not feasible in reality, it often yields other ideas that make people realize some of the assumed constraints are indeed changeable.

This is in fact what some luminaries in the Java world, such as Rod Johnson, did when they envisioned successful enterprise development without the constraints of EJBs (Enterprise JavaBeans). That's what DHH (David Heinemeier Hansson) did when he envisioned simplified web development relying on conventions instead of endless configuration files. That's what Google did when they built GWT (Google Web Toolkit), a framework that abstracts all the web low level details from developers.

In any case, often developers reject out-of-the-box solutions because they are not mature enough yet. For example, I know quite a few developers that are not very fond of GWT despite the fact that it offers these benefits:

• Simplifies the problem of web development by abstracting it to its essence: programming on the server and programming on the client with data passed back and forth in between. This has been successfully solved for desktop applications in the 90s with one programming language, so why have developers deal now with co-incidental technologies like XHTML, CSS, and Javascript?
• Unified debugging interaction for client and server making it very easy to trace data moving between them without having to context switch between many different syntaxes and technologies
• Abstracted all browser-related variations saving the developers from a huge burden in web development. Isn't that the premise of abstraction in software after all?

The reasons GWT is not considered a mature solution by some developers though are:

• Does not render web-standards compliant XHTML/CSS as it relies on the frowned up abuse of HTML tables to do layout


• Relies on the imperative Swing-like Java syntax to layout widgets, which is considered archaic nowadays compared to using DSLs that map closely to the visual layout, like Groovy SwingBuilder and SWIXML (or even good old XHTML)


• Of course, there is the learning curve and the fact that developers would have to remember to debug through an IDE instead of a browser debugger like Firebug. So, traditional web developers are kinda out of luck until they learn the new ways, but veteran desktop developers would be fine.

Still, the reason I bring this example up is because often when people get frustrated with a technology like GWT, they go back to accepting the status quo and working with solutions that are in-the-box as opposed to fixing the problems with the new out-of-the-box solutions.

The few that do persist and go beyond the box though end up with solutions that completely shatter existing expectations. For example, the Java language in its early days was considered by many developers as outlandish and impractical in comparison to writing code with a language that hits memory directly and works close to the hardware, like C/C++.

Who's making all the money now? :)