SANTA CLARA, Calif.—Programmers at this weeks Software Development Expo here are doing what they do best: sharing advice and showing one another effective ways to develop quality code.
During the week-long technical conference, experts in such fields as software modeling, Web services, and system security are sharing their experiences with real-world problems and solutions. Theyre giving much attention to dealing with management—for good or ill.
In a session nominally about upcoming changes to the UML standard, Scott Ambler, senior consultant at Ronin International and author of “The Elements of UML 2.0 Style,” lamented the rarity with which development projects deliver on time, and the wastage that results. Worse, he said, everyone involved knows the schedules are unrealistic. “If the estimates upfront are lies,” Ambler said, “and [management] knows the cost/benefits analyses are lies … they just go on gut feel.”
Amblers solution is to use software methodologies such as Scrum, with iterative development funded in extremely short time frames. Among the benefits are reduced bureaucracy and the fact that users learn what features they really care about before the team wastes time implementing unneeded functionality.
These iterations shouldnt last more than a month. Ambler explained. “Its like studying for an exam,” and starting work the night before the deadline. With six weeks in a project “sprint,” he said, not much is accomplished for the first week or two. “The longer the iterations, the greater at risk your project is,” Ambler said.
Theres good—or at least understandable—reasons for management to emphasize schedules, said Gerald M. Weinberg, author of “The Psychology of Computer Programming” and prime mover behind the AYE Conference. “Even a 4-year-old knows when its Christmas,” Weinberg said. Nontechnical managers may not be able to recognize quality (not that its much easier for anyone else), but they know when the product is done by Christmas day.
Weinberg, a keynote speaker, provided a retrospective from his 50 years in the software development industry. (For instance, in the 1950s, male programmers were called Applied Science Representatives, while women doing the same job were called System Service Girls.) One thing that hasnt changed, Weinberg said, is developers snowing management. “They dont know what youre doing,” he said, “so they reward the appearance of work.”
While programmers embrace methodologies primarily because they want to write good code that fulfills their customers needs, theyre also cognizant of the challenges the processes present to management. One problem, according to David Heskell, senior Java architect from Sun Microsystems Inc., is the assumption that a methodology that works great on one type of system will therefore work great on all projects. That doesnt work because of dynamic project requirements (60 percent of requirements change by the end of a project, Heskell said), technical complexity, and the people issues involved.
There are, he said, 63 attributes that can provide predictive insight on project outcome. According to Heskell, only 27 percent of development projects complete on time.
In a panel discussion about agile methods, Joshua Bloch, principal engineer at Google Inc. advised developers to pay particular attention to the way they name variables. Code should read almost like English, Bloch said, and itll be better documentation. He told developers to use the same words in their documentation as in their code. “Better programmers get the names exactly right,” Bloch said.
An overwhelming theme at the show was is to choose methodologies that work for developers and their team. “People have taken [Extreme Programming] rules as gospel,” said Randy Miller, program manager for MSF Agile at Microsoft. MSF Agile is shipping with Visual Studio 2005 Team System.
In response, Bloch quipped, “How can something that calls itself extreme be interpreted loosely?”
/zimages/1/28571.gifCheck out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.