Andy Pols Geek, Entrepreneur

Some random thoughts...

XPDay and the Drift Table

Bill Gaver gave an fabulous keynote at the recent XPDay conference. He talked about designing things for Ludic (playful) Engagement.

This included the Drift Table, a coffee table that enables people to slowly float over the British countryside from their own sitting room. The weight of objects left on the table control the slow drift of aerial photographs displayed in the table surface. This table suggests a 'hole' in the home connecting physical and virtual space. A display on the side of the table shows the location of the aerial image. See photos of the drift table in use

Check out this paper to find out more.

I bet you want one of those tables as much as I do!

Testing Challenge

I've been running several two week "challenge" assignments recently and really enjoyed them.

This week I'm trying to prove to a company that they can automate lots of their 3rd party vendor acceptance tests. They're spending vast sums of money on manual testing - any reduction in this would be a godsend.

The first application is a java web app. That should be easy. It turns out that it's using lots of really strange javascript.

For example, the login form looks like this:

<form id="login" name="login" method="POST"
                 action="security_check">
   <input name="username"/>
   <input name="password" type="password"/>
   <!-- click this to submit! -->
   <a href="#" onclick="submitForm('login',1,{'event':'login'});return false">
      <img src="/some/image/path/login.gif" .../>
   </a>
</form>

The post action security_check simply returns an error saying you can't post!! Why would anyone subvert the standard web form process like that? They have some javascript called from an image link that submits the form. If you don't do things in a standard way you can't test your application using standard tools.

Httpunit could not parse the javascript. If I clicked the link it simply returned to the same page (due to the href="#").

JWebUnit uses Httpunit under the hood, so was not really an option (although I did give it a spin).

Selenium did not work as I could not change the deployed webapp (the selenium javascript needs to be served up from the same server).

Then I discovered the lovely JExplorer library from MIIK. It basically wraps the IE components so you can embed Internet Explorer in a Swing application.

It worked a treat! I can now automate all my acceptance tests using JExplorer.

Inspirational Video

I stumbled across this the other day. Bill Strickland is amazing. All organisations need a Bill Strickland. I recommend you give it a look.

http://stream.fuqua.duke.edu/Content/fuqua_events/2003/Strickland/Strickland.smil

You can find more about Bill at http://www.fastcompany.com/magazine/17/genius.html

I particularly like this observation:

Artists are by nature entrepreneurs, they're just not called that," Strickland says. "They have the ability to visualize something that doesn't exist, to look at a canvas and see a painting. Entrepreneurs do that. That's what makes them different from businesspeople. Business people are essentially administrators. Entrepreneurs are by definition visionaries. Entrepreneurs and artists are interchangeable in many ways. The hip companies know that.

Why Is Agile Development So Scary?

Preston Smith has written a pragmatic overview from of why Agile works. I particularly liked the reference to Donald Reinertsen's research that showed:

  • Out of hundreds of projects, there is no case in which requirements remained stable throughout design.
  • Of more than 200 product developers, fewer than 5% had complete requirements before beginning design.
  • On average, design commenced with only 58% of requirements specified.

If requirements are going to change, wouldn't we be better off acknowledging this and building our processes to accommodate it?

Thoughts on Strangler Applications

Some time ago Chris Stevenson and I wrote about our experience working on a legacy application. Martin Fowler liked our approach and decided to call it a Strangler Application.

Brian Marick includes it in his recent blog discussion about the different approaches to dealing with legacy code.

I have been thinking about this a lot lately. I have been working with a client where a strangler application would have been a good solution. It was an almost repeat scenario from when we first applied the Strangler Application approach to a legacy financial trading system.

One of the key aspects of the original project is that we left the legacy application alone. The legacy application was still maintained by the original team. A new team completed the replacement strangler application. The rationale behind this was that the original team had repeatedly failed to address the legacy problems and was holding back the business. A key problem was the team itself. The team appeared incapable of coming up with an alternative solution, but management did not want to change the team as they were the only people who knew how the legacy application worked.

The new client rejected the approach.

We can't do that! There is no way we can get the budget for two teams

Asking for more money in this way highlights the problems of the original team and the fact that the project management do not know how to fix the original team (and have not addressed it before).

I now realise a critical success factor of the original project was the way the Project Manager hid the cost of the strangler application by associating it against a different project that had spare cash available.

This is a real barrier to applying these ideas in this situation.