Because of the breadth and depth of Dr. Masood Mortazavi's knowledge and interests, as evidenced on his popular blogs.sun.com blog, On the Margins, his Meet the Engineer interview appears in two parts. Part 1 explored his thoughts on technology, virtual reality, the nature of open-source movements, and more. Part 2 explores his work as a Java developer and manager of a team of senior database engineers.
I started at Sun about 10 years ago with the J2EE reference implementation team, worked on continuous-availability problems, and participated in building technical relationships with our business partners in the telecommunications network equipment provider business. I've also worked as a Sun representative to Open Mobile Alliance and have filed several SMI (Sun Microsystems, Inc.) patents. Retrospectively, the patents show my interest in distributed systems and system dynamics. Among other projects, I was involved in carrier-grade J2EE investigations and high-performance computing (HPC) and high-availability (HA) studies with Sun technology partners in the telecommunications and financial services industries. Before joining Sun, I worked as a chief architect and an investigator on DARPA-funded projects with a focus on distributed intelligent computing, and I also worked for Hughes Satellite Systems. As a university student, I did a B.S. (U.C. San Diego) and M.S. (U.C. Davis) in applied and chemical engineering, and finished my Ph.D. work in computational fluid dynamics with a dissertation titled Vortex-Vortex Interactions and PDF Methods, under the guidance of professor Wolfgang Kollmann (U.C. Davis, 1990). After filing my dissertation, I could have started work in a national research lab, doing more computational fluid dynamics. However, I had spent my early 20s on this and was looking for something different. So my wife and I decided to go to China for a year. I worked for China's National Petroleum Company in Anda, a very small town in China's Northeast Province of Heilongjiang, teaching computational techniques for plant design and spending the winter weeks sheltered away from Anda's -25° cold in our residence hotel. I busied myself by doing research in logic, philosophy, and computational linguistics. After China, jobs for a freshly minted Ph.D. with little industry experience were scarce in the U.S., and I returned to U.C. Berkeley, where I pursued studies in mathematics, theories of computation, and philosophy (with Berkeley's Graduate Group in Logic and Methodology of Science). In the meantime, I finished my professional studies toward a master's degree in journalism (I had been writing for a school paper to support myself and had developed an interest in journalism) and later, while working at Sun and realizing the importance of a business education, received an M.B.A. from Haas School of Business. Late in the 1990s, still with the Graduate Group in Logic and Methodology of Science, I was fortunate enough to have a chance to study the philosophy of artificial intelligence with Hubert Dreyfus. Dreyfus is the author of What Computers Still Can't Do. He has also penned a number of other essays and books on technology and philosophy, including an important little book called On the Internet. Another great mentor was Oliver Williamson, with whom I spent a semester studying transaction cost economics. Williamson has authored dozens of books and essays on transaction cost economics, for example, The Economic Institutions of Capitalism and The Mechanisms of Governance, both of which extend Coase's and others' theories of the firm, corporate governance, and strategy. Transaction-cost economics has broad application to all kinds of economic systems. Some researchers have applied it to open-source software economies. java.sun.com (JSC): Tell us about your work with Sun's database group. Mortazavi: I'm currently the engineering and business manager for several teams in Sun's database group, including ones working on MySQL developer tools and on Java DB. My involvement with Sun's database group occurred in stages. In early 2004, my boss was looking for a manager. I was doing engineering work on mobile telecommunications platforms and application frameworks written in Java, and we had just added to our group some folks who worked on OSS/J. So I volunteered. I saw a huge promise in using Java platforms for mobile and Internet telecommunications service control and service-management applications. My boss set a condition that I should also manage a small group of database engineers. His proposal probably had something to do with my familiarity with Clustra. Clustra was a highly available, relational database engine in whose acquisition and evaluation I had played a minor role in 2000-2001, including some early technical evaluation and contacts with its system architect, lead, and CTO, Dr. Øystein Torbjørnsen, whose graduate work in computer science had formed a basis for some of the Clustra functionality. (Øystein later joined Fast Search.) That's how it started. Then in 2005 and 2006, I helped put together a team of engineers who worked on Java DB (Apache Derby) and PostgreSQL. In 2008, Sun acquired MySQL, and the rest is history. By the way, I personally have a special interest in Java DB. We embedded it in our J2EE reference implementation back in 1999, when it was known as Cloudscape. It was produced by an amazing group of database engineers (including Richard Hillegas and François Orsini, now with Sun), who had formed a startup with the same name and who wanted to develop a fantastic and robust Java database. They had succeeded for the most part. Cloudscape was later purchased by Informix. It then came to IBM through its Informix acquisition. IBM contributed it to Apache under the Apache Derby project. This was a great boost for this little, amazing database. Sun joined forces with IBM to continue the development of Apache Derby. Sun's contributions brought Derby out of the incubation phase and transformed it into a full-fledged Apache project. We also started distributing Derby as Java DB, which is a fantastic and promising technology with exciting deployments, such as its use on the client side of Zimbra and its use by PaperCut. It's worth noting that Zimbra uses MySQL on the server side. What's more, the MySQL and Java DB application code are quite similar on both sides of the Zimbra system. More recently, I've been charged with mandates that include management of MySQL developer tools: connectors, administrative GUI tools, the workbench, and docs. I hope to be writing more about this work in my blog entries in 2009.
JSC: You mentioned the Java DB project. In your opinion, what makes projects challenging to manage, particularly those involving open-source communities? Mortazavi: Projects are inherently difficult to manage, and projects involving participation in an open-source community have their own special constraints. What I say here is partly based on my experience managing Sun's Apache Derby development project through 2006, when our team delivered Java DB -- Sun's distribution of Apache Derby, a completely new persistence component and toolset -- into the JDK. Speaking generally, I can say that all kinds of ambiguities and changes, uncertainties, team interactions, and organizational complexities make projects a challenge to manage. In his book Microsoft Secrets, Michael Cusumano presents many good examples of these project-management problems as they apply to software engineering. Many software project-management subtleties have also been discussed in Frederick P. Brooks's Mythical Man-Month, with which most senior software engineers and project leads and managers should be deeply familiar. Brooks's main interest is how project communications and roles affect project efficiency and project complexity. Whether some project involves resources and interactions outside of the firm has always been a classic question. In the past, we had the concept of contractual agreements outside of the firm. Now, when interacting with open-source communities, we do not really have a contractual agreement with the community. Our "agreement" is mostly an emergent order. Our relationship with the community, in a sense, is ordered without a contract. Of course, Apache has a contributor agreement, as does Sun under the SCA (Service Component Architecture). However, these are akin to a membership fee or a membership card for participation in a commons. After the membership fee has been paid and the card obtained, we still have to have a model for how to proceed forward with open-source projects. We move forward by making our own contributions and meeting all other community constraints at the same time. Yes, there's a lack of total control. However, what we gain includes early community feedback and contributions, tested practices, and, somewhat ironically, better quality.
In running projects, and for the moment setting aside the special subtleties related to software development, I've learned that project-management processes, project models, and the roles that are selected and established within projects matter a great deal. Having the right structure reduces conflicts and delays, speeds up decision making, and improves productivity tremendously, especially when you go beyond teams of four or five engineers. Based on sets of well-defined responsibilities, we often define accountable roles such as project sponsor, project manager, lead, architect, and so on. Each of these roles has its responsibilities and resources and boundaries of power and influence. Even in the open-source communities, we have various roles such as gatekeeper, contributor, committer, developer, release manager, guru, and so on. Definition and establishment of roles and boundaries help reduce and avoid conflicts. Of course, with role-based project-governance models and without some amount of conflict, we are always in the terrible danger of limiting innovation and creativity, both of which require a good deal of freedom to experiment and to make mistakes. Team creativity requires a much more intense attention to how teams communicate, share, and generate ideas. Here in the Silicon Valley, folks at IDEO have worked hard to perfect the art of creative project management. In a sense, and to be more precise, they have honed and perfected the project-management processes as they apply to creative projects. I recently taught a project-management course at a local nonprofit university that exposed me to the Project Management Institute's Project Management Body of Knowledge (PMBoK), which is a project-management standard. In the software world, people do not pay enough attention to how projects as complex as Burj Dubai -- slated to be the world's tallest skyscraper -- are built. A very subtle point is the number and types of potential project-management processes that we need to select for our projects and the intensity with which we want to implement these processes. I'm not saying we need to use all the processes that are listed in the PMBoK, but I think that we can judiciously select where to put the emphasis on any given project. I remember that in one of the exams, I asked my students what project-management processes they would select and apply in a specific project -- for example, their own wedding -- if they could only select a limited number of these project-management processes to implement. The costs of project-management processes often force that kind of decision making. In some ways, even when we're not consciously choosing to officially implement certain project-management processes for our projects, we end up doing something about these processes in practice. These processes are part of the natural frame of doing a project. So, for example, in a wedding plan, we may not be conscious of the fact that we are using a change-management process or the fact that there is always a change-management committee, even if we do not think of these explicitly as a process or a committee. (One should expect the bride and the groom to be members of such a committee!)
JSC: What's happening in open-source database communities? Mortazavi: There's amazing growth in open-source databases, both in terms of variety and community activity. Sun has various offerings for three open-source databases: MySQL, Java DB, and PostgreSQL. Of course, Sun acquired MySQL, the company behind the MySQL database, and MySQL is Sun's flagship database for a whole range of applications. The MySQL community is huge, and Sun/MySQL will be fostering and growing this community even larger. Java DB grows within the Apache community and PostgreSQL within its own community. Sun has made significant contributions to both over the years. Then there are a plethora of other open-source databases popping up -- most notably, SQLite. Finally, we have a bunch of open-source nonrelational data stores and map-reduce technologies, such as Hadoop, which is developed through Apache. What does all this mean? For one thing, Sun's flagship product, MySQL, is used by numerous startups and Web 2.0 firms, not to mention Google and YouTube. There is also MySQL Cluster, a separate product targeted for HA applications. The plethora of open-source products proves that the age of few commercial products addressing all customer needs is over.
JSC: What are the biggest issues that companies have getting the most out of Java technology-based applications? Mortazavi: I would point to problems related to a mishmash of technologies, the lack of ability to select properly, and a relative increase in nonstandard, de-facto programming platforms. My advice is to keep to the standards and to Sun-supported technologies in this area. They are excellent and have been tested by time and the marketplace. Last time I checked, Sun still employs some of the best Java engineers in the world. There's already plenty that can be done with the standard platforms -- way more than anyone will need well into the foreseeable future. This is not to deny that there are also amazing innovations in Java applications across the software world. Some of the best are developed in reputable open-source communities such as Apache, in which Sun participates actively.
JSC: If there were one thing you would like information technology professionals to understand about the Java EE platform, what would it be? Mortazavi: Scalability. Java EE is an enterprise technology for scalability, separation of business logic and system concerns, portability, and long-term maintenance. In these areas, Java EE is truly unique.
JSC: You have filed a number of patents, all of which are tied to Java technology. Can you summarize the problems you've been trying to solve? Mortazavi: I have a strong interest in system dynamics of distributed software systems. This interest I may have developed while working on DARPA-funded projects as a researcher in distributed intelligent systems. It probably also has something to do with my background in basic engineering sciences, which has included quite a bit of applied math, dynamics, physics, and chemistry. My patents and invention disclosures fall into three categories. The first category has to do with high-availability and scalability technologies. Most of these ideas came out of a carrier-grade application-server project we ran in the early 2000s. This is prior to the Clustra acquisition. Our focus in this work was on handling application state through replication and on routing of requests to the correct application-server nodes. The second category focuses on failure detection and automatic recovery. Parts of this work transformed and led to other projects such as Shoal, which is also based on a large number of other innovations. The main issue here was to define and build a technology for automatic application recovery, where the application can participate in its own recovery, even through multiple chained failures. This involved definition of callback APIs as well as an execution system that allows for the nomination of recovering servers.
The third category was based on the fact that Java had made possible -- and made much easier -- specific technological visions such as true online software upgrade in the same application container. I developed some of these ideas while working on highly available application servers. Doing an online upgrade of an application involves both a conserving schema upgrade and an application upgrade. A conserving schema upgrade conserves the application and data integrity. It is possible to handle what might appear as nonconservative schema changes through conservative steps in schema and applications. (This rare case happens when an application has actually been simplified.) Another issue with online upgrades is the required class-loading and virtual machine technologies. JSC: If you could send out one message about Java programming, what would it be? Mortazavi: Using Java, you can better reason about your program's correctness. This has to do not only with Java's strongly typed system but also with the relative paucity of ambiguities in Java when compared to various functional, scripting, or even typed languages. Other features that are second nature to Java programmers remain crucial to reasoning about programs: automatic garbage collection and the threading system, for example. These innovations have made it possible for large numbers of servers to "choose" Java as their implementation language. It is not for naught that most application programs in services such as Google, Amazon, E-Bay, and Facebook are implemented in Java.
JSC: Do you have any advice to someone just starting out as a Java programmer? Mortazavi: Start simple. Learn the basics of the language, and even before that, make simple modifications to existing, running programs and see what happens. Tap into the amazing online documentation resources. Write the most advanced program you can concoct, choosing something that tickles your imagination, to stretch your own limits, and if you can, to stretch the limits of the Java platform. Get involved and write programs for some commercial or open-source software that matters and that people actually use. As you advance, select a great IDE to work with, say NetBeans. (Sometimes this is necessary earlier.) Keep learning about the systemic use of Java in system programming. There are lots of pleasant surprises there. Don't forget that billions of dollars of revenue have been generated and millions of people have been employed because someone at Sun Microsystems invented Java, and a group of dedicated engineers kept producing innovations around it. So contribute to the goodness.
JSC: Can you name some things you wish you'd learned in engineering school? Mortazavi: Yes -- more design, more marketing, more business, more economics, more management and organizational theory, and finally, more philosophy and art -- all in that order or some other combination, to create a good mix of ideas. Unfortunately, while going through four different University of California campuses, Stanford University, and some other schools as an engineering student and researcher, I didn't observe an interest in bringing these other disciplines into the life of an engineering student. Unfortunately, students are kept in the silos of their own academic disciplines. Even in science and technology, they are divided into various minidisciplines with very little cross-pollination. I myself did have some lucky breaks. For example, my Ph.D. advisor, Dr. Wolfgang Kollmann, was very open to my exploration of various areas. While conducting research in computational fluid dynamics with him, I also took advanced courses in biochemistry, embryology, linguistics, and linguistic neurophysiology, along with courses in art, philosophy, economics, and political science. I also worked on the university paper. This is a very general problem in American education that probably exists elsewhere as well. We're "mass producing" technologists and scientists with narrow focus and with little care for their development as leaders and creative inventors who can help us to disclose new ways of living, working, and prospering. European engineering schools have had a tradition of teaching these other disciplines along with engineering. We cannot compete globally unless we train top-notch engineers who have a broad perspective about how their technical work fits into other domains and who understand the institutional place for technology. Otherwise, it's highly unlikely that we will be able to continue to tap technology for the general social good, beyond the production of gadgets. JSC: What is the Java class that you couldn't live without? Mortazavi: It's very hard to choose.
JSC: Is there an intellectual discipline or fun activity that you feel makes you a better developer? Mortazavi: Emotional alertness. Many people are sensitive to this and take care of themselves. Others forget and let it atrophy in the throngs of work. In my early days at Sun, I liked retreating to the atrium in Sun's CUP02 building, where Java came into being. The large atrium was filled with amazing plants. Walking over on one of the bridges and looking into the atrium would improve my mood. What is beautiful has always reduced stress throughout human history and has made us much more productive in our lives. Some companies pack developers' rest areas with puzzles, where they compete to see who can solve them faster. They also provide other facilities at work to take care of people. I don't think this kind of environment is conducive to psychological balance, because it makes escape harder. I would rather be walking in Henry Cowell Redwoods State Park and pondering the majesty of the redwoods, or some equivalent thereof. Seeing things that are much older than ourselves, our technology, and the institutions around us can bring our senses back to the reality of our own impermanence and make us more humble. Our humility and care should also be balanced with a sense of purpose, discipline, and organization. As software developers, we actually affect our institutions and people's lives by creating a plethora of everyday interaction systems. It is for this reason that many software developers are keenly interested in the aesthetics and evolution of the systems they create.
JSC: What new changes to the platform have made your life easier? Mortazavi: The threading libraries and the generic type system are very powerful and came at a time when there was already a huge installed base of Java programs that didn't use them. So in that sense, they are new. The use of the new threading model greatly improves performance and program correctness when compared to the classical uses of the old threading libraries. There are ways to use the old threading libraries efficiently, but few developers were patient enough to use these more efficient programming models. The new threading system removes this barrier to good multithreaded programming. However, its power has not been fully developed. We are poised to experience truly great improvements in multithreaded programming. The power of generics in Java has not been fully realized in its installed application base, but it has some very cool new uses, particularly when it comes to highly modular and layered systems, and runtime plug-ins. The opportunities are tremendous. JSC: What do you enjoy most about programming? What do you enjoy least? Mortazavi: I enjoy developing software in an environment that allows developers to rapidly test ideas, strive for code brevity, and build useful programs that process a great deal of data and participate in a lot of interaction and dynamics. Architecting for modularity and good design is also high on my list of favorite things to do. Repetition that leads to no physical benefit or skill is what I enjoy least. I think I share this dislike with the majority of developers. JSC: Where in the process of programming do you have the most fun? Mortazavi: Doing architecture and good design, while working alongside great programmers. Good architecture and design foster even better creativity in implementation, which can lead to great software with good staying power. I have most fun when all this is getting translated to the first implementation of a system. I also like doing bugs in highly constrained systems, but this can be a grueling task if the original programmer has taken no care for how the program will be maintained.
JSC: What is the funniest thing that has happened to you as a developer? Mortazavi: Back in the mid-1990s, an Internet search company interviewed me for a job and asked me to reproduce, on the white board, a Java program I had written to implement a set of path-planning algorithms. I had posted the program as an applet on my web site at the mathematics department at Berkeley. Among other features, it produced a navigation plan -- and could demonstrate all intermediate plans visually -- through a set of user-defined geometric obstacles in space. It used A* search and some geometric algorithms to accomplish this task, and it had a user interface in which the user could define the obstacles and start the planning engine. The interviewers didn't believe that I'd written the program myself. What I wrote on the white board didn't encourage them to believe otherwise or appear to make them feel any easier. While the people who'd invited me to the interview were really excited about the program, I was literally shooed out of their offices by the CTO. I was dumbfounded and didn't know what to make of it, and it became a funny story I would later tell my friends. The story reflected the classic economic problem of asymmetric information in the concrete case of assessing people's skills before they have started working in a team. (I'm assuming the CTO was not shooing me away for some political reason.) Frankly, back then, Java was just another programming language to me. As a logician, I saw the differences among programming languages as a trivial matter: One programming language was Turing-equivalent to another as far as a mathematical logician was concerned. I was coming from academia -- with a background in scientific computing and then seven more years of graduate work on the logic and methodology of science -- I had no notion of what it meant to develop commercial software. Back then, for me, everything was just a piece of research conducted merely to discover some properties or characteristics of a phenomenon. I was attracted to Java's type-safety, garbage-collection, and other properties. I had written my little path-planning program as an informal test of Java's performance and as a test of my own understanding of some simple algorithm applied to a nontrivial case. I also wanted to know whether I could do highly intensive computational work with Java.
JSC: What are some surprises you've had in working with the Java language? Mortazavi: My initial surprise was its performance in comparison to C and C++, when it came to ORBs -- object request brokers. My next big surprise was its excellence in multithreading. For example, Java DB is a clear example of a multithreaded, multiuser database system that can scale linearly over dozens of computational cores. The case of GlassFish is another. The next surprise was Java's excellence in memory management through adaptive garbage collection and through easy in-program object recycling. Finally, a smart programmer with some background in modern math and type theory can reason about a piece of Java code much more easily than they can with code from most other programming languages. Potential exceptions would include LISP and ML. Others may come up with their own exceptions, but Java would definitely be included in the set of well-reasoned languages. (I'm coining the term well-reasoned to mirror the term well-formed formulas.)
JSC: Can you describe the process of writing code? Mortazavi: From a formal standpoint, it's easy to describe: requirements, design, implementation. From an informal standpoint, it's more subtle: interpretation, conception and imagination, creative meeting of constraints. What tools or systems we use are secondary, and unfortunately in programming, they often get in the way, because they can be hard to work with. Creating and running your first "hello world" program in a new environment can be much harder than writing your largest piece of code in the same environment. Creative inventions in how we program can bring huge benefits to writing good programs. When writing code, I used to imagine and dream about a 3-D development environment, where I could literally wire and work with color-coded objects through large movements with my hands and a voice-activated system.
JSC: Do you have any tips about writing better code? Mortazavi: I've often had to focus on logical structures, specific algorithms, and program dynamics when writing code. It often feels like I'm writing some kind of legal argument as we create and encode system behavior. Here, the best code makes the least and only the absolutely necessary assumptions, if any. For the logician, thinking of programs as a structure of predicates with bound and free variables can be very helpful. What's called a good method in Java -- or function in other, traditional programming languages -- is one that avoids local variables, which only serve for internal bookkeeping. The more internal bookkeeping we do, the more verbose our program becomes, which means the code will begin demanding that we break it up into more classes and methods.
JSC: What basic software problem would you most like to solve? Mortazavi: Intellectually, I like to work on long-running systems that have to perform some useful set of tasks with very high throughput, good distributed dynamics, and excellent resilience. However, this is a crowded field, or perhaps I've done too much work in this area. So I don't think it's the most promising domain of work, although we do need such functional systems. Usability problems also interest me. I'd like to be part of a movement to develop adaptive environments that enable non-programming professionals to put together systems that are usable in the specific context of their activities. This is already happening in the field of content aggregation, with various widgets that content professionals can embed in their systems. Similar possibilities may exist in other fields. For example, a surgeon or an assistant monitoring a patient can put together, just in time, all the charts relevant for that particular patient for easier view during the patient's hospitalization and recovery. Current programming and interface technologies should allow us to easily create such usable adaptive systems on our own, even when we are not programmers. The areas of peer-to-peer computing, social networks, communications technologies, and networks continue to be full of interesting problems, even though they seem to be based on traditional fields. Finally, a great deal of work can be done in creating intelligent scaffolding for our urban, living, and work environments. There's tremendous promise in this area and a great need for social investment. But I think, at least in the U.S., we will need some economic and institutional adjustments before this kind of possibility becomes real.
Meet Sun Software Engineering Manager Masood Mortazavi, Part 1: Reflections on Computers, Technology, and Life
|
| ||||||||||||||||||||||||||||||||||
 | |
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
Print-friendly Version
