Software Development
The More Things Change...
Computing pioneer Gerald Weinberg walks SD West through software's past and future.
 Computing pioneer Jerry Weinberg ponders the essential conundrum of computing since the 1950s: The more the hardware changes ... the more software development stays the same. |
Of course, some things have improved: Displaying a photo of the mechanical calculator that inverted 10x10 matrices, Weinberg quipped to audience laughter, "My first job title in computing was ... 'computer'." Also unlamented is the former status of women in the industry. At IBM, said Weinberg, women weren't hireable before World War II. "Thomas Watson's philosophy was that any employee could rise to become president of the company, and, of course, a woman couldn't do that, so it wouldn't be fair," said Weinberg, fully aware of the irony involved. But during the war, women were hired—as "systems service girls." "Would you put up with that today?" Weinberg asked the audience. "I didn't think so." Thankfully, too, software developers no longer have to sing fight songs extolling the virtues of company executives—another ancient practice that remains unmissed.
Hardware Importance
In an era of massive computer power at practically disposable prices, it's easy to forget that computers were once immobile, enormous, expensive and individually constructed by hand, Weinberg reminded the audience. "Today, Dell says it will custom-build a computer for you," he continued. "Dell doesn't know what 'custom' means!"
According to Weinberg, a 4.4MB disk array was once as tall as its operator, and shook the building when it ran. Steel-tape drives were so dangerous that operators had to leave the room lest they be decapitated by a broken tape. And today's software development model was turned on its head: "When you rented a machine from IBM, you got me—for free."
Originally the province of hardware engineers wiring the machines, the job of developing software was eventually handed off to specialized programmers, said Weinberg, but the hardware was never far from their minds. (Of course not: Weinberg noted that a machine like the IBM 607, with a grand total of 14 decimal digits of memory, weighed in at two tons and gave off 26,000 BTUs!) "Half the time, if there was some error, it was the hardware not working. After a couple of days of debugging, you'd find that somebody had borrowed a vacuum tube."
Bug Hunting
Back then, finding and fixing the bugs was hard; sadly, it's still hard now: "Debugging is easiest if there are no bugs. [Laughter] Next easiest is if there's only one bug. If there's more than one, you start getting interactions ... and that's still true today; that's one of the general principles of computing and testing that hasn't changed in 50 years, but people don't seem to know that—they seem to think, 'We'll throw a lot of crap in there, and then debug it."
Software tools such as configuration management aids aren't so new, Weinberg said. They'd had them even in the days of punch card decks. Displaying a photo of such decks, he pointed out the diagonal lines marked down their edges. "And you can tell which deck was produced by the most professional programmer." The real pros, he noted, used two rubber bands around the deck.
"And it's the same today: The amateurs think they can do better by zapping the configuration management system." Likewise for how we listen to our support tools, Weinberg continued, noting that a logic-analysis flowcharting tool had actually prompted programmers stand up and complain that the flowcharts constructed from their programs were "a mess"!
As for continuous builds? "When I worked on the Mercury project, we did three builds a day," Weinberg said. When he asked for a show of hands, fewer than half of the audience members indicated that they perform that many builds.
What about open source? Programs were shared freely in those days, he said, especially among the Society to Help Alleviate Redundant Effort (SHARE).
Open Source and More
The danger of working in isolation from your users, of premature optimization? Definitely old news. The team that built Fortran, Weinberg noted, expended fully half of its effort on an optimization "feature" that so slowed most programs' execution that a special hardware workaround had to be implemented. "'Fortran will never last,' I said. Well, I'm still hangin' in here, hoping to outlast Fortran; I don't think I'm gonna make it."
Weinberg's closing admonition to the audience was simple, unvarnished, and will probably ring true a half-century hence: "My advice to you is this: If you don't keep up, you're gone."
—Rick Wayne
Is an Agile Patent an Oxymoron?
David Hecksel, senior Java architect at Sun Microsystems, proposes a
proprietary business process method for determining a project's agility score.
 [click for larger image] Panelists Dan Rawsthorne, Scott Ambler, Joshua Bloch and Granville Miller debated documentation and disagreed on its usefulness during David Hecksel's expert panel on agile software development. |
The question-and-answer portion ranged far and deep, with unexpected tangents from audience and experts into gender issues (Would more women in the field improve the often toxic social environment of software development?), people skills (As keynoter Gerald Weinberg said from his seat in the audience, "We're victims only if we allow ourselves to be. A doctor doesn't operate with a rusty scalpel and say, 'Well, a committee bought it, so I guess I should use it.'") and software development versus university-taught computer science (Scott Ambler described his maligned efforts to train college students to work in teams and maintain others' projects). But Hecksel also plugged his own patterns, peer reviewed by the Pattern Languages of Programming group founded by Ward Cunningham. The patterns cover methodology, methodology selection, team composition and management.
"I have an 80-page document with the Pattern Languages group," Hecksel said. "They have a shepherding process where they assign you a mentor. I'm not sure what I want to do with the actual output, if I can make that available yet."
But beyond the patterns, Hecksel's seeking a patent for a "System and Method for Software Methodology Evaluation and Selection." It seems Sun is wading into business-method patent territory—remember the uproar over Amazon's one-click purchasing method patent? Hecksel has also defined the Hecksel Agility Index, which appears in the as-yet-unapproved patent application as an "Agility score" determined by the project's people, process and technology:
"System and method for evaluating and selecting methodologies for software development projects ... A project context for a project may be defined. Attribute values for ... components of the project context may be determined. An Agility score for the project context may be generated from the determined attribute values. In one embodiment, a project context may be scored against each candidate methodology. The Agility score may be applied to an Agility curve for the project context to determine a best-fit methodology for the project ... In one embodiment, the plurality of methodologies may include methodologies ranging from lightweight to heavyweight methodologies ... [and] may include one or more Agile methodologies."
Hecksel spent 11 years at IBM and then served as CTO of Active Software, where he gained his rules background, working on product recommendations based on customer profiles.
"It's not a patent on the patterns—those are not patentable," Hecksel explained. "It's a blueprint of an application that would do a predictive assessment on what the best methodology or pieces and parts of a methodology would be. It may say, 'Due to the architectural complexity, do something on the architecture side similar to the SunTone Architecture Methodology.' That's often linked to doing use cases. However, if your team size is only eight and the flexibility of requirements is rather high, it may pick an Extreme Programming delivery approach."
Mitigating Methodology Misfits
But would enforcement of such a patent even be possible? Yes and no, according to Hecksel. "The enforcement on the usage would be difficult, but as a blueprint for an application, a very clear guide for how you measure these attributes, yes. Sometimes I refer to it as the eHarmony.com of methodology. You know how they look at compatible attributes for matching couples? This is looking at the same thing, but for projects and methodologies, along with patterns for mitigation—how you mitigate a methodology misfit."
Hecksel's not at liberty to discuss Sun's intentions with the patent, but he implies that a tool and an even broader usage are in the works, along with an announcement at Sun's upcoming JavaOne conference. One thing is clear: It's an interesting new wrinkle in the agile trend—and one that, at least at the metalogical level, goes slightly counter to the visions of Kent Beck and his ilk.
—Alexandra Weber Morales
Agile Experts Agree to Disagree on Documentation
Granville Miller: "It's worthless!" Joshua Bloch: "It
prevents fuzzy thinking."
Four questions formed the framework for the panel discussion on agility moderated by Sun's David Hecksel:
1. How do you formulate and document requirements?
2. Do programmers need to do documentation?
3. Do tools help you slim down a process?
4. Is XP applicable to all projects?
 [click for larger image] Software Development contributing editor Rick Wayne hosted a discussion on selecting the best tools and vendors. Pictured from left to right are Wayne, Paul Tyma, Joel Spolsky, David Dossot, Alan Zeichick and Scott Ambler. |
On tools, Software Development columnist Scott Ambler, true to form, didn't shy from controversy: "I want to see a show of hands. How many of you are doing MDA [model-driven architecture]?" Not a single hand was lifted in the audience of some 500 developers. "How many of you know what it means?" he prodded. Two dozen hands rose tentatively. "We have a fairly educated audience, but no one here seems to do MDA. Tool vendors want to sell us stuff, like those old CASE tools sitting on the shelf. We don't need it."
When it came to Extreme Programming, opinions weren't extremely divergent. According to Net Objectives Senior Consultant Dan Rawsthorne, "This is tough. XP is applicable to everything. The fact that it's validation centric is what's important. But you have to tailor the heck out of it." To that, Effective Java author Joshua Bloch replied, "I worship Kent Beck. I credit [the XP folks] for making unit testing sexy. I don't know how they did that. But many of the specific things in his book are applicable only to specific styles of project. The way I write programs with Doug Lee—it's not exactly pair programming. It's more like 'buddy programming': I write code and send it to him, and he comments on it." Bloch recommended setting up a good automated code-review program to achieve some of the same benefits as sharing a single keyboard, monitor and desk with another programmer.
In a "touché" moment toward the end of the discussion, Miller turned to Bloch: "When you do a code review, do you check the spelling in the comments?" "Yes, I check the spelling and the grammar throughout. Good code should read like English—but wait," Bloch replied, "I thought you didn't care about documentation!"
—AWM
The Services World Is Coming?
in his keynote, David Chappell touts change.
 David Chappell warns developers that SOA is just over the horizon. |
"The global agreement on SOAP has the potential to affect software development analogous to the adoption of TCP/IP 10 years ago. The result then was the global Internet," Chappell said, predicting that in the near future, "we'll see that same sort of ubiquitous connectivity at the application level."
It should be no surprise that this kind of move is coming, he insisted. "We know that pretty much all software we build eventually has to talk to other software. Doesn't it make sense that our default architecture should take into account from the get-go this need for connectivity in logic?" Previous attempts (CORBA, Java RMI, COM, DCOM) have failed, said Chappell, since vendors weren't all on the same page. But Web services are different, simply because agreement exists.
The Human Factor
Of course, even if all the technical issues were settled, "the real impact of this move to a service-oriented world is with people," Chappell pointed out. How do you motivate people to make the move? For example, if one group in a company builds applications that can be adopted by other units, what's in it for the authors? Chappell reported that in his consulting experience, a massive top-down-directed move to a company-wide SOA is the best choice from a technical standpoint: All the services can be developed together toward a common goal, with less time spent refactoring. "It's the way any sane architect would approach the problem, yes?" Most IT departments start out using a return-on-investment argument, Chappell said. "IT goes to the business, with all the credibility IT has [audience laughter], and says, 'Give us $5 million—we'll SOA the world and come back in three years with great ROI!' Doesn't work. SOA arguments based on ROI are DOA." Instead, he said, in all but a handful of cases, SOA adoption occurs incrementally.
Business Rules
Chappell went on to business process management (BPM), and explained how BPM, business rules engines (BREs) and Web services are entwined. "Application servers by themselves aren't sufficient to support orchestration," he explained. Again, the crucial trend is the convergence of vendor support on a common model: Web services to communicate among the business process logic, the legacy applications and the new Web service-enabled applications. It may even enable a new class of developer/analyst hybrid, said Chappell. The major vendors all support graphical development of the business logic that runs within their rules engines ("There's a standard for this called Business Process Modeling Notation that nobody supports yet," he said wryly). He stepped quickly through a graphical example of creating business logic in the diagramming notation. "But do you see objects anywhere in here?" he challenged. "Do you see classes? Inheritance?" Clearly, the engine will compile business logic to objects under the hood, he said, but it needn't be visible to the user. Today's model of embedding business logic in Java or C++ or C# code is flawed, said Chappell, because the logic becomes scattered throughout source files and is hard to find. But the advent of business rules engines, communicating via Web services and driven by graphical editors usable by nonprogrammers, is "about to go mainstream. Last year, Microsoft shipped a rules engine," he pointed out. "They don't enter small markets." This means that the kinds of business analysts who used to work in Visual Basic will now be able to work strictly on the business logic that's their specialty, rather than having to just pass requirements on to developers.
"This is the strongest force in development, the biggest thing we're going to face, for the next several years," he said in conclusion. "If you're open to change ... welcome to the service-oriented world."
—RW
UI Design: Can You Hear Me?
Jim Hobart's tutorial stresses listening skills.
 Jim Hobart advised SD West attendees that success rates could go up if they inject usability testing early in the development process. |
To generate a usable UI design, Hobart advised starting with a standardized presentation model (including screen resolution, layout and fonts) and brainstorming the system functionality on a whiteboard. Next, dig in and create a wireframe, then go on to modeling and simulation tasks, and finally, incorporate behaviors.
How do you measure usability? Most parameters are subjective, but a more objective approach is to track the errors per hour for a specific task, and monitor that rate over time. Shockingly, Hobart claimed, 63 percent of all projects fail usability tests—a statistic that hasn't changed in the past 15 years. Hobart contended that improvements are outpaced by rising and ever more-complex development.
Success rates can go up, Hobart said, if you inject usability testing early in the development process by prototyping and validating presentation models. He advised having a test process in place that includes the desired profile of testers, a prepared script and a recording of the usability test and logging behaviors.
Good modern UI design, then, uses agile elements: storyboards, a flexible design process, early customer feedback, standard design patterns and reusable components. Yet one of this tutorial's most vivid lessons was simple: Listening to and learning from your customer's needs is invaluable.
—Rosalyn Lum
Dr. Dobb's Journal Panel Highlights
Creators
of Python, Perl, SQL, the StandardTemplate Library and Scheme debate the
importance of languages.
Five of IT's greats—all winners of the Dr. Dobb's Journal Excellence in Programming prize—participated in a rambling discussion at SD West 2005 moderated by Jonathan Erickson, editor in chief of Dr. Dobb's Journal. The talk was understandably skewed toward languages, given the presence of Python creator Guido van Rossum, Java and Scheme cocreator Guy Steele Jr., Perl creator Larry Wall, SQL cocreator Don Chamberlin and C++ Standard Template Library creator Alexander Stepanov. Each offered spirited insights into the role of literature, math and learning in software development.
On the greatest language:
Steele: "I'm tempted to say that Java was the best language of the decade, but I think JavaScript has the better claim. The worst languages are HQ9Plus and Befunge. Very few people have ever used them, however, so they haven't caused much harm."
Chamberlin: "There's a tendency to feel like something that's more complicated is better. Languages today have too many features, and the effect in the aggregate is a decline in the elegance of computer languages."
Stepanov: "I believe the greatest programmer ever is [Donald] Knuth. Knuth uses C. Let me make a great pitch for C. Why is English a great language? Because Shakespeare and Dickens and Trollope wrote in it. The moment I see great code bases written in Haskell or Perl, for example, I will revise my view."
Van Rossum: "English is a great language because it's everybody's second language. English is the lingua franca. Underneath Python, Perl, Haskell and the Java Virtual Machine is probably a C implementation that makes it all possible."
On the role of mathematics:
Wall: "I think there's a cultural balkanization going on. There have always been language wars and editor wars. There seems to be a breakdown—different realms of computer science are not informing each other. You can blame it on postmodernism, if you like. I tend to come from a linguistic side of things rather than the mathematical side, but the two need to talk to each other."
Van Rossum: "Mathematicians have had very little to add to the world of programming, and in that sense, I have to disagree with the concept of mathematics being a foundation for programming."
On the learning process:
Chamberlin: "I wish I had more time for learning. The most effective way for me to learn something is to teach it."
Wall: "Try to learn something very different than what you already know. For instance, I'm now learning Japanese, which is different from Indo-European languages. I always thought reverse Polish notation was strange until I learned Japanese and realized that they speak reverse Polish notation."
—AWM
