As the saying goes, the more things change, the more they stay the same. And today’s developers face the same fundamental challenges as coders did back in the 1980s, says Ivar Jacobson.
One of the “Three Amigos” behind the Unified Modeling Language, and a co-creator of the Rational Unified Process, Jacobson is the author of “Object-Oriented Software Engineering: A Use Case Driven Approach,” and “Software Reuse: Architecture, Process, and Organization for Business Success,” among other computer-science standards.
Jacobson believes that developers lack common ground with one another, as well as an understanding of methods used by different companies and developers. Academic institutions are unsure how to teach software development to the newest crop of software developers, engineers and architects.
Not all is doom and gloom, though. “We are clearly improving in many aspects; usability of software is fundamentally better today than it was at that time, but if you have metrics where you measure productivity, taking into account that we have much better tools today then at that time, I think we have been developing at a constant level. We [software developers] have the same kind of challenges we had then,” he said.
“The world really doesn’t know genuinely what it means to develop. Everyone knows how he or she would develop software; as a community, there is no common ground,” he said, adding that this leads to developers and managers getting distracted by new technologies, and embracing newer methods without evaluating—and learning from—older methods.
“People run in one direction, and then they are stopped because something new is coming and they run in another direction,” Jacobson said, adding that there are 100,000 different methodologies available, something he believes is a positive thing.
Jacobson said he wishes to see 200,000 or more different methodologies in the future, but he also wishes to see some sort of library where developers at different companies can go to learn about the different methodologies and can learn where they might fit into existing processes.
Documentation for these practices doesn’t have to be extensive; in fact, Jacobson said that it should only contain the most important parts of a methodology, and they can be written on index cards. A description of the process isn’t as necessary as steps to enact the process, in his opinion.