My husband recently acceded to an upgrade of a music recording application that achieved an unfortunately too-common nadir: in providing an array of new secondary features, it derailed one of the primary features of the application (the ability to sync tracks). He asked a very pertinent question: how can software engineers ignore the needs of the people who use the product?
Having worked in the software industry for some time, I understand well how modifications can unmoor features that were functional and stable in the prior release. I also know that when engineering and users are more than a degree of separation, it’s all too easy for engineering to make assumptions about how and why users engage with their application – resulting in irrevocable decisions that seem (and probably are) cavalier, despite good intentions. Back in the day of proprietary software development, responsible software companies held engineering accountable to client services. Having to front up a client, angry about an upgrade that removed functionality, is actually helpful for software engineers to understand their purpose: to create software that enhances the users’ abilities or quality of life.
Coincidentally, I read today a blog entry from Mitchell Baker, President of Mozilla Foundation: “It’s hard to find someone who understands both open source software and the consumer space.” I trust her on this, but wonder how this could be? Wasn’t open source supposed to bridge the chasm between software development and users? No longer at the mercy of the monolithic software corporations, open source’s promise was to integrate the user with the development process. And when the user is a software developer, this probably does hold true. But rather than become more democratic, too often development has become solipsistic instead, and accountable to no one.
Andrew Keen’s analysis (The Cult of the Amateur) is spot-on. Good software is the result of well-defined processes managed by professionals. Proprietary vs. open source is a false choice on this: ownership and licencing is irrelevant; whether engineers work together actually or virtually is also not an issue. But, development must be seen as a defined process, with a bright-line difference between a test release and the real thing. As consumers too often see ‘Beta’ at the top of their web-based applications, they are becoming accustomed to working with test release software, and we continue to lower the bar. Is this the brave new world?
AddThis
About
- Dionne Dumitru
- My career and life are shaped by my many interests and love of learning and solving problems. I also like making things; the best part is playing with ideas. This blog is part of that outlet.
Subscribe To
Posts
Comments
1 comment:
This is certainly becoming more and more of a problem with all kinds of software. It often seems that the more updates that software vendors send down the line the worse the software works, and the steeper learning curve climbs, just to be able to use the software in the same way one was able to before the update. I think that much of the root of the problem lies in the paradigm of an ongoing, dynamic relationship between the vendor and the user. I think that in practice, the application of the paradigm has deviated so much from the idea of a mutually beneficial relationship in which there is an ongoing give and take of ideas and needs, to become more of a one-sided relationship in which software vendors increasingly think they know best what the customer needs and will eventually accept. I think as well, that as software update permeates society there is an aspect of paternalism in which the thought of the user becoming dependent on the vendor to direct him or her how and for what purposes the product is used. I think therefore that the problem may be deeper than slack testing in environments permissive of questionable quality. I think the industry bias towards newer faster better does not always yield these things and fosters less than optimal outcomes.
Post a Comment