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 iPad is a better laptop

For some things at least. Yesterday evening i was doing some coding on my laptop. When i finished, i put my laptop away, and grabbed the ipad to do some internet reading. I actually put the laptop away to use my ipad. Why? The ipad is just a limited laptop. I can open a browser on a laptop. Still, for reading on a couch the iPad is a much better device. No useless keyboard in the way.

Luke Wroblewski posted some interesting statistics yesterday about the post-pc era. The one that surprised me most: Sales of Apple’s iPad pulled in 30% more than all of Dell’s consumer PC business in just the first half of the year. Seems like many people agree that tablets are better than laptops.

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…

What is Agile?

In my previous post, Better products faster, a reaction to this discussion on linkedin, my main point was: how do you define success for Agile?

But before you can define success, you need to specify what Agile is. Even this seems unclear. One reply on the discussion calls it a marketing/branding term in the IT sector. Also common sense, pragmatism, and an adaptive approach to project management. For others doing agile means following the principles of the Agile manifesto.

I see Agile mostly as a reaction to the failures of waterfall: trying to predict long running, complex projects. Following a predefined plan, not being able to alter requirements or plans when new information or situations arise.

Waterfall is behaving like you have a crystal ball, Agile is the trial and error way of reaching your goals.

Calling it trial and error is probably not the best way to sell it. PDCA (plan, do, check, act) or empiricism are better names from a marketing point of view.

It all comes down to not pretending that you know the future. Instead you take small steps, determine the results of these steps, and you adjust your plan according to the feedback you collected.

Donald Reinertsen makes an interesting statement about trail and error in his book Managing the design factory: The try-it-fix-it approach is faster and higher quality (page 76).

This is agility: being able to adjust your plans based on new information.

Not just from the perspective of the developers, but even more so for Product Managers.

Better Products Faster

There’s an interesting discussion on linkedin groups about successful use of Agile in large companies.

Many companies are mentioned. It could be that these companies have development teams that are using agile/scrum to deliver software in short iterations. It could be that Agile is an improvement for these developers. Maybe the developers are now more involved is estimating, design, unit testing, continuous integration and continuous deployment.

But is this what successful implementation of Agile looks like? How do you define success? Has Agile succeeded in a Big Company if the software developers have improved the way they work?

Sure, it’s a big improvement. But to see the real benefit of Agile for companies you have to see it from the perspective of a product manager.

Agile and Scrum are tools which enable product managers to be successful in managing the development of products. Using an agile approach the PM can focus on iteratively en empirically working towards products that fulfil the needs of customers.

Iterations enable feedback, feedback creates information, information enables better decisions and better products. Cross functional teams remove work handovers and queues. Less queues means increased speed.

Agile enables Product Managers to create better products faster.

To determine if Agile has succeeded in a company you need to determine if it has enabled a company to create better products faster. I think it’s save to say that both Yahoo and Nokia (both were mentioned in the linkedin discussion) haven’t shown any proof that they are creating better products faster. They are extremely slow in reacting to changing markets and competition.

Even if their teams are using Agile, both companies have failed to benefit from agile.