Ben Galbraith from Palm gave an interesting presentation about creating a compelling UI for one's software. Watching the presentation, I couldn't help thinking that software development has come of age. Even about three years ago, it is hard to imagine an engineer coming onstage at a software conference, displaying a slide with glossy women's magazines on it, and saying: "We as developers have to follow the fashion in the industry".

So what is "fashion in software" as of November 2009? Consider an example: the application "Delicious Library" has probably the most basic functionality of its class of applications (online itinerary tracking). Based on the technical features alone, it is not clear why it should be favored instead of its competitors with a much more more impressive feature set. But here's the catch: "Delicious Library" is a real designer's work. It is a "beautiful thing" designed with an eye for detail and a signature aesthetic style. The result - 500.000 USD in sales in three months, with very little advertising.

Traditional software has come of age because now we speak increasingly more about the packaging of the software we build, about the wrapping. It turns out that wrapping is related to the inner cogs and wheels of an application. Knowing how an application would look and feel, what kind of behavior it would display if it were a physical object is a fundamentally different development strategy than having a bunch of code and building an UI to make the code behave. And according to Ryan Singer of 37 Signals, the UI itself is nothing but another software layer - the outermost, thin layer of software with hooks to the lower levels.

For those teams that are still not convinced about the need to budget for UI development and design, some facts:

• It is 2-3 times more expensive to push software inside a badly designed UI to the market than doing it right from the start;
• When contemplating a beautifully designed car, you are activating the same part of the brain that you are using when recognizing faces; the "face" of something familiar is its design;
• For an average person, it takes about one tenth of a second to gauge the quality of a company based on the impression of the company's web site.

"Attractive things work better", as Donald A. Norman says. Attractive software sells better, Ben might add. I'm convinced. After all, I am a Mac user!

The jazz band that was swingin' tonight packed up some time ago, but everyone’s still hanging out.  The discussions, networking and mingling carry on.   And when asked about how it’s going, how’s the conference experience, the answers keep coming back about this special, once a year place.  “Conferences run on a kind of continuum between super academic and too sponsor driven.  Øredev isn’t like that – it’s in the sweet spot, with real practical talks, with expert practitioners, and an amazing range of topics. I am once again happy I travelled from the other side of the world to be here.”  

it’s not me that says it (I’m from this side of the world)…   but it’s pretty cool to hear.

Software development and entrepreneurship - the combination is exciting both because of the challenges and its promises it holds. On one hand, it can be challenging to shift attention from unit testing and data structures to market analysis and product development. On the other hand, a product or service created by a savvy developer can reach hundreds of thousands of potential users at the cost of one.

"The Lean Startup" by Eric Ries focused on creating new products and services in the face of extreme uncertainty. Extreme uncertainty is, or should be, the reality of every developer who prefers reality to preconceived ideas about his or her product and its market.

According to Eric, the biggest obstacles to achieving entrepreneurial success often lie with the entrepreneurs themselves; they come from the "shadow beliefs" that influence product development. These are:

    1.    We know what the customers want
    2.    We can accurately predict the future
    3.    "Advancing the plan" is progress

Eric shared an enlightening story about Startup A and Startup B. Startup a had a detailed business plan, hired the most talented workforce, and had ample funding. Startup B kick-started the business by releasing - fast - a buggy and basic version of the product.

Startup A became a failure, and startup B a successful, multi-billion dollar enterprise. The lesson learned here is spending time and resources on what directly create value for a startup. These things must necessarily whatever brings the startup in touch with the reality. Thus, the unit of progress for a lean startup is "Validated Learning About Its Customers".

For this reason a startup would prefer to fail early, as long as the failure results in a reality check and a timely change of direction. A startup that fails early and often can change direction earlier and more often, thus coming closer to a viable business model with each failure. In contrast, a non-lean startup relies on preconceptions and delays the reality check; at the time when it does release its product out to the world changing direction will become costly and morale-defeating.

So Eric's prescription is: start up lean; at all costs, accelerate the rate of customer feedback; only add features you can get instant feedback on; test, track, and tweak continuously; and only raise capital based on your sales facts and data, not speculation.

A bunch of the session speakers were just raving about the smoothness of the conference and the quality of the content – but they’re wondering where everyone’s questions are in the sessions.  Hey gang, don’t be afraid to raise your hand, get in there, and ask 'em what you wanna know.

Speaking as a pro-techie non-techie, the more intuitive the application the better. Stopping over at the Microsoft booth to check out their latest device – the Surface – you’ll find its interface goes a loooong way towards delivering a foolproof tool for digital interaction. Mostly it’s pretty fun.

Most people in the software industry would probably agree that managing the process of software development can at times be more challenging than building the actual software. Weird and wonderful things have happened to teams where the technical and the managerial parts spoke different languages. Bridging this gap and having efficient processes was the the theme of "eXtreme programming in practice" by Neal Ford and it was a tour de force describing the sometimes irrational forces affecting the profession of a software developer.

Neal's talk made a bold promise at the beginning: to show how to selectively replace some of the benefits of extreme programming (XP) while at the same time retaining some of its benefits.

According to Ford, one of the best way to retain the benefits of XP turns out to be not trying to make it less "extreme". (What is "extreme programming" anyway? From a manager's perspective, it could as well mean dealing with programmers with extreme body art. Not a very corporate-friendly image, and therefore, according to Ford, an unfortunate name for a software development methodology).

If this sounds paradoxical, consider that XP is simply "things that worked, pushed to the extreme" and as such they have a well-defined structure. Trying to make XP more "pragmatical" doesn't work unless one maintains the structure of the process: the many nested iterations, the smaller feedback loops within the larger feedback loops that eventually constitute the entire process. Take away the structure and you'll likely to harm the outcome!

Another nugget of information was how to better manage the estimation process (accurate estimation of the duration of a software project is one of the Very Hard Things of software development). The solution offered by Ford is:

A) Don't ask developers "how long will it take you to complete this". Ask instead: "how complex is it, within the domain of the given system". Then, let the Project Manager convert this complexity estimate into a realistic time estimate using a number of well-defined load factors.

B) Use well-defined, quantifiable metrics to arrive at the load factor. To this end:

   1) Define what it means to "be done";
   2) Use a binary completion convention, i.e. either you are 0% done or 100% done.

C) Track down and adjust these metrics constantly, so that you are continuously getting data about the their accuracy.

Lastly, some insights about Pair Programming. PP is valuable to the industry because it has a solid physiological justification: even when programming alone, one works both with the logical / analytical part-oriented view of the problem (left-brain activity) and the intuitive / synthesizing / whole-oriented view (right-brain). So PP is merely an externalization of these two ways of approaching an assignment, with two programmers switching roles to act as the "left brain" or the "right brain" interchangeably.

All in all, an enlightening and valuable talk rooted in considerable industry experience.

Dan North brought some of the ideas of efficiency we’ve been hearing about into focus during an interview with the fellas from .NET Rocks, Carl Franklin and Richard Campbell. Bringing the discussion straight home to the developer world, he noted that efficiency is indeed the right thing to think about, once you’ve realized effectiveness.

Dan made a nice distinction between efficiency, meaning using fewer resources for a given result versus effectiveness, which is about getting results – and getting the ones you want.  After all, optimizing is great when we’re optimizing the right thing.  Effectiveness is like design, making the system do the right thing.  Efficiency is about performance.  So be effective first, and once that works right (enough) then start to optimize it.   Or in .Net Rocks speak: just be awesome!  

So, it's November 9th 2009 and the Oredev conference has taken off; for me, it's 3 days of talks about the software industry on topics that I most enjoy. In the spirit of the times, I kicked off my first day with a popular topic - visualization.

Eric Stollnitz from Microsoft showed that there are more cool things to MicroSoft than the XMLHTTPRequest object. We were shown a slew of demos dealing with images and image processing. The common theme running through these applications was taking disparate chunks of visual information (images) and transforming them into a form natural for the human perception to process. There was an application that, given a large set of photographs, stitched them together into into one complete, continuous view. Imagine having taken a number of photos (of a landscape, for instance) from different angles. Navigating these images one by one has been the domain of a traditional photo gallery; the demo showed how these discrete photographs can be viewed much like the original, real-life original. To this end, images are "stitched" together and 3D panoramic effects are applied to the resulting landscape to make the viewing close to viewing the original. A flat photograph acquired depth and volume; zooming in felt like stepping up closer to the picture. (An aside: I never knew there were owls in the daytime on the rooftops of Seattle!)

The computational challenges of solving such a problem efficiently are interesting. For example, when handed N images (or pieces of a puzzle), how would you put them together to the original form without comparing every image to every other image (N*N comparisons)? Leave a comment below.

Other demos included The Worldwide Telescope, a collaboration between MicroSoft and various astronomy labs. Viewing planets and moons in real-time, and even zooming out to view or Galaxy (which looks like a fine, white mesh, like a coral reef suspended somewhere in the Universe) has never been easier.

All in all, this was an interesting presentation offering one possible answer to the question: "How do we best use the enormous computing power we have at our disposal"?

Eric's answer, with this presentation, is: "Help us visualize data to understand it better".

Activity on the exhibition floor seems to keep rollin’ throughout the day with interviews and quick talks on the stage. Good for a quick “nugget o’ knowledge” between sessions.

Whoa! The blustering Malmö winds were making noises in the auditorium that sound like a child learning to play “twinkle twinkle little star” on the flute.

Marc Lesser kicked off the conference with a keynote that left the audience in speechless silence – a whole 60 seconds of it!  It was an excellent reminder of how we can be a more peaceful AND more effective version of ourselves. Thank you Marc, for helping bring us to the right place to get the most out of these special days, and helping bridge the gap between the business of business and the business of me.