Werner Vogels on Amazon Cloud

The next web linked to a really interesting presentation by Amazon’s CTO today: Amazon’s CTO: “Amazon is a technology company. We just happen to do retail”.

Lots of interesting information here:

  • Scrum & Agile – small teams, fast innovation, all teams are customer focussed. How to scale.
  • Architecture – what’s important when architecting large scale applications. Ideas behind doing SOA
  • Cloud – impact of cloud on enterprise software development
  • Business – lots of companies are transforming into IT companies, even if they don’t see this yet. This causes problems because they should put the best possible people on their most important assets: software
  • Operations – No separate operations department. You build it, you run it.

Werner Vogels: Amazon and the Lean Cloud from HackFwd on Vimeo.

Using the Backbone router

Derick Bailey has some good advice regarding the backbone router: Stop Using Backbone As If It Were A Stateless Web Server.

A javascript application using backbone is stateful, and implementing MVC doesn’t mean that all actions have to be handled by the router. Only use the router when you want to expose a url in your browser history, something the user can bookmark or email.

I think it’s useful to look at it from a REST perspective: a url is an id or address of a resource. Use the backbone router to create urls to things that are resources, not to actions on resources.

When will we dump server side web frameworks?

Single page web applications have been around for a while. Applications that run all user interface code in the browser using Javascript to update the user interface. The application server only exists to provide access to data and business logic.

However, most Java Enterprise web applications i encounter still use serverside web technology like jsf, seam, wicket or similar. It’s not like these frameworks are perfect. Heavy weight on memory usage, problems with history and back buttons, complex lifecycle to maintain state, complex model split over multiple tiers.

Why are most enterprise web applications still using server side webframeworks? Some years ago I wrote a single page web application, mostly using JQuery (Here’s a presentation I did for nljug in 2008 about this project: Client-Server 2.0 using JQuery and Grails).

Today, the javascript frameworks to support single page webapps have matured a lot: we have MVC frameworks like backbone.js, UI component frameworks, javascript templating, QA tools like jslint and google closure linter, unit testing frameworks like qunit and jsunit, and documentation tools like jsdoc and docco.

So a full set of frameworks and tools to create single page webapplications exists. What is keeping us from using these for enterprise web applications?

On these Windows Explorer usage statistics

Microsoft posted some windows explorer statistics. Lots of detail about how people are using explorer.

Based on these statistics they are making conclusions what users find important, and what should thus be improved in windows explorer.

But do these numbers really show what people find important? As far as I’m concerned these numbers just show what people find usable in the current version of windows explorer, not what they would like to use it for.

I change my habits based on the qualities of the tooling I use. For example, the kind of drawings i made with Adobe Illustrator are different from the ones I make with Inkscape or with iDraw on the iPad. I don’t want to fight a tool, forcing it to do something it doesn’t really support very easily. I just figure out what the tool is best used for, and change my usage accordingly. Inkscape doesn’t easily support customised brushes, so i don’t use them. But in Illustrator i used them a lot.

Usage statistics don’t tell the whole story.

The power of trial and error

A while ago i mentioned the following quote from Donald Reinertsen’s Managing the design factory: The try-it-fix-it approach is faster and higher quality.

Here’s another interesting statement regarding trial and error: delighting customers can only be approached by trial and error. It’s a quote from Myth #8: Apple Just Builds A Better Mousetrap.

Trial and error leads to better quality, higher productivity and improved customer satisfaction. Why are so many people still convinced that we should have much longer preparation, bigger design documents, longer analyses, before implementing a process, or creating a product prototype?

Here’s another interesting statement regarding the power of prototypes: A big part of that is prototyping. Whereas other companies might make six or seven prototypes while developing a new product, Apple will make hundreds, Kahney said. “They discover these products through prototypes, and that’s what makes it so creative.” (Steve Jobs’s most ambitious product: Apple Inc.).

So, in addition to the benefits mentioned above, trail and error also increases creativity.

Trail and error increases quality, productivity, customer satisfaction and creativity. Sounds like a silver bullet.

Who needs a database when you have R?

This is really nice; using the following two statements you can read a comma separated file into a variable and run a sql query over the data:

stats <- read.table("stats.log",header=FALSE,sep=";"
    ,col.names=c("id","ip","timestamp","url","time"))
callsPerUrl <- sqldf(
  "select distinct(url), count(ip) from stats group by url")

No need to create a database, just a simple script that you can start on the commandline using R.

Recently i needed to calculate some statistics on log files created during a performance test. The logfiles are too big for MS-Excel, one option was to load them into MS-access, or some other database.

However, a co-worker told be about R. I thought this might be a good opportunity to try it. If you know a bit about sql it’s pretty easy to get started.

Here’s an example log file i’m going to process:

"1";"192.168.1.1";2011-08-12 11:47:25;"/search";2.997
"2";"192.168.1.2";2011-08-12 11:47:29;"/book/ISBN/1234";4.6
"3";"192.168.1.1";2011-08-12 11:47:31;"/searchresults";1.383
"4";"192.168.1.2";2011-08-12 11:47:46;"/searchresults";10.536

You can read this log file into an R data-table using the following statement:

library(data.table)
statsTable <- data.table(read.table("stats.log",
    header=FALSE,sep=";",
    col.names=c("id","ip","timestamp","url","time")))
setkey(statsTable,url,ip)
statsTable

If you run this using R you get the following result:

     id          ip           timestamp             url   time
[1,]  2 192.168.1.2 2011-08-12 11:47:29 /book/ISBN/1234  4.600
[2,]  1 192.168.1.1 2011-08-12 11:47:25         /search  2.997
[3,]  3 192.168.1.1 2011-08-12 11:47:31  /searchresults  1.383
[4,]  4 192.168.1.2 2011-08-12 11:47:46  /searchresults 10.536

The following statements calculates the average time it takes to serve an url:

avgPerUrl <- statsTable[,list(avg=round(mean(time),2)),by=url]
avgPerUrl

The result:

                 url  avg
[1,] /book/ISBN/1234 4.60
[2,]         /search 3.00
[3,]  /searchresults 5.96

Now, the best part for those of us who are more familiar with sql. Just use SQL:

library(sqldf)
callsPerUrl <- sqldf(
    "select distinct(url), count(ip) from statsTable group by url")
callsPerUrl

The result:

              url count(ip)
1 /book/ISBN/1234         1
2         /search         1
3  /searchresults         2

Nice. One statement to load a file into a data table, and another statement to query the data. No need to start an RDBMS server, create tables, import data, just a simple script. And it gets better from here: simple statements to plot graphs, and lots of libraries to do complex analysis…

Software architecture, PHP and Javascript

One of the main goals that Software architects try to achieve is to design solutions that will last a long time. You’ll often hear an architect say that the product will have a life span of about ten years, and that all technical choices should support this goal. This means that any framework you select today should not just solve your technical issues, but should preferable still be around in ten years, so you can still find people to support the software.

One obvious choice is to stick to standards. Many frameworks, especially java web frameworks, come and go, but the JEE standards stick around much longer. In this light, JSF can be considered a save choice, and Seam is a bit more risky.

What if you could go back in time 10 years, and redo the designs you created back then with the knowledge you have today? .Net was still beta, J2EE didn’t contain a standard MVC framework, object persistence was either done using entity beans or plain JDBC. With the knowledge you have today would you have stuck to the standards ten years ago?

Struts was first released in 2000, and it’s still around. So, not a bad choice ten years ago. But, both Java and .Net, the standard choices for enterprise software development, have changed quite a lot in ten years. Maybe picking something like PHP would have been the smart way to go? I think most software architects working in big companies underestimate the value of PHP.

Ok, so web development has changed a lot in the last ten years. We’ve learned a lot, and by now we probably have mature frameworks. It should be saver to stick to the standards, right?

Not so sure. I think putting the web layer on the server will soon be a thing of the past for most web applications. We’re heading back to client-server land. Lot’s of javascript MVC frameworks, like backbone.js, are being created. What’s the Javascript Struts equivalent?

Just like the smart choice for the last ten years might not have been Java or .Net, the smart choice for the future might also not be Java or .Net. Maybe in ten years you will think: if only I picked Javascript from the start…

Amazon looking for a game developer?

Just noticed this job description for a job at Amazon:

Amazon is building a new team focused on social games innovation. This group offers a creative, fast paced, entrepreneurial work environment where you will be working on a cutting edge initiative within Amazon.

Didn’t know Amazon was building games? Are they adding gamification to their (book)store, or preparing games for the upcoming Amazon tablet?

Agile versus Agile

Who benefits the most from being Agile? Who are you trying to make Agile by implementing Scrum? Is it the development team that needs to be Agile? Or is the Product Owner that needs Agile?

Depending on whom you ask, agile means different things. For a software developer Agile often means light on procedure, process, meetings and documentation, so there’s more time to actually develop software. For a Product Owner Agile means being able to quickly change the priority and details of requirements and still be able to forecast the success of a product development project.

Because Agile means different things to different people you get discussions like this on linkedin: Do you agree or disagree that Scrum is not Agile?.

In my opinion the main Agility that Scrum delivers is product management agility. The ability for a Product Manager to empirically get to the best possible product. This means get quick feedback on vision and features by being able to test working software. Being able to quickly assess ROI by having real feedback on feature size and productivity. Being able to re-prioritize features and reschedule release dates based on changing markets.

Scrum delivers business Agility to Product Managers.

Is team productivity a responsibility of the Product owner?

Recently somebody suggested to me that it should be the product owner’s responsibility to ensure that the Scrum team is as productive as possible.

My first reaction was to disagree. The team is responsible to always find ways to improve productivity. The Scrum Master is responsible to remove any productivity impediments. The product owner however, should focus on the vision and value of the product, not the productivity of the team.

However, queuing theory indicates that the Product Owner has a big impact on productivity.

The following chart illustrates the impact of batch size on the cycle time. The time it takes for a requirement (user story) to be implemented, depends on the utilisation of the team and on the size of the story (batch size). Utilisation of the team can be higher if batch sizes are smaller. If utilisation is too high, cycle time will increase and productivity will drop. This will happen sooner with larger batch sizes.

Another reason to keep your user stories as small as possible.