This has been a very good year for computer science graduates. Almost all the graduates I know who want a job have one. Of those who are not going on to graduate school, the only ones who are not entering the work force right after graduation are those who haven't yet tried to find employment. And there are very few students in this category. Most of the Worcester Polytechnic Institute (WPI) computer science graduates that I know have received multiple employment offers. Now, I ponder whether they are ready to face the challenges that await them and worry like a mother hen if I've done a good enough job preparing them.
I have been thinking about how different the software development landscape of 2006 is from 2003, when I left IBM and joined WPI. Several words come to mind to describe what I think my students will face today -- complex, competitive, collaborative, distributed, and flat.
I'm not worried about their ability to handle complexity. As they progressed through the university, they were asked to tackle ever more complex problems, work under pressure, and stretch their creative thinking capabilities. They almost universally exhibit an advanced aptitude for understanding complex technology and its applications. They are the children of the technological age, and technical complexity will not be a deterrent to their success.
The real challenges will come under the headings "competition" and "collaboration."
I don't think that these two attributes of the software development landscape can be discussed by themselves. One phenomenon that has become commonplace in today's technical landscape is the increased number of alliances between competing companies.
It wasn't too long ago when someone had an idea, started a business based upon it, and expected the business to exist ten years later. They guarded their ideas and built a niche in the marketplace. They sold their products and programs, added new features, and looked for opportunities to add to the product line -- usually from internally generated ideas. When a competitor came along, they took actions to put them out of business quickly. In a niche market, this was an effective strategy. The rule-of-thumb was that if you captured the marketplace first, or invented a new marketplace, it was almost impossible to lose your leadership position. There were exceptions, but the normal case was that there was a leader and it took a lot to knock them out of first place.
This model is readily apparent if you look at computer manufacturers. IBM gained the foothold for mainframe computers and has maintained their lead. Former competitors, like Burroughs, Honeywell, and UNIVAC, have entered into different areas of high technology. Digital Equipment was the king of the hill for minicomputers. They were never able to successfully move from that market to the PC, workstations, or mainframe markets, even as the minicomputer market decreased. Sun Microsystems gained the advantage in the workstation market and, while they are struggling to stay profitable, they are still leaders in Unix workstations, but the boundary between the workstation market and the PC market is getting fuzzy.1
Manufacturing computer equipment is a capital-intensive endeavor, like most other manufacturing ventures. It requires raw materials, supply chains, fabrication facilities, and a lot of specialized equipment. Software is different. The main resource is the intellectual capital provided by the employees. Not all employees in a software company are developers; in fact, most of them are not. But people are the critical ingredient for successful software ventures. The need to collaborate, as well as compete, emerges sooner in software businesses because the market's demands are not for more of the exact same item, but for more ideas, more features, more innovative applications and tools. This demand cannot be met by simply spending more on manufacturing facilities. It can only be met by continual innovation.
The software industry has discovered that continual innovation requires a different model. Creating software is like doing research. It requires building new ideas upon previous work, looking for new ways to exploit known results, and adding something to the known body of knowledge. It is not a highly predictable discipline, especially when you attempt to add a lot of new behavior and functionality to a product.
As researchers have learned to compete and collaborate, software companies have learned to compete while they collaborate. We have seen collaborations that produced innovations like the Unified Modeling Language (UML) and development tools that support it. Tools that support Model-Driven Architecture (MDA) are the next generation of modeling tools. In order for the tools to have the maximum value to the users, they have to adhere to standards and operate with each other.
The two previous examples of collaboration point out an interesting shift that has taken place in the area of standards. Years ago, we standardized what we knew -- those things that we had used for a long time and had determined were stable. Like the common office stapler: If there was no standard for staple size, you would be forced to select your staples from the vendor who made your stapler. But a decade or so ago, there came a shift in the way we standardized things. Rather than standardizing common things, companies began to work to get their own implementations standardized as a way of gaining competitive edge. In many cases, this rush to standardize new concepts proved a hindrance to widespread innovation. If a company could "lock in" their implementation as a standard, their competitors would very likely have to spend time adopting to this new standard and, thereby, lose time adding value to their own products. While it may be difficult to get a universally accepted standard under this newer business model, if you can make your competitors support your formats, you gain an advantage. We see this phenomenon frequently today. You would be annoyed if your word processor or spreadsheet application did not support the industry leaders' specific formats.
Today, with organizations like the Object Management Group (OMG), we are seeing a different model. Organizations and individuals come together early in a technology's lifecycle to bring the best ideas together into a standard. This creates a more level playing field for anyone who wants to build tools to support that technology.2 But this model does not guarantee success. Several years ago, I was involved with the Open Software Foundation's (OSF) Architectural Neutral Distribution Format (ANDF), which was an effort to provide a way to package software that could be deployed and run on any platform, without requiring multiple implementations.3 Some interesting ideas came out of this, but it never succeeded. In fact, some companies who were members of the OSF actively worked to ensure that ANDF did not succeed.
What does all of this mean for the graduates starting their commercial career? Unless we prepare them correctly, they may think that developing software means that they get to "do it all." That is, like some of their course assignments, they come up with the idea, design it, implement it, and test it -- everything, from start to finish, all by themselves, or with a few friends. If we prepare them correctly, they realize that they will form part of a larger team. They will extend software products, possibly come up with new products that must work with other ones, adhere to standards, and fit into an organization's product line. There is a lot of room for creativity in all of this, but they have little chance of developing a complete product, from start to finish, without using other software for key features.
Distributed development teams are commonplace today. This is partly due to our systems' becoming larger and more complex. But the greater reason is that the technology available today supports distributed development better than ever before.
High-speed Internet access lets a worker be as productive working at home as she would be sitting in a cubicle in an office building -- perhaps even more so. The point is that with the right technology, I can be sitting at my desk at home and using the computer in my office at school, just as if I were sitting in front of it.
Organizations have found good reasons to support distributed development teams:
- They can leverage the talents of very smart people working together, without the expense of bringing them together physically.
- They can save the cost of office space by enabling telecommuting employees.
- Allowing people to work from home, or their location of choice, makes the job more attractive and possible for a larger, more talented workforce.
But with a more distributed development team come additional challenges that must be addressed.
The agile community champions software development by teams that are co-located -- all in the same room, working together, communicating directly, face-to-face. This may be an ideal situation for certain types of products and development environments, but it isn't supported by the trend towards distributed teams. So let's put aside labels like "agile," and simply agree that effective, rapid communication and feedback are necessary for any team to succeed. How can we promote these characteristics in distributed teams?
The evolution of groupware tools
One promising answer is that new tools, and changes to existing tools, have emerged to support distributed teams. Many products are available today that are worthy of the "groupware" label. Early groupware products were characterized by data-sharing among applications. Various office suites, and suites of development tools that were either loosely integrated or not integrated at all, were among the first groupware offerings. Teams suffered from the disjointed artifacts these tools produced and consumed. There was no connection between the requirements that you created with one of the suite tools, the code you wrote with another, and the tests you ran with yet another. It was difficult, if not impossible, to embed a spreadsheet table or chart inside of a text document.
The second generation of groupware tools linked the different applications together. Finally you could embed one type of document inside of another. You were able to trace requirements through your code and tests. Defects were submitted, and working sets of code and other artifacts that changed as part of the solution were grouped into working sets for future reference. But while they allowed us to share the artifacts we produced, they were not geared to true teamwork. We mostly used tools as individuals and distributed products for others to look at asynchronously, because these tools didn't help teams connect in real time. The synergistic effects of a group review or design session were missing. It took too long for everyone on the team to review artifacts and respond to other team members' comments by annotating the shared documents in sequence.
The next generation of groupware tools focused on these communications problems. One of the first tools I used to support a development team was Groove, developed by Groove Networks. It allowed a small, geographically distributed team to electronically meet and collaborate effectively.4 When I reflect on our experiences and the capabilities of Groove at the time, I'm amazed at how much it lacked, based upon what I expect today from my tools. There was no integrated version control system, and the Groove environment was completely detached from our development tools. Yet, Groove allowed us to capture meeting minutes, as well as share ideas and several types of artifacts.
Groove is a good example of this third generation of groupware tools. It leveraged the power of communicating over the Internet to provide multimedia support to our group. When we met, however, we had to use the phone since voice-over IP (VOIP) was not available. There are many other products that entered the market in the early part of this decade to support electronic meetings and distributed teams. Most of you have probably used one or more of them.
Collaborative development environments
Today, there are more advanced group tools. We have come to know them as Collaborative development environments. Some have been around for a while, such as SourceForge®, by VA Software. While SourceForge does not yet have support for real-time meetings, it has many features that make it easy for development teams to share artifacts and work in a more responsive manner than previous tools have.
Organizations have several options for collaborative development environments available to them. Some of them are completely open source applications like GForge,5 while others are commercial offerings like SourceForge and CollabNet.6
We use SourceForge Enterprise Edition as a central environment tool at Worcester Polytechnic Institute for several classes and capstone projects. One of the nice features of SourceForge is that it has an API for integrating other tools with it and extending its capabilities.
There are exciting developments and research in collaborative development environments today. IBM has a couple of initiatives that are interesting to me, including IBM Workplace™. Though not exclusively an environment for developers, Workplace does offer a host of enabling technologies that assist distributed teams of all types. The new project that everyone seems to be excited about is "Jazz." Jazz is a joint effort between IBM Rational and IBM Research to provide a unified set of tools for distributed development teams. The Jazz concepts have been in the research laboratories for a while. I found the paper, Jazzing up Eclipse with Collaborative Tools, by the IBM Cambridge Research Center to be an interesting introduction to this work.7
Frequent readers of this column know that I am a fan of Eclipse. If Jazz is based upon Eclipse, then I'm quite sure that it will add a lot of value to the way my students and I develop software. It also means that it's likely that we can build our own extensions to customize the environment to fit the academic context.
Eclipse already has quite a bit of support for group collaboration. One of the project initiatives is called the Eclipse Communication Framework (ECF). The front page for the project claims: "The Eclipse Communication Framework (ECF) provides APIs that simplify the creation of interoperable, extensible, reliable distributed applications. The framework is useful for aiding the creation of plug-ins, tools, or full Eclipse RCP applications, that require client-server and/or peer-to-peer messaging and communications."8 ECF currently supports different chat clients, shared editing, VOIP, and other communication mechanisms.
At WPI we've started a multi-year project to create an environment for distributed development teams that will use Eclipse, ECF, SourceForge, and other tools and technologies as its core.9 The environment will be designed to specifically support academic teams working in different locations, both on campus and in collaboration with different schools around the world.
This brings us back to the original point of this section. The students today will need to develop the skills that let them communicate clearly, effectively, and responsibly using the tools in their electronic environment. Again, the technology will not be the barrier to their success. Success will come by learning how to write clearly, formulate sound ideas, accept criticism, and respect the value of their team members. The skills will be different than they might have to use today in a small co-located group.
If you don't know what "flat" refers to here, then you haven't read Tom Friedman's book, The World Is Flat: A Brief History Of The 21st Century.10 I suggest you find a copy of the book and read it, or at least read the extended review of the book that appeared in The Rational Edge late last year.11 In a nutshell, Friedman describes how technology has "leveled the playing field" on a worldwide scale between countries and organizations of once disparate capabilities. He describes the significance of this flattening, and explains how governments and societies can and must adapt. Anyone involved in technology-related business needs to know about the topics discussed in the book. You may not agree with everything Friedman says, but you will certainly gain new insights about the globalization that is taking place in every industry today.
Never in the course of commercial and political history have we seen as much transnational collaboration as there is today. We can expect it to increase even more if we want to succeed. This is more than just working in a distributed development environment. It involves the integration of different cultures and collaborative efforts such as we've never before encountered. Companies and countries that are able to harness the intellectual and knowledge-based capital of their global neighbors will be the big winners in the coming decades. Friedman makes a convincing argument for this.
Before the flattening of the world, we had to do a good bit of traveling to know our global neighbors and understand their culture. I consider myself fortunate because I have been able to travel to several countries. I've lived abroad for a short time and have been able to immerse myself in a different culture. Many of the people whom I most respect have also traveled and lived abroad. I am convinced that there is a correlation between our global experiences and our ability to reason in a broad, open manner. I encourage students to travel and experience other cultures whenever I can. The university is a good place to see a true "melting pot" of students from many countries and cultures. The students learn to collaborate in the sheltered halls of the school. But, nothing can replace going off to another country and getting to know the people and customs in their own settings.
However, as Friedman points out, we do not have to physically travel today in order to work with people around the world or produce products for marketplaces we've never actually visited. If you want to start an international collaboration for a new software product, you can easily do it by starting a project on one of the many project hosting Websites and advertise for collaborators. It's not hard. You could have a "business partner" that you've never actually met. And you can be successful! It just takes knowledge, ambition, and a high-speed Internet connection.
Many of the graduating students at WPI already have global experience. We have project centers around the world, in places like London, Bangkok, Sydney, Hong Kong, and Venice. Most of the projects at these centers are the students' interactive qualifying projects (IQPs) that challenge the students to relate social needs or concerns to specific issues raised by technological developments.
What else can we do to get the students ready for the new, flat world? We can provide more opportunity to collaborate in class work and research with schools and organizations around the world. Many schools are already doing this to some degree. We need to increase this dramatically. We need to teach our students that competition and collaboration in the flat world requires a true win-win approach. We don't need to crush the competition to succeed. We need to collaborate in ways that capitalize on each partner's strength in complementary ways.
More than anything, I think we educators need to continue to instill in the students a healthy intellectual curiosity and ability to reason. The student needs to realize that learning is a continual process -- one that is both enjoyable and necessary. We need to instill in them a true love of learning and the values that go along with it.
We need to teach our students how to innovate, how to evaluate ideas on their merits and exploit them. They need to understand that people around the world now have the same capability for doing software development. True, they must learn how to build quality products quickly. But more importantly, they have to learn how to innovate and leverage the work of others. Students in the United States and other industrialized nations can no longer compete based upon their information infrastructure and tools. Everyone has these. The students today must value innovation and develop a passion for excellence. They have to want to succeed, not just get a job and pay the bills. There are too may others in the world who are willing to do that for much lower salaries.
One passage in The World Is Flat points this out to me in very stark terms. Friedman talks about how young people in China were hanging from the rafters just to hear Bill Gates speak. They have an ambition and a desire to learn from the successful entrepreneurs. At the end of the section, Friedman has a paragraph that gives me my marching orders as a teacher, and also sends a chill down my spine. "In China today, Bill Gates is Britney Spears. In America today, Britney Spears is Britney Spears -- and that is our problem."12 Thus far, my students don't get the two confused, and I intend to make sure that they never do.
1 See the Computer Business Review Online article that discusses the workstation market for 2005: http://www.cbronline.com/article_news.asp?guid=E579CA31-2B44-44BC-933C-5A714368E9F6&z=rc_OpenSource
2 A good example of such collaboration can be found by looking at the MDA pages on the OMG Web site. http://www.omg.org/mda/
3 We might look at this idea today and think that Java satisfies the conditions. However, this effort was also supposed to allow you to build your product with any of several languages, and deploy it to platforms for which you have never compiled and tested it.
4 We documented our experiences using Groove in Software Development for Small Teams, Addison Wesley 2004.
5 See http://gforge.org/
6 See http://www.collab.net/ for CollabNet information and http://www.vasoftware.com/ for information on SourceForge.
7 The paper can be obtained from http://domino.research.ibm.com/cambridge/research.nsf/0/7ee2b2e5648ab96885256dc7006fc670/$FILE/TR2003-12.pdf
8 See http://www.eclipse.org/ecf/
9 See https://sourceforge.wpi.edu/sf/sfmain/do/viewProject/projects.webfoot
10 Thomas L. Friedman, The World Is Flat: A Brief History Of The 21st Century. Farrar, Straus, and Giroux 2005.
11 You can find this review at: http://www-128.ibm.com/developerworks/rational/library/oct05/reader/halovanic.html
12 Friedman, Op. cit. p. 265.
Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a BA in mathematics and an MS in computer science.
Comments (Undergoing maintenance)
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
