Berry

In a project I am currently part of we are using Scrum as an agile development method. In each short iteration of 4 weeks we are building a working webapplication. The advantage is that the customer can see a working example (a preview) of the final application within a very short time after the project has started. With traditional project methods the first time a customer would see a working example typically would be towards to the end of the project.

To be able to quickly build working versions of webapplications you need the right tools. Tools that give you the power to quickly build a website, to show it to the customer and be able to easily make changes. Still, the tools need to be serious enough to build complex and maintainable applications.

What are those tools? That's a question that's been bugging me for a while now. Does it matter which database you use? Does it matter which programming language you use? Does it matter which (information) architecture you adhere to?

For example. Most people will argue that you can build anything with any programming language. I think this is not true. And I am certainly not alone in thinking this. Some programming languages are more efficient for building webapplications for example than others. Especially interpreted languages like Python, Ruby, Groovy, Lisp, etc. seem to be much more efficient than compiled languages like Java or C#. Especially young internet startups flock to these interpreted languages. Primarily because you can quickly build your first iteration of your idea. Put it on the web and create an audience for your application. Listen to your audience and then quickly modify your application as your audience and your traffic grows. The tools used by these startups seem to help them to get quickly up and running and the tools also seem to be able to help them when their business grows. So, I keep a close watch at the tools young startups are using. And interpreted, dynamically typed programming languages seems to be a more efficient tool for building web application than compiled and statically typed programming languages.

Still, existing enterprises and governmental departments do not seem to see this trend. Or perhaps they do see it but do not know how to act on it. Most enterprises are still focused on the more traditional toolsets like Java EE, .Net and traditional RDBM's. These tools have served them well in the past. Complete departments exist to build and maintain applications build using these tools. And it is very understandable to use the tools that served a company so well to also build the company webapplication with these tools. But webapplications have their own dynamics. Especially public facing webapplications need tools and information, software and hardware architectures that scale well beyond the traditional requirements of a business application. The time-to-market for a public facing website needs to be very short. You need to be able to pick up a trend and quickly build an application. You need to be able to make changes to an existing website quickly and often. Your customers expect this and will appreciate and reward you for this. So, as a company you need to have procedures in place that make this possible. Traditionally changes to an application take "for ever" to test and deploy. So, traditional enterprises and governmental departments need to adept themselves to these new trends.

One of my personal goals for 2009 is to make (traditional) enterprises and governmental departments aware of the trends in webapplication development and to make them aware of how these new toolsets and new ways of designing your information architecture (ie. REST) can help a company to meet their goals more quickly and more (cost) efficiently.

This was a long introduction to what I really wanted to share with you. This week there is quite some talk on the internet about two trends: schemaless db's and new in-browser visual layout design tools.

First schemaless databases are gaining popularity. The reasons: very quick reads, high-scalability, supports agile development, changes to database schema are easy (because their is no schema). There must be a trade-off and that is there are no in-database relations defined. Relations between data is defined much more ad-hoc. More hypermedia like. If a relationship must be maintained this is usually done in easy to read code. Schemaless database tend to be very lean and mean, easy to use and to maintain. Examples:

• CouchDB - a project by Damian Katz. Build in Erlang, data format in JSON, indexing done using map-reduce functions defined in javascript and last but not least a REST API accessible via HTTP. This project seems to use all the best technologies that "the internet" has given us.
• Friendfeed uses MySQL to store schemaless data. And it has given them an easy, scalable and stable database.
• Tokyo Cabinet - a very, very fast key-value database from Japan. This looks like very seriously cool technology.

And unlike a lot of existing layout editor availabe today, Atlas is not a code generator. On the contrary, Atlas lets you edit the live JavaScript objects in memory and then takes a “snapshot” of them in place.

Loading mentions Retweet