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.

According to Jacobson, he and other leaders in the industry began to see this problem more often about two years ago. The remedy they developed was Software Engineering Method and Theory (SEMAT): a collaboration of companies, thought leaders and academic institutions as a way to attack what they believe to be the fundamental problems of the software development community.

They noticed that despite the different methodologies and different systems, there is a commonality in software development, and students need to be taught that commonality instead of just learning how to use a process or programming language.

The SEMAT group, according to Jacobson, has a three-year vision in which they believe they can fix the fundamental issues he believes are harming the software development community.

“We have a large group of people working together to develop a vision for SEMAT, a three-year vision,” he said. “After three years, we think there is a good chance that the universities will start to teach software engineering in a more theoretical basis.

“Today, if you go to universities around the world, when they teach software engineering, either they do it in a way that is not supported by the industry, or they don’t teach anything. They just teach examples or methods. This means we don’t have robust engineers, so they will fall in love with something new, because that’s all they know how to do. New technologies sound appealing and then developers are happy to run after that.”

He added that new methodologies don’t always contain all of the practices one needs for developing software. For example, Scrum doesn’t talk about gathering requirements or doing tests, so a developer would need another methodology in order to complete those portions of the software development life cycle, according to Jacobson.

Common ground
Jacobson believes that building winning teams—teams that understand which methodology fits into their existing programs and how new methodologies can be folded into existing practices—is an essential part of creating this common ground within the development community.

His consulting firm, Ivar Jacobson International, teaches development teams at medium- to enterprise-sized businesses in seven countries on how to scale their agile strategy across the company. “We don’t tell them about a particular technique [of agile methodology], we just introduce product management techniques, iterative development techniques, and other Kanban and lean technologies,” he said.

“We introduce agile techniques for product management, iterative development, Kanban-like techniques, use cases and user stories, combined into something that gets the best of these two worlds. We help them with architecture, which is quite demanding.”

Ultimately, in order to be successful, Jacobson believes a sense of community must be created in individual companies and among developers around the world.

“You need to create a community, especially in geographically distributed teams, so that you can inspire everyone to adopt it in a systematic way,” he said.