|
||||||
|
|
|||||
|
Experts Face Off on Software Management
VSLive! San Francisco, February 13, 2003
VSLive! San Francisco's Wednesday morning keynote drew laughs, applause, and murmurs of concurrence as Alan Cooper and Alan W. Brown presented a small panel discussion of the challenges of software development. Moderated by Jeff Hadfield, publisher of Visual Studio Magazine, the speakers explored a range of topics including lessons learned, the roles of players in the process, how to approach estimation, and the role and benefit of tools. The discussion started with each speaker describing their worst-nightmare project and the lessons learned from working on it. Alan Cooper led off by talking about a product where the development team was divided into two camps, each having different viewpoints of what the product was. The problem was that the teams didn't talk or agree, but their software had to. The lesson learned: The organization of your software will usually reflect the organization of the teams that build it—dysfunctional teams will build dysfunctional software. Alan Brown cited an example in the modernization of the FAA air traffic control system, where different groups of users could not agree on what the system should look like and what the interactions should be. The result was that the only acceptable solution was an online modeling of the paper process in use at the beginning, even though it was clearly inefficient. The lesson learned here: You need to know who the project's stakeholders are, what their individual needs are, and what authority they have in determining the project's outcome. On the subject of project planning and estimation, Brown identified the problem of two different viewpoints of the development process. One viewpoint is that it is a "black art" that is highly dependent on individuals, and that understanding the individuals' skills and knowledge of the domain should allow you to drive the schedule. The other viewpoint allows for consistency across projects and teams, focusing on small iterations, working closely with stakeholders, and taking up small chunks of functionality and delivering them successfully. He said that interfaces between groups are the key things that drive accountability. Cooper revealed a misconception in the way we approach software development: We try to fit the process within the same framework as other industrial and engineering processes. He discussed the problem that arises from the uncertainty of programming—the fact that many tasks can take a day if things go well, or a week or more if they don't. As a result, programmers are always at odds with management, leading to self-deception on both sides in terms of how long projects will take.
Hadfield then led the discussion toward tools, noting the impression that they're often forced on programmers even though the tool selection might not fit the methodology or process in use. Brown underscored the importance of tools for programmer productivity, but mentioned that the process is a complex negotiation between players—and there needs to be equal or greater tool support to manage those negotiations because that's where many projects fail. Cooper took a dissenting view, saying that "the act of constructing software is not engineering" and that the focus is too often on process instead of successful delivery of a product that satisfies the users' needs. Most of programming is problem solving, he said, not in building the solution to the problem once the solution is determined. His view was that good programmers are often called upon to do technical problem solving that amounts to engineering, even though their best talents might lie elsewhere. Cooper said that programming is largely an unsupervised task, leading Brown to ask whether the industry would need or want greater supervision and oversight in the process, if the process of engineering and construction are cleanly separated as they are in other industries. Cooper pointed out that some might say Extreme Programming involves an additional level of supervision in the form of pair programming, and that simply having someone else there helps people have a conscience. However, Cooper drew rounds of laughter by pointing out that "one wild-eyed programmer working next to another wild-eyed programmer" doesn't necessarily amount to supervision. Refocusing the discussion on tools, Brown discussed the role of the .NET infrastructure and the need to improve productivity and not reinvent the wheel. He discussed the benefits of patterns and anti-patterns—learning what works and what doesn't from problems that have been solved many times before. Cooper questioned the focus on efficiency at the expense of the focus on the software being built and whether it will meet the users' needs. He stated that the "best to market always trumps the first to market" and cited several examples. Brown countered by asking whether the examples were necessarily the best, or whether other factors such as marketing, company, and target users had a more profound effect on the product's success. To close, Hadfield asked each speaker for his one piece of essential advice. Cooper responded by again stressing the importance of the problem-solving process in the definition of the product. He described the disconnect between the engineering view of software development and the realities of the process as well as the types of people involved. Having earlier said that "users are problematic," he defined the role of an "interaction designer" to bridge the gap between the users' limited understanding of how to specify their software needs, and the ability of the programmers to construct it. Brown took a somewhat less concrete approach, citing a large and complex project that he will start this week. He said he's approaching it with some trepidation, unsure of the right approach. He said he was hoping he would be able to understand the problems and figure out their solutions. He ended by advising attendees to have the courage to confront the things they don't understand and try to solve them. About the Speakers Alan Cooper's passion for humanizing technology and his experience as an inventor and software programmer provide the vision and focus for Cooper's wide range of GOAL-DIRECTED® services. Known among the digerati as a leading authority on customer experience, the "father" of Visual Basic, and a longtime champion of the interaction design discipline, Alan is the author of two best-selling books: About Face: The Essentials of User Interface Design, and The Inmates Are Running the Asylum, and is in demand as a speaker on customer-centered issues worldwide.
About the Author |
