Review: Dreaming in Code, by Scott Rosenberg

时间:2019-03-01 08:04:02166网络整理admin

By Louis Suárez-Pottis Silicon Valley’s history is littered with failed attempts to build software that sets the world alight. Louis Suarez-Potts asks why it’s so difficult to create something new in a discipline that seems poised between science and art HOW do you make good software, let alone software that transcends the usual expectations? Dreaming in Code by Scott Rosenberg is about one such attempt: a project to create a free “personal information manager” called Chandler that combines features such as a calender, email, an address book and instant messaging. Rosenberg tells us that software is created the way just about any other intrinsically complex work is: by people animated by dreams, ambitions, egos and plans. In software development, however, there is a long history of failed attempts to build programs that transcend the norm – a history that developers seem oblivious to. Creating novel software is for optimists. Dreaming delves into historical efforts by developers to coordinate the programmers, designers and managers who make up a software development team. The book is neither technical nor superficial so it should engage readers already in the field as well as those simply interested in what software visionaries and programmers do. It is an enjoyable and illuminating study of software-making. To his credit, Rosenberg refrains from pitting one method against another. Rather, his argument concerns the very problem of imagining and then building novel software. Rosenberg has done his research and what minor inaccuracies there are do not mar the overall trajectory of the work. Chapters and sections on Chandler are interleaved with examinations of software management and development, its theory and practice. It is difficult not to wish the protagonists in this book had the same historical insight as the reader comes to possess. That blindness to history is not down to a lack of talent. Mitch Kapor, the driving spirit behind Chandler, made his name and fortune in the early eighties by developing the spreadsheet program Lotus 1-2-3, arguably the “killer application” which made the business world embrace the PC. Kapor’s love of, and evident brilliance at, what he does are coupled with a strong moral sense of how things should be done: he wants to change things for the better, openly and inclusively. Kapor exemplifies the difficulties involved in creating something new in a discipline poised between science and art. Most of today’s software is opaque to developers – it is nothing but ones and zeros, which means that the way others have solved familiar problems is largely hidden. Perhaps that is why the same mistakes keep rearing their ugly heads. Developers must also decide what it is they want to create, how this should be done and who should do it. Then they have to organise those involved. Kapor chose the strategy known as open source, which depends on a community of contributors. Each member helps the others and shares in the “commons” produced by the joint efforts. This approach aims to bypass a problem identified by Frederick Brooks, a US computer scientist, who wrote that “adding manpower to a late software project makes it later”, because one must train all the recruits. In many cases, open source succeeds because of its community spirit. Well-known examples of open source projects include Linux, Firefox and, all of which were created to improve on proprietary products. Even so, open source is not a panacea. Developers must still negotiate the basic problems of directing projects, managing code and coordinating, however benevolently, the community. Chandler differs in an important way from other open source projects because it was created to satisfy a dream. Maybe that’s why, after four years of significant change, it is only now close to being unveiled. I have a confession to make: as the community manager of, I’m not only an advocate of open source but I’ve met and corresponded with members of the Chandler team almost since the start of their project. This connection enlivened my appreciation of the story. It also made me wish for more details. I would have preferred, for instance, a stronger account of the governing procedures affecting code in open source projects. In addition, I was left with the impression that software development, and open source in particular, is exclusive to the US and Europe. I know from and other endeavours that this is not so. But Rosenberg is not interested in the close examination of this or that method or in software’s global politics. He’s interested in the art of making software,