With this final and belated prediction in the series, I have taken the liberty of looking beyond 2011 speculating on the coming decade. I’ll start with a trip down memory lane in order describe how we got into this mess of information overload and what we can do about it.
It all goes back to files. The concept of a file is one of the simplest and most widely used abstractions in user interface design. Files are how we share documents, source code, and online content. Part of the success of UNIX and C that started in 1969, and lives on today in Linux, came from the elegance that files provided to the programming model. Those of us who started our careers programming C may still be amazed at seeing UNIX-style file paths now engrained in pop culture in the form of URLs. In addition to being a useful construct for programmers and operating systems, the notion of files became the primary way to organize information in the IDE, on the desktop, and on the web.
The problem with files is that we have way too many of them. In 1981, the graphical user interface was created at Xerox PARC in order to help us manage large volumes of files more easily than we could on in the filing cabinet or command-line interface. That same desktop metaphor was imitated first by the Mac, then by Windows. With a few decades of Moore’s law driving graphics performance improvements the windowed desktop has become a lot prettier. But the window-based desktops have experienced only incremental improvements, and the amount of information that we now need to process has exploded. The document hierarchies that we access daily have grown to tens of thousands of files. For developers, tens of thousands of files turned into hundreds of thousands. Yet the file and folder metaphor for browsing them remained the same. We were spending more time hunting for and clicking for information than creating it. The desktop metaphor collapsed under the weight of all of those files.
In late 1990s search-based navigation started getting embedded into both our desktop and online information retrieval experience. We were no longer bound to constant browsing for files through deep hierarchies or Yahoo-style categorizations of tagged content. Computers, network infrastructure, indexing and ranking technologies had become fast enough to place at our fingertips the thousands of files on our desktop, millions of classes accessible in our IDEs, and billions of pages on the Internet. When you consider the sheer speed of access that we have via Google’s Instant Search or Eclipse’s Open Type, this is nothing short of remarkable. But then we started seeing a familiar pattern emerging again: we were spending more time searching for information than we were spending on the collaborative and creative endeavours that are productive and rewarding. The repeated, wasteful clicking and keystrokes used to constantly browse and re-browse through information had now turned into repeated, wasteful finding and re-finding for the same information. We increased the volume of information that we could work with effectively by an order of magnitude or two, but the level of information relevant to our day-to-day work grew at an even higher rate.
The information overload problem that we are facing goes back to this notion of files that we have been relying on so heavily. Files encapsulate content. We tag them, bookmark them, index them and search them. Some of us are filers and obsess with having our content neatly organized and desktops de-cluttered. Most of us are pilers, with our computers’ desktops as cluttered as our physical ones. Either way, we are all playing a losing battle. The fundamental problem is that no matter how we organize and structure our documents and source code, our daily tasks crosscut that structure. We need a new approach to managing knowledge work in order to survive the ongoing deluge of information and increased demands for collaboration. The graphical user interface and search-based navigation will continue to be a key part of user interface design, but improvements on that front will only provide diminishing returns.
The primary unit of knowledge work is the task. Tasks have a structure that is defined by the process that we use in our knowledge production activities. For software, this could be an Agile process, with tasks being recorded in a project tracking tool and taking the form of user stories and defects. For the sales part of the organization, tasks are captured as opportunities in Salesforce. The game changer created by the task-focused interface [http://en.wikipedia.org/wiki/Task-focused_interface] is to leverage these entrenched tracking tools to make tasks the primary anchor for the conversation and context around knowledge work. This concept means that the primary way that we access the information in the IDE and desktop user interface becomes the task, not the file. All conversation is available through a single point of access, no matter how many different repositories, email, or social communication channels it appears on. Even more importantly, all knowledge accessed and created as part of the task is tracked automatically, meaning that we offload our brains and let the computer do the work of ranking the information that’s relevant to what we are doing. Multi-tasking becomes a one-click operation, meaning that we don’t have to pay the price of context switching in the presence of constant interruptions. The near-term benefits of this approach are the reduction of information overload and multitasking overhead. The long-term benefits are a new level of knowledge capture and sharing that will eventually transform the productivity of the knowledge worker by an order of magnitude.
In 2011, tasks will be well on their way to becoming an entrenched unit of abstraction in the software development of leading IT-centric organizations. Every change made to a system will be automatically linked back to the task that it originated from as task activation becomes an integral part of developer workflow. This task-level traceability will be connected to continuous integration systems, which will position tasks as the primary unit of production in the continuous integration loop. This will dramatically improve development transparency across heterogenous ALM stacks, and plug Agile project tracking into the development loop, while empowering developers with the tools that they need to manage changes in very complex systems.
In 2012, this automatic capture of context will be leveraged by other stakeholders in the software delivery loop, including support staff, DevOps and QA. Stakeholder-specific context tracking will tie together the activities of developers, operations and quality assurance engineers; this will help to unify all of the participants in the deployment, diagnosis, and development of an application. Materializing a release-specific workspace to investigate a defect in a deployed application, along with all of the context from the application operators and help desk staff, will become as easy as clicking the “activate” button on a task.
2013 will bring tasks-focused collaboration higher up the management stack. Requirements tracking, project, and portfolio management tools will become directly linked to development activities happening at the production level. The production level of software development activity will finally have a high-fidelity link to the planning level, allowing for a new level of predictability and productivity in the software lifecycle. In their support of this movement, ALM tools will learn to speak the language of development tasks and then get out of the developer’s way.
What follows in 2014 is an infection to other parts of the enterprise. With project and portfolio management activities planned via tasks, email will finally start being displaced by task-focused collaboration as the mechanism for tracking work. One-click multitasking™, task-focused collaboration and automatic knowledge capture will start to be tailored to the other departments in the organization.
In 2015, the single integrated Task List and task-focused interface will layer so seamlessly over desktop and mobile operating systems that consumers will start seeing the same level of productivity and collaboration benefits. By 2020, it will be effortless to assign your grandmother a task to bake you cookies, no matter where she is located, and have the recipe automatically captured as part of the context in order to later delegate the same task to your robot assistant before flying to work in your car.
As William Gibson stated, “the future is already here – it’s just not very evenly distributed”. In writing this blog series, every bit of content that I produced and accessed has been automatically captured as part of my task context, and each of the many revisions and bits of feedback were tracked on the task. When I re-activated this task after a series of interruptions, my desktop-based Word and web-based WordPress editors were instantly restored. In the same way, every change that any committer has made in the Eclipse Mylyn codebase is automatically linked to the Bugzilla bug describing the social conversation around the change, then linked to the corresponding build and release. Tasks and contexts externalize our memory and make it much easier for both our forgetful selves and for newcomers to help us evolve our software.
To my surprise and concern, Tasktop is telling me that I have spent over 88 hours researching, collaborating on, and writing this prediction series on Agile, ALM and developer tools. All of this information was automatically captured and will be accessible to me in 2015 when I attempt to explain away any inaccuracies in my predictions.
“The best way to predict the future is to invent it” said Alan Kay at Xerox PARC in 1971, inspiring Smalltalk and paving the road for the graphical user interface. Our vision at Tasktop, as embodied in the “less is more” logo , is to transform knowledge work around the focus and flow required to get creative work done in the presence of ever-growing volumes of infromation. As with other innovations, like the file hierarchy and desktop metaphor, this move to task-focused collaboration will originate from developers and move upwards and outwards in the organization. We look forward to working with you in making this vision a reality, starting with the transformation of the Agile ALM stack and developer tools. <=>
Mike Henke
