Software Engineering Matters

Fred Brooks, the author of the seminal book The Mythical Man-Month and the famous essay No Silver Bullet was invited to give a talk at OOPSLA 07. His Collaboration and Telecollaboration in Design talk addresses the issues that affect designs done in teams. Currently, the designs of complex systems are usually done collaboratively in teams because the design requires more effort and knowledge than what a single architecture can muster. However, design by teams present a new challenge: how do we get great designs when there are so many contributors? After all, it's pretty much a truism that too many cooks spoil the broth.

The key to achieving great design is maintaining conceptual integrity. Conceptual integrity is achieved when the system exhibits a consistent and unifying theme: everything seems to fit together seamlessly. Conceptual integrity is the presence of normalcy and the absence of radical designs in different parts of the system. A possible example of conceptual integrity would be the drag-and-drop metaphor found in most operating systems (done more right in some than others). If the system was design with conceptual integrity then drag-and-drop should just work everywhere. For instance, opening a file would just involve dragging it to the appropriate application; deleting a file would involve dragging it to the trash. In short, conceptual integrity (for the user and developers alike) creates an easy-to-use system with little surprises.

Ideally, conceptual integrity is easy to maintain when there is only one chief architect who oversees everything. This chief architect plays the important role of seeing how the pieces fit together. He might not understand all the details but he certainly knows at a high level how everything works. How would one achieve this in a team? It does not really seem possible to have multiple chief architects (in fact, that sentence seems grammatically wrong since chief already refers to a single person). There could be multiple architects but there is one chief architect who has the authority to make the final decisions. Even in an open source project like Linux, Linus Torvalds still has the ultimate veto power on what to put in and what not to put in. This almost seems like a dictatorship but if that is what is required for conceptual integrity then it is something that has to be done.

While collaboration should definitely be done, the need to actually appoint someone with the authority for making the final decisions should not be overlooked. According to Brooks, collaborative efforts such as pair-programming actually works to get ideas and design decisions out quickly. The important thing to realize is that certain phases of design requires decisions by an individual.

On the other hand, Brooks does not actually think that telecollaboration with all the fancy bells and whistles actually work. The phrase he used to describe this is profound: [telecollaboration sytems are] technologically-pushed rather than application-pulled. So most of the tools out there are just loaded with technology that no one needs to use. In fact, there is no need for fancy teleconferencing equipment: what is needed is a way to share the documents (via e-mail, source control, real-time editing, etc) and voice conferencing. Video conferencing does not bring any additional benefit.

Brook's thoughts agree well with what the two second-life developers said during a previous talk. The developers of Second-Life are located all over the world and they need to use telecollaboration as well. They use an application such as SubEthaEdit for real-time code editing. And they use the new 3D voice technology in Second Life to talk to one another while their avatars are positioned in a room inside Second Life itself. They do not use any form of video conferencing. This setup has been found to be effective for their development task and they have been using it for some time.

One final issue that Brooks addresses in his talk is the perceived malleability of software. Non-programmers have the notion that software is very easy to change - it's easy to add a feature, remove a feature or modify the feature. The software marketing industry is partly to blame for this perception since the marketing team is always touting that the latest version of application X and how it has 100+ features and tons of bug fixes. And they do these kinds of promotions annually. Is it any wonder that the masses just think that software is so easy to change?

In my opinion, this mindset causes many problems for developers. Requirements in software tend to change a lot more than any other engineering project especially once it has started. No one would change the design of a bridge halfway especially after all the foundation has been done. And yet, even after the architecture of software has been decided, it is not impossible to imagine the pointy-haired boss coming up to the developers and demanding a radical change. And this is why, agile methods have been so pivotal in the development of modern software systems.

Maybe people would think differently if they had something more tangible such as the printed source code to relate the efforts of software development. After all, it's easy to see how much of the bridge has been completed based on the visible structures. It makes me wonder if there are other areas which suffer from perceived malleability. I think fiction books suffer from the same syndrome since most editors might think it is very easy to rework the story line. However, this is not always true since the astute reader can actually find inconsistencies between the lines when the author changes the story line halfway through the book.

Fred Brooks is undoubtedly a very smart man. And his arguments, as shown in both the The Mythical Man-month and No Silver Bullet, hold true for many decades. In fact, it is unlikely that anything would come to contradict his arguments. After all, it's hard to challenge something that was written based on his observations on the projects that he was involved in. So when he says something about collaboration and telecollaboration, it's advisable for people like us to actually pay attention.

I spent the morning in the Educators' Symposium at OOPSLA. It was an interesting session but unfortunately I could only stay for 3.5 activities since I wanted to go for the Dynamic Language Symposium in the afternoon.

We started off with a short session on how to teach recursion to incoming freshmen by Michael Goldwasser from St. Louis University. He had an interesting way for teaching recursion to first year students: he would pick a group of volunteers who would act as nodes in a list that is defined recursively. He would set it up so that each node knew which was the next list (null being the next node for the tail of the list). He would then act as the main program and call out a function like count() which returns the length of the list. His call of the function was symbolized by throwing a real tennis ball. This tennis ball was slit open and contained a piece of paper that was supposed to show the activation record of the current method call. In the case of count() each volunteer would then throw the ball to the next node and await a reply. This is a great way to illustrate how recursion works. However, I was a bit skeptical whether this activity might distract the students from the main concept of recursion. I was also curious whether this method of teaching recursion had permanence in the students's minds. Lastly, I wonder how well this method would scale up to a class that has 100+ students. Either way this was a nice method and it did give me some ideas for things to try on my students next time.

Next we had a session on Scrum. This was my first introduction to Scrum and it was pretty intersting -- it's a high level process that emphasizes customer needs and iterative design but it is not focused entirely on software development. So unlike XP, it is not explicitly required in Scrum to do pair programming or test first development. However, most software developers who use Scrum will augment it with those two practices anyway. It was a fun hands-on introduction to Scrum but again unless there is a decent reflection session after the activity I am curious whether the students will actually understand what Scrum is all about.

After the break, Kathy Sierra gave a nice presentation on how educators can create more motivating materials for their students. There were some nice gimmick tricks such as using bright colored slides, using seductive images, using animation, etc. These are definitely some ideas that I have to remind myself to use next time. Kathy is an engaging speaker and she managed to capture the audience's attention easily. I think she was the perfect person to give the keynote for the Educators' Symposium. Kathy also had a list of books that she thought was entertaining and enriching to read as educators. Here is a partial list of those that I wrote down:

• Flow: The Psychology of Optimal Experience
• A Smile in the Mind
• What the Best College Teachers Do

Before I had to leave, there was a presentation on Extreme Learning by two professors from the University of Utah. Basically it is a form of XP but in the process of developing the software, you had to actually put down goals to learn something. So you are teaching yourself new things as you implement the project. Again, this seemed rather intuitive to me: every time you do any major development you are bound to have to dedicate some time learning something new. The only difference in this case is that the student has to make it part of the user story to learn a new technology. This is definitely something that would be a good approach in a graduate level class since graduate students are often more mature and know how to organize their time to actually learn something new.

The Educators' Symposium is definitely fun and interesting. I wished I could have stayed for more of the sessions but the Dynamic Language Symposium was too compelling to miss.

BOFs or Birds of a Feather Sessions allow people with common interests to gather and just talk about anything and/or everything about their common interest! This time I went for three BOFs, all of them focused around Squeak and Smalltalk.

The first one was on Tuesday evening and it featured several short talks by various people. I have to say that the highlight of that BOF was about the by-now-well-known XO laptop (formerly known as the OLPC laptop). We even had two demo units available for us to try out if we wanted. The XO laptop is a marvelously piece of technology for its price. Undeniably, it is built to withstand all the harsh conditions that it might suffer through. However, as mentioned by the presenters the biggest roadblock for this project might not be technology but the lack of actual educational contents to put onto the device itself. Right now, there are no official educational materials that will be installed onto the machines yet. And for a machine that is supposed to function as the all-in-one textbook replacement, this is a major predicament. In fact, it might be a serious blow toward the success of this system. And no one knows what is the best solution to this problem.

There were also two presentations on language tools for Squeak: OMeta and CAT. OMeta is a project by Alessandro Warth and is already available from SqueakMap. It's pretty compact and has some nice features for parsing languages. Alessandro has actually implemented a Javascript interpreter on top of it but the source is not yet available. CAT is another tool for language recognition by Jamie Douglas. It has more features compared to OMeta -- can support PEG and CFG, has better error messages, automatic AST generation and some AST rewriting. It's currently not released yet but from what I have seen during the BOF demo it is as good as ANTLR and I will definitely be looking into it. It might be fun and useful to create a simple IDE for CAT in Squeak like what AntlrWorks does.

At another BOF that I attended, Dan Ingalls did a presentation of the Lively Kernel project at Sun. Basically the project shows an implementation of a Squeak-like system in Javascript. Since Javascript is supposed to be cross-platform and runs on all modern web browsers, it is one of the best choices to implement this project in. And by taking advantage of the latest SVG features in new web browsers, one can actually create a lot of graphics without all the overhead of loading images. The demo for the Lively Kernel project is available from its website and runs fine on the Safari 3.0 and above.

The final BOF I attended was the Seaside BOF organized by Roger Whitney who is currently on sabbatical at UIUC. Unfortunately I arrived late for this BOF since I thought I have misplaced my keys and had to go to the lost-and-found office to check on that. I must have arrived more than halfway through the BOF since they were already going into the QA session. The attendees had very different backgrounds: there were some newbies like myself who have read about Seaside but have never used it and there were clearly some veterans who have worked extensively on Seaside. It would have been good if a quick walkthrough demo could have been done to introduce the newbies to Seaside development. Some attendees did raise some interesting questions. For instance, how many projects were using Seaside; what is needed to set it up quickly; which databases did it work with; what hosting options were available (besides hosting it yourself). Fortunately there is an up-to-date website, appropriately named seaside.st, that addresses those questions. I must say based on the short demo that web development with Seaside certainly has a different feel. It requires the developer to use all the tools from Squeak (or some other Smalltalk version). However, like Rails, once you have accepted the philosophy of Seaside, web development is certainly better than what it used to be.

I was fortunate enough to have the opportunity to go to OOPSLA this year. I say fortunate because I had to apply for a Canadian visa; and based on past experiences it can either be a painless ordeal or one where you are unsure what you have done to not deserve one. Anyway, all went well, and after 15 hours of driving and 12 hours of recuperative sleep -- I was not able to sleep in the van -- I attended the first day of OOPSLA without any problems.

The first day was relatively easy-going since I was not signed up for any of the symposiums and could freely choose which two tutorials (or none) that I wanted to attend. I chose the tutorials on Software Architecture by Michael Stal of Pattern-Oriented Software Architecture fame.

The first tutorial was during the morning session and was entitled High Quality Software Architecture. It was an interesting tutorial and I think I was the youngest person in the room. The tell-tale signs of balding heads indicated that most of the other attendees were professional software architects that were here to learn the secrets of the trade from Stal himself. Anyway, the first part of the talk was essentially a nice review of the material that I had read about a year ago when I took the Advanced Software Engineering class. In fact, I wrote articles on the books and papers that we read for that class here in this blog. Stal was using the same terms an definitions from the Software Architecture in Practice book. It was interesting to actually see how someone else who interpret that book since it was a rather academic book and it was hard to actually find someone else to discuss about it.

Stal emphasized three main issues that was only lightly touched upon in the book. And I agree with him that these three topics will help promote higher quality software architecture:

• Clear architecture vision: This is similar to the metaphor in XP or the ubiquitous language in Domain Driven Design. Essentially it means that the architecture should be driven by a clear idea of what you are trying to achieve. And the architecture should strive to maintain this goal in every aspect possible.
• Iterative Development: This is really important. Developers usually think of architecture as something that must always be done up-front. There is some truth to this since if you get the architecture (vs the design; see this for an explanation on the differences) wrong then there is a heavy price to pay in terms of development efforts. Stal solves this by introducing the concept of the baseline. The baseline is the core of the architecture that needs to be done right and will not change throughout the entire development cycle. The baseline is determined from a set of prioritized requirements from the stakeholders. Only the most important requirements shape the architecture of the baseline; the remaining requirements will be acted on later in an incremental manner. This balance on what to add first and what to add later makes sense: unlike design, software architecture will definitely permeate the entire system so it is essential to at least get the important aspects right the first time.
• Testing: It is necessary to be able to test that your system supports certain requirements. It is usually commonplace now to have automated tests for most of the functional requirements of the system. Stal claims that it is necessary to have tests as well for the system architecture. These tests need not be automated fully of course but they should exist nonetheless. Either doing it through a code review or a formal inspection would reveal missing requirements in the architecture. I talked to Stal about using executable Architectural Description Languages(ADL) to verify the architecture and he says that most of the time that approach is not feasible since it requires a domain expert on the ADL itself reaffirming what I thought about ADLs in the first place.

The afternoon session was on Refactoring Software Architecture. Stal admitted that what he was going to present was based on preliminary work but nonetheless he felt that it was essential enough to warrant a tutorial. I completely agree with him especially since he too mentioned the Grand Unified Theory of Refactoring at the end of his talk and if we have any chance of finding one we had to start thinking of a lot more about software in terms on refactoring and program transformation. Like Fowler, Stal motivated the indicators of architecture refactoring in terms of architecture smells or what he terms the lack of the following qualities:

• Pattern Density
• Symmetry
• Expressiveness
• Simplicity
• Orthogonality
• Emergent behavior

The list of refactorings that he presented were based in the spirit of the original refactorings by Fowler: he used a pattern language to describe them. When I first saw the first few refactorings that he presented I was confused by the scope of it: were they architecture refactorings or design refactorings? And this is where the distinctions in the paper Architecture, Design and Implementation might be useful. When I asked Stal, he explained that he treats refactorings that could have a percolating impact to be an architectural refactoring. So when you refactor something and it affects things below it then it is probably an architectural refactoring pattern. There is still this nagging feeling inside me that thinks that architectural refactorings might not be behavior preserving -- the quintessential definition of what a refactoring is -- but I just cannot come up with an example of this. So I could be wrong about this.

Stal has a list of roughly 30 refactorings. But the two that most interested me were Aspectize and Integrate DSLs. The former being that you might need to address some cross-cutting concern and use an aspect-oriented approach to solve it. This is actually the few times that I have seen someone promote aspects in an appropriate manner. Usually people are vehemently for or against aspect-oriented programming. Stal however, presented a clear case where aspects can actually be a good approach. The second pattern is all about not being reserved on using a Domain Specific Language for your architecture if you need one. Again, I think that the time for thinking in more than one language has come and this is one way to make good use of that approach. Software architecture can be a complex beast and while it might be usually over-kill to use AOP and DSLs for normal projects, architecture could be the key area where they should both have relevant roles.

Throughout both these presentations Stal mentions the need for iterative design and refactoring. He is clearly a strong supporter of refactoring. He realizes that all future software development can only be successful with decent and continuous refactorings. And he is far-sighted enough to see how refactoring can be applied not only to code but also other artifacts like architecture.

I was talking to Maurice and we both agree how our advisor, Ralph Johnson, could have made one of the greatest contributions to software engineering by introducing the concept of refactoring. Sure he has co-authored the book on Design Patterns but the main concept of refactoring is probably more influential. Thinking of software engineering in terms of refactoring and transformations is definitely how all future software should be developed.

There were a ton of demos going on at OOPSLA this year but I was only able to attend three of them. The three that I chose were all focused on Java or Eclipse development since I was really interested in finding out what we could use to make Eclipse a better environment for tool development.

Jazz

I did not go for the original demo of Jazz but rather stopped by the booth the next day to talk to some of the developers there. From what I heard, the original demo has some technical problems; they were doing a demo of two development team -- one team at OOPSLA and the other team in another part of the world -- and someone accidentally tripped on the ethernet cable and the demo could not go on after that.

Jazz is an all-in-one collaboration tool for Eclipse. It integrates version control, bug-tracking, task-management and even wiki editing! It could potentially do lots more but those were the features that I saw and which I was most interested in. In order to provide a better user experience the creators of Jazz decided to recreate some of the underlying features from scratch instead of relying on existing technologies that users have grown accustomed to. For instance, instead of relying on CVS or SVN, Jazz has its own version control system. When I first heard this I was rather doubtful of how necessary it would be since most developers are already using some system like CVS and might be reluctant to migrate over to something new. However, this issue is resolved by having an importer that takes the current CVS repository and converts it into a Jazz repository. I was at the booth during this demo and the person there actually imported the source code from CVS for the Photran project that we are working on and converted it into a Jazz project. The conversion retained the meta-information from CVS and this would ease the transition for existing projects.

The goal of Jazz is for all its features to work together seamlessly in a consistent manner. To fulfill this goal, the developers deemed that wrapping a myriad of tools such as CVS/SVN, Bugzilla, etc would not provide the best user experience. This might be true since tight-integration is one way to ensure that everything is working together without having to spend countless hours configuring all the tools to work together. Jazz comes with its own fully packaged server that contains all the tools that you would need to get started immediately.

The approach Jazz has taken is different from Mylyn, another popular Eclipse plug-in for collaborative development:

Mylyn FAQ - Eclipsepedia:

"At the EclipseCon and JavaONE 2006 conferences IBM demonstrated previews of Jazz, a collaborative team server and Eclipse-based client. Articles have remarked on the similarities between Mylyn and Jazz because both integrate tasks into Eclipse (Jazz's 'work items' and Mylyn's 'tasks'), and both provide change sets grouped by task. But there are both significant differences and complementary aspects to the two approaches. A key goal of Mylyn is to provide an open source framework to support integration of task management with existing issue trackers and source repositories. According to the presentations, components that come with Jazz include include a next-generation issue tracker and source repository and related lifecycle management tools such as project health. In addition, a driving and unique goal of Mylyn is to focus the UI around a usage-based and degree-of-interested weighted task context, which is complementary to the Jazz platform. Just as it integrates with Mylyn's Task List, Mylyn's Task Focused UI and task context model components are possible to integrate with other kinds of task management systems, such as the one provided by Jazz."

I have only begun using Mylyn recently and have been impressed by what I have seen so far. Our university Computer Science department has an existing JIRA server that we are using for our development needs. Mylyn connects seamlessly to it and works fine. It is this ability to interoperate with existing technology and tools that is the strongest advantage about Mylyn. Though I would really like to use Jazz it is not really practical to convince the technology services group to install a dedicated server for it when they are already using a bunch of existing tools that work well. I suspect the same situation occurs in existing software development companies as well.

The Jazz developers have already done a good job at reducing the initial risk of switching over to it by providing the importers/adapter that convert existing data into a format that Jazz can work with. If the Jazz developers could convince the Eclipse foundation to adopt Jazz instead of using their current tools, then it would make a big impact in convincing other projects to follow suit. Until then, most developers with existing projects might be less inclined to use it.