Why Wireframing Should be a Required Activity

The overwhelming majority of users we deal with are non-technical and visual learners. As a result, requirements documents that are heavy on narrative are a poor conduit to understanding the way in which users will interact with a proposed application. By visually manifesting the application prior to development, wireframes put everyone in the best position to win.

Here’s my anecdotal allegory of the problem with requirements documents. When distributing a requirements document, if there are six business users in the room there are probably four that have read the document and two that understand it. Of the two who have understood the document, each of them is imagining a different application in their mind’s eye. It’s not their fault. This stuff isn’t what they do for living and when they become involved it’s on top of their normal day job.

Wireframes replace the written word with visual manifestations of the screens/pages. From a users perspective (an even from our respective) they are significantly easier to understand than dozens of pages of narrative. Software developers and business users live in different worlds and often think very differently. Wireframes help to bridge that gap through pictures that represent a common understanding of functionality. Because wireframes are a visual representation of the application, everyone in the room leaves with the same understanding of what will be developed.

Wireframes should be developed either alongside requirements documents or in lieu of them. They should also be developed deeply and completely to the point where the development team can state at the end of the wireframing sessions:

“This is what we are building – no more and no less. If we are forgetting a feature and it needs to be added later it will likely effect the schedule and budget.”

From my experience, when the wireframing sessions are done well and are complete, change orders are almost never disputed. Don’t get the wrong idea, however, that wireframes result in everyone living happily ever after. Change orders, regardless of whether disputed or not, still frequently cause frustration and require negotiations with scope, schedule, and/or budget.

It’s amazing how often what seems to make sense in thought and speech requires modification once manifested on screen. Wireframes help to alleviate, but not eliminate, this affect. Needless to say, virtually every project succumbs to Humphrey’s Requirements Uncertainty Principle which states:

“For a new software system, the requirements will not be completely known until after the users have used it.”

Wireframes also help to uncover hidden business rules. We all take what we know as professionals for granted and sometimes inadvertently omit information from those with less experience than ourselves. When the development team is discussing the need for each page, workflow, control, validation rule, et al it’s a natural process to hit upon each of the business reasons and processes and discuss them in detail.

Wireframing also helps with estimating projects. I’ve mentioned in previous posts about the inherent problem with estimating software projects. A good example of how badly human beings are at estimating is a statistic from “Demystifying the Black Art of Estimation” by Steve McConnell that most estimates are actually 30% of the actual level of effort. With that kind of epidemic of over-optimism, the clearer we, and the business users, can visualize the application – the better.

Once the wireframes are developed, a finer grained estimate is possible than prior to the wireframes. Each page and feature is able to be enumerated, sized and prioritized. Any prior estimates should be validated against the new information provided by the wireframes.

Wireframing the application doesn’t eliminate documentation. Things like complex business processes still need to be codified.

Wireframes, however, do a better job than requirements documents at articulating for what purposes users need to use a system and the most efficient way in which to use it.

Could the Unthinkable Happen to Microsoft?

This year has been a pivotal one for the OS business. A few key stats caused my mind to fast-forward to a possibly unthinkable scenario –- Within the next 5 years, Windows will not be the dominant OS, and in fact is set up to be this millennium's OS2.

Yikes.

You’re probably thinking; “How could Jack possibly think that? Has he lost his mind?”

The latter question is hardly up for debate. However, the aforementioned radical scenario is far from certain, but in my view, certainly plausible. Here are some stunning data and some logic immediately thereafter to make my compelling argument. I end the story with all the reasons why Microsoft should maintain their coveted pace in the OS market.

How Microsoft Could Lose Their Place

From a Morgan Stanley study published in April 2010, there are four stats that I think support my dire Windows scenario (not prediction).

1. By 2015, there will be more mobile than desktop Internet users.

2. Social network users have surpassed email users indicating the preference to communicate in the context of online collaboration.

3. People are using their mobile devices more as computers than as phones.

Couple those stats with these by Gartner showing the growth of Android and Apple and the decline of Windows in the context of mobile devices.

Mobile technology is moving at a break neck pace that consumers and businesses alike are adopting virtually immediately. More and more, those mobile users are using their mobile devices in the same way as their desktop computers. With the advent of the iPad and it’s competitors, one can fast forward to a day where a user’s mobile device IS their desktop by virtue of plugging their device into a docking station to enable additional sets of ports, a bigger monitor and/or multiple monitors, a keyboard and mouse, and to charge their battery.

One can also make the argument that over the next 2-3 years, the mobile OS business will trim down through attrition to only a few big players; right now the trajectory favors Apple and certain flavors of Android. A side note … doesn’t Android’s story remind you of Linux where at one point there were lots of players that ultimately trimmed down to a select few best of breed?

With only 4%of the mobile market, is Microsoft too far behind to catch up in the requisite time? Could metaphors introduced by Android and/or Apple provide well known and soon-to-be intuitive features where Microsoft could be frozen out of the mobile OS market and thus by extension the desktop market?

Why Microsoft Is Likely To Maintain Their Place

Here are some reasons why the unthinkable Microsoft scenario may not happen, many of which should be attributed to a colleague of mine who counter-pointed me at every turn as I laid down the potential demise of Microsoft.

Android, by nature of it being open source, is not a single, consistently deployed OS but in actuality many flavors of the same OS with a different feel to each one. By contrast, Microsoft, as usual, will continue to provide a singular vision of it’s Windows mobile OS providing a consistency across devices.

Businesses and consumers alike use their devices to be continuously connected and to easily collaborate with one another. Outlook, Microsoft’s email client, is well known and well liked by it’s users making adoption by primarily email users highly likely.

So you say that with a current 4% market share, Microsoft is too far behind and too late the to the game?

Well, the throw away, appliance-like, aspect of mobile devices means that users will be upgrading to new devices every two years or so. As a result, the ability to enter the market with a better mouse trap and convert audiences from one OS to another is constantly available.

My colleague also makes the point that the rapid nature of new, unforeseen, and game changing devices being introduced every 5 years  or sooner requires a constant introduction of new OS’s for the foreseeable future.

We’ve gotten used to Microsoft letting others break ground then usurping control of said ground. However, with the speed at which mobile devices are being adopted and replacing desktops, one has to wonder if waiting has put their place in the OS market in jeopardy.

Dreamforce 2010

This was my first Dreamforce and I have to say that Salesforce really knows how to put on a show. Nonetheless, it was a good take and worth the money and time. There was lots to see, plenty of people to talk to and a good number of significant Salesforce announcements . So here is my summary as it relates to app dev.

The biggest news is their mega jump into cloud-based application development with the announcements of the acquisition of Heroku, partnership with VMWare to offer the VMForce platform, and their abstraction of the Salesforce database platform into a product called Database.com.

Clearly, Salesforce’s slew of recent offerings is their foray into the competition for cloud-based developers joining Amazon EC2, Google App Engine, and Microsoft’s Azure.

Salesforce is playing catch up. Amazon and Google leveraged their infrastructures for development and hosting services two years ago. Microsoft was talking about Azure soon thereafter and unveiled it for general release earlier this year.

However, with the acquisition of Heroku, a hosted application development platform for Ruby on Rails developers, and their 107K hosted applications, Salesforce has bought a development community. If you are going to be late to the game, they did a great job of catching up.

VMForce, which is a Salesforce/VMWare partnership, was unveiled this past summer and is geared towards the enterprise Java development community. Like Heroku, VMForce is a hosted application development environment.

Both Heroku and VMForce provide developers with the ability to code locally and publish to the cloud.

Database.com is an abstracted version of the Salesforce database platform. The IDE is completely web-based and all development happens in the cloud. Like all demos, it looks pretty slick but time will tell whether it is scalable and its performance is up to the standards that application developers and their customers expect.

Salesforce has bet big on cloud-based application development. It’ll be interesting to see how it all shakes out between them, Google, Amazon and Microsoft.

P.S. A funny thing happened to me on my first day back from Dreamforce. I logged into LinkedIn today and saw a note in my message box from Microsoft offering me a trial version of Microsoft CRM Online. Weird coincidence ;)

Humphrey's Requirements Uncertainty Principle

Watts S. Humphrey (July 4, 1927 - October 28, 2010) passed away over the last few weeks and as a memorial to him I thought I'd post an article about his Requirements Uncertainty Principle, which is a cornerstone of Agile's approach to defining system requirements.

Watts Humphrey contributed significant thought leadership in the software engineering process and one of the principles he states is requirements are inherently uncertain. To quote and excerpt from his book "A Discipline for Software Engineering":

"This creative design process is complicated by the generally poor status of most requirements descriptions. This is not because the users or the system's designers are incompetent but because of what I call the requirements uncertainty principle:

For a new software system, the requirements will not be completely known until after the users have used it.

The true role of design is thus to create a workable solution to an ill-defined problem. While there is no procedural way to address this task, it is important to establish a rigorous and explicit design process that can identify and help to resolve the requirements uncertainties as early in the developmental process as possible."

Back in 1995 when this book was written (2 years after the founding of Scrum), Humphrey recognized that the software engineering process was broken and that repeated attempts at having a requirements document comprehensively describe a proposed system was met with failure many more times than with success. We are 15 years removed from this publication and there are many development teams still searching for this fictitious Holy Grail!

As we all know, Agile addresses Humphrey's Requirements Uncertainty Principle by:

1. Capturing what users' want in user stories
2. At the time of development, collaborating orally and through whatever documentation is required to fully understand what is to be developed
3. Designing and developing features to address the requirement(s)
4. Then immediately thereafter providing what's been developed to the user(s) so the requirements can thus be fully known.
5. Repeat

Why wait till the end of a project or many months after a feature has been developed to get feedback from our users. It is always most efficient to make the inevitable, yet unforeseen, changes to features immediately after they have been introduced.