Archive for the ‘technology’ Category
Last week a short interview with (Sir) Jon(athan) Ive, senior vice-president of industrial design at Apple, appeared in i, the Independent’s cut-price stablemate. As the force behind such products as the iPod, iPhone and iPad, he presumably knows a thing or two about successful technology-led innovation. Mark Prigg, the interviewer, asked what makes Apple design different. Ive answered by focusing on the design process, rather than on its products, and said this:
We struggle with the right words to describe the design process at Apple, but it is very much about designing and prototyping and making. When you separate those, I think the final result suffers.
Although Ive was talking largely about the creation of physical technology objects, his words have relevance for software developers too. Integration of processes is key, he says, yet the structures and roles defined in many organizations militate strongly against this. A common problem is what could be termed paralysis through analysis. For a certain sort of organizational mind, no problem is quite so alluring as devising a logical org chart, in which each business function is resolved into a set of processes, separate roles are defined to address every stage and functional element of each process, and those roles then turned without further ado into jobs.
To those of this analytical cast of mind, jobs look well-defined when the key activities with which they are associated are relatively uniform. And indeed often this makes good sense: doubtless it would frequently be counterproductive to combine into a single job a variety of tasks that demand radically different skill sets or personal attributes. But take the approach too far and you end up with dull, narrow jobs that fail to embrace functionally substantive chunks of business process. One consequence is that to accomplish anything at all requires the effective operation of a communication network the size and complexity of which is out of all proportion to the nature of the fundamental business requirement. In addition there is the risk that job holders derive little satisfaction from their work. After all, they are not responsible for very much, and their ability to do their job depends as much – or more – on the performance of others as it does on the skilful exercise of their own abilities.
If you don’t feel responsible for something meaningful, your motivations will tend (unless you are one of those rare types able to remain serenely absorbed in a task, irrespective of how worthwhile the task seems to be) to be extrinsic – and often negative, in the sense that the principal justification for effort is liable to become the avoidance of the disciplinary measures likely to attend poor performance. Thinking about motivation brings me to something else Ive said in the interview. When asked ‘What makes a great designer?’, he replied
It is so important to be light on your feet: inquisitive and interested in being wrong. You have that fascination with the what-if questions, but you also need absolute focus and a keen insight into context and what is important – that is really terribly important. It’s about contradictions you have to navigate.
The flexible, deep engagement Ive describes surely requires an at least partially intrinsic sense of responsibility for an outcome, of ownership of the problem of realizing that outcome. (‘I want to do this, because it seems important to me.’) Ive talks about the need to be both inquisitive and optimistic, and those qualities are quite demanding in terms of the conditions they require. You must have confidence in both your own abilities and those of the organization you belong to. The harder the problem, or the more initially ill-defined the solution, the more you need the support of your organization. You need to know that your efforts will not be in vain, and that support will be available when you need it.
Probably anyone who has worked in software development has encountered situations in which innovation has been difficult if not actually impossible. These situations may be such that they fail to provide the conditions under which individuals can engage in depth with a problem, and/or they frustrate the collaboration needed to ensure that individual efforts sum positively. Commonly the problem is not lack of absolute quantity of resource, but rather lack of resource of the right type at the right times. Indeed, many failures in software development probably stem from having too many people involved with a project, working in roles that are too narrowly and rigidly defined or that are defined in a way that is somehow orthogonal to the natural grain of the business or the project.
The price of functional atomization of project resources is, more often than not, a very high communication overhead. People will spend more time in meetings trying to negotiate requirements, or writing documents, memos and emails as inputs to or outputs from such meetings, than they will in actually trying ideas out and turning them into working solutions. This is where we should heed Jon Ive’s cautionary remarks about the separation of activities. Integrate roles. Combine activities. Focus on user needs, the problem space and the functional area, not on the technology set. Select your staff well, then trust and empower them. Avoid premature commitment to a specific solution; make sure you’re exploring the solution space as fully as possible. Keep things fluid. And don’t over-decompose a project, thinking that with more staff it will get done quicker. (It will just get harder for everyone to see what they’re driving at, or to change direction mid-way.) This is where agile as it’s sometimes practised doesn’t seem to get it quite right. Sometimes there’s a benefit to providing longer periods of time for problem wrestling and solution wrangling, a chance for multiple rethinks and fresh starts of which no one need ever be aware apart from the individual or team involved. Sometimes the best solutions are the ones that look least like what you first thought you needed.
Today’s web is not the web of the 1990s – hence the idea of Web 2.0 as articulated by Tim O’Reilly and others. The early emphasis on simple standards – HTTP, static HTML pages – represented a shift away from the 1980s PC-related trend towards locating processing power and bespoke algorithmic complexity on the desktop.
The alacrity with which a standards-based web was adopted was in part a reflection of the exasperation many felt at the complexity and brittleness of local proprietary software configurations running in a Windows environment. One result was the rise of the open-source movement and the LAMP paradigm. But with increasing network bandwidth and the continued proliferation of often complex web standards for a range of data types and operations on data (and growing user bases for a variety of application types), functionality has again become richer and applications have become thicker and more varied at both client and server ends.
Static pages of HTML have increasingly been supplanted by dynamic pages bringing together diverse resources from multiple locations. Page templates and style rules are often combined with dynamically sourced data and perhaps with advertising material selected according to user behaviour. Documents – if that term can still be considered apt – must therefore increasingly be seen as modular, distributed and context-dependent. Various web protocols and standards provide a framework for accessing software services and specific elements of functionality as opposed simply to data. These web services are intended for incorporation into other data processing frameworks rather than for human consumption.
As the online environment has become more established and useful in everyday life it has been adopted by a widening demographic. Web users have shown themselves willing to adapt to technological developments where they demonstrably serve their needs (e.g. for financial services or entertainment). Social media and the interactive, participative functionality of Web 2.0 have become integral aspects of a media-savvy, platform-plural lifestyle that has connotations of ‘cool’ rather than merely geeky. But accompanying these developments are not unreasonable fears of the disenfranchisement of the technology-averse.
The explosion of content on the web, in the form of corporate and institutional sites, personal pages, blogs, and media-sharing sites, demands new and improved ways of locating relevant content. Google apparently meets many of the search needs of most users, but feed formats such as RSS and associated aggregation tools are increasingly necessary for keeping on top of developments. A further level of delegation in respect of the discovery of relevant information is likely to come about through increasingly automated metadata generation and algorithmic content analysis. (This can be considered complementary to the arguably more labour-intensive data engineering efforts needed to realize visions of a ‘semantic web’.)
The overall effect of the web’s evolution is to open up new kinds of information space, catering to the diverse needs and interests of multiple kinds of user, as well as new ways of meeting old information needs. This complexification threatens to make simple categorical prognostications and projections look merely simplistic.
(First posted on the KnowledgeCraft wordpress blog on July 11, 2009)