SANTA CLARA, Calif.—Programmers at this week's 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. They're 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."

Ambler's 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 shouldn't last more than a month. Ambler explained. "It's 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.

There's 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 it's Christmas," Weinberg said. Nontechnical managers may not be able to recognize quality (not that it's 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 hasn't changed, Weinberg said, is developers snowing management. "They don't know what you're 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, they're 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 doesn't 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 it'll 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?"

How useful are "modern" programming methodologies? Join the discussion in the DevSource forum.