|
|
|
|
||
| March 2002 | Vol. 3 Issue 3 | |||
|
|
Inside This Issue
|
|||
|
****** NEW! ****** |
Software Reuse By David Mosley Common wisdom dictates that we should reuse as much software as possible, but in practice we never seem to achieve this goal. Why? Various authors and pundits have long considered the problem. I would like to focus this paper on two articles which discuss software reuse. In an article he wrote a couple of years ago, Joel Spolsky1 discussed the situation at Netscape when they elected to rewrite software from scratch rather than reuse it. The results were far from encouraging. Spolsky also looked at the reasons why the Netscape developers and other developers favor rewriting code. In the most recent issue of Software Development, Scott Ambler2 suggests practical solutions to the problems of software reuse. First, let's review the Netscape situation Spolsky described. In April 2000, Netscape 6.0 was finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years previously. Three years is an awfully long time in the Internet world, and Netscape's market share plummeted. Spolsky did not account for the competition from Microsoft-it is likely Netscape's market share would have dropped regardless of the timing of the next release. Nevertheless, during that three-year period Netscape did not effectively respond to Microsoft's new product. They put themselves in that position by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. Spolsky argues that there is a subtle reason why developers always want to throw away the code and start over. The reason is that they think the old code is a mess. And the reason they think that is because of a fundamental law of programming: It's harder to read code than to write it. As a corollary of this axiom, you can ask almost any programmer about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over." Why is it a mess? "Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for." The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Software doesn't rust. Back to that two page function. Yes, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. But the answer is simple: Those are bug fixes. One of them fixes that bug when installing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. And so on. Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. When you throw away code and start from scratch, you are throwing away all that knowledge, all those collected bug fixes, and years of programming work. When developers say that their code is a holy mess (as they always do), Spolsky finds there are usually three kinds of things that are wrong with it. First, there are architectural problems. The code is not factored correctly. For example, the networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the user interface code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces etc. Even fairly major architectural changes can be done without throwing away the code. A second reason developers think that their code is a mess is that it is inefficient. You don't have to rewrite the whole thing. When optimizing for speed, 1% of the work gets you 99% of the bang. Third, the code may simply be "doggone ugly". One project that Spolsky described had started out using the convention of starting member variables with an underscore, but later switched to the more standard "m_". So half the functions started with "_" and half with "m_", which looked ugly. Frankly, this is the kind of thing you solve in five minutes with an editor macro, not by starting from scratch. It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same development team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version. And you're wasting an outlandish amount of money writing code that already exists. Spolsky's article defined the problem and suggested the kernel of a solution. In his article, Ambler proposes a methodical approach. The secret to increasing reuse within your organization is to identify and adopt the appropriate development techniques that create recycling opportunities. According to Ambler, organizations that are successful at reuse share several common philosophies. First, they recognize that you can reuse more than just code. Second, they acknowledge that something isn't reusable until it's been reused. In other words, reuse is in the eye of the beholder-not the creator. This harkens back to Spolsky's fundamental law that it is harder to read code than to write it. Third, reuse is a mind set. To increase the level of reuse within your organization, individual developers must actively strive to reuse the wheel rather than reinvent it. Fourth, successful organizations differentiate between project-level reuse and organization-level reuse because they recognize that they require different approaches. Ambler sees three general approaches to project-level reuse: grass roots, planned and external source. In grass-roots reuse, a developer builds something on one project and then adapts it as needed on the next project. This approach is common and fairly successful, because developers tend to work with similar technologies within the same domain. While developers readily reuse their own work, incorporating the work of others is the challenging part. Remember Spolsky's fundamental law. Both the planned and external source approaches focus on overcoming that hurdle. A planned reuse, or reuse-by-design, is often attempted, but unfortunately seldom successful. With this approach, you design an item from the start with reusability in mind, striving to make it sufficiently robust, so it's attractive to other developers. Of course, this effort often entails identifying requirements not directly applicable to your current project, including potential future requirements. In other words, you overbuild the item and hope that you guessed right, and other developers will find the work suitable for their needs. The third approach to project-level reuse is external-source reuse, which employs reusable items from outside your project, for example, commercially available components, free items downloaded from the Internet, and software from colleagues on other projects. The willingness to accept external software, and to examine, try and then modify it for your needs depends upon the mind set of the organization. Ambler believes grass-roots reuse works particularly well for project teams taking an agile approach to software development, particularly methodologies such as Extreme Programming (XP) and Agile Modeling (AM). If your process demands the creation of high-quality artifacts, you dramatically increase the chance that they'll be reuse candidates. Furthermore, if you've invested the minimum amount of resources to build an item (agile software development generally doesn't support overbuilding) you're more likely able to afford additional resources to extend the item to meet your new needs. Finally, Ambler also addresses organization-level reuse. Reuse of that kind focuses on systematic reuse across your organization's portfolio of software projects, a task often referred to as reuse management. There are two basic approaches-harvested and institutionalized reuse. However, organization-level reuse can be difficult because it requires processes and organizational structures within your department that are beyond the scope of a single project. Organizations that are struggling to deliver individual projects typically don't have the wherewithal to succeed at organization-level reuse. Nevertheless, Ambler states you can succeed at increasing the level of reuse within your organization. First, you must foster a reuse-positive mind set; second, recognize that there are multiple approaches to achieving reuse; and third, choose one or more approaches that fit best in your environment. Reuse is far easier said than done, but it's worth the effort to reap the beneficial repercussions of a project's success. References: 1. Spolsky, Joel, Things You Should Never Do. Part I, April 2000, http://www.joelonsoftware.com/articles/fog0000000069.html. 2. Ambler, Scott, Reuse for the Real World, Software Development, April 2002, Vol 10, No.4, pp 52-54, http://www.sdmagazine.com/documents/s=7032/sdm0204k/0204k.htm.
On the Front Lines
As Assistant Product Champ for the DACSTM (DDC-I Ada Compiler System) product line, Richard Frost has the responsibility of "front-liner" support issues for U.S. based DACS customers. Richard is responsible for development of the DACS-PC/NT version of the product. A valuable employee since 1996, Richard has extensive knowledge of the DACS debugger and run-time system, making him the perfect choice for taking the lead on the Comanche Helicopter Program, a large work related contract won in 1997. As Project Manager for this program, Richard works very closely with the Boeing/Sikorsky team, providing a customer interface for Comanche specific issues, acting as the lead for new development efforts on the program, and providing an interface for reporting and scheduling activities. During his 6 year career at DDC-I, Richard has also contributed to the development of the SCORE product line, writing much of the original code for the GUI. This experience also allows Richard to submit valuable enhancements to SCORE GUI team. Richard lives in Gilbert Arizona, with his wife Samantha and son Gregory. His true passion is spending time with his family, and playing with his son.
3rd Party Update
ARTiSAN brings UML to Ada Community In the Summer of 2001, ARTiSAN Software Tools (http://www.artisansw.com) released the first version of their new Ada code generation from UML. Real-time Studio has gained increasing acceptance among systems engineers and software designers in safety-related and mission critical software projects around the world. By bringing out an Ada code generator that supports full Ada generation, and also SPARK (the safe Ada subset), ARTiSAN indicated a new company focus on supporting safety related projects. This summer, ARTiSAN will release full "round-trip" synchronization for Ada, and in particular offer a reliable and understandable translation from legacy Ada 83 code into UML. As part of ARtiSAN's recognition that Ada is the language of choice for safety related projects, the synchronizer is being developed in cooperation with Praxis Critical Systems – the birthplace of SPARK – and supports the SPARK annotations for formal verification as well as the safe subset of Ada. (http://www.sparkada.com/) For more information on Real-time Studio or the Ada Synchronizer and its mapping to UML, please e-mail info@artisansw.com
Tech Talk: Debugging SCORE UCCs on PowerPC Debugging the UCC can be challenging, since no target code can be debugged with the SCORE Multi-Language Debugger, if the UCC is not working. In the event of a UCC bug, it is recommended that the user start by turning on the UCC test output by replacing the following line in initialize.c: ddci_tstio_install( &ddci_null_driver ); with either ddci_tstio_install( &ddci_com1_int_buf_driver ); if the UCC uses interrupt driven I/O, or ddci_tstio_install( &ddci_com1_non_int_driver ); if polled I/O is used. If there is no output at all, then always use the second option. The UCC startup code will then provide progress output on the serial line. The progress output that appears before the serial communication device has been initialized may have to be commented out, if the serial device has not been set up by some earlier board firmware initialization. The UCC contains functionality for the following:
Item 1) is hardware-independent and has only been placed in the UCC to make it easy to reconfigure the I/O, e.g. to switch between polled and interrupt-driven I/O. Item 2) is specified by the PowerPC architecture, it is common to all PowerPC processors. These two parts of the UCC are not likely to have problems, since they are basically common for all UCCs. Items 3) and 4) are the areas where closer examination will be required if the UCC startup hangs. Peripheral units will often be legacy units like the PC 16650 UART and 8259 interrupt controllers or units that are software compatible with these units. It will often be possible to find suitable initialization code in one of the preconfigured UCCs. The biggest challenge posed by the peripheral unit initialization can be to ensure that there is access to the peripheral unit. On modern COTS boards with multiple buses, it may be necessary also to initialize bridge chips connecting the buses before the peripherals are accessible to the PowerPC CPU. The preconfigured UCC for the Motorola MVME2400 board for example needs to set up the HAWK bridge chip before the interrupt controller can be initialized. If the board hangs right after the cache has been enabled it is most likely due to an error in the initialization of the IBAT and DBAT registers contained in the file set_simple_protection_bats.S. It is recommended to let the entire RAM area be covered by both IBATs and DBATs and it is essential that the address ranges used for I/O are covered by DBATs, but these blocks shall not be cached. Also please note that the start address of the BAT block must be aligned to the size of the BAT block. Another pitfall that may lead to the board hanging when the cache is turned on, is that the caching may already be active, if the UCC is started from a firmware monitor. In that case, the contents of the data cache shall be written back to RAM before the cache is invalidated as part of the initialization. An example of this can be found in the preconfigured UCC for Motorola MVME2400. After your debugging is complete, restore the file initialize.c to its original state by replacing the line ddci_tstio_install( &ddci_null_driver ); to prevent the progress text from cluttering the display.
Introducing New Technology into the Workplace We’re continually bombarded with new ideas for making our organizations better. We might attend a conference or read an article about an exciting new technology. How can we get things going in our companies? By Linda Rising I would like to share my experiences with patterns and the success of my former employer in introducing this new technology. After I tell my story, I’ll describe a book that I’m co-authoring with Mary Lynn Manns, a good friend and colleague and a professor at the University of North Carolina. My interest in patterns began at OOPSLA ‘94 where I signed up for a tutorial on "Design Patterns." There were four presenters: Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. At the conference, people called them the "Gang of Four." During the tutorial, the presenters kept referring to "The Book." [Gamma+95] When the exhibit hall opened the next day, Addison-Wesley wheeled in carton after carton of this book. The line of developers stretched the length of the hall and out the door. As fast as the cartons were opened, the books were sold. Addison-Wesley outsold by a factor of 7, any other technical book that has ever been introduced at a conference. The book is still selling well. But that was 1994! That’s old for a technical book! I think it’s because the ideas are "timeless." Those of you who have read my earlier introduction know that a pattern is one way of capturing a good idea. Most people who know about patterns have heard of the "Gang of Four" book. These patterns are for software designers. At first, we believed that they were for object-oriented designers but that’s not true. Many of these patterns can be used in any programming language. Patterns like Proxy and Mediator do not need inheritance or polymorphism. Now we not only have hundreds of patterns and dozens of books, but we have many different kinds of patterns: patterns for organization and process, patterns for testing, patterns for customer interaction. The list goes on. Jim Coplien was the first to notice patterns in organizational behavior. He was a researcher at Bell Labs looking at hyper-productive teams. He found that teams that were productive exhibited certain characteristic patterns while teams that were not so productive were missing one or more patterns. [Coplien95] The patterns that are the focus of this article are organizational patterns. They are patterns that help individuals introduce new ideas into their organizations. When I returned from OOPSLA, I was excited about what I had learned in the Design Patterns tutorial. I started talking to other developers and began a series of Brown Bags (presentations over lunchtime when attendees bring their own lunch and eat during the talk). I told my boss about patterns and the Brown Bags. He suggested I give a presentation to our vice-president and his staff. At that meeting, management wanted some assurance that patterns were a good idea. They asked me to continue the Brown Bags and each manager wanted to invite a specific technical person who could evaluate the new technology. After a few more Brown Bags, I reported to a follow-on staff meeting to receive further direction. All the technical people had voted in favor of patterns, so the managers said that everyone in the company should learn about patterns and asked me for a plan. My proposal was to buy a copy of the Design Patterns text for anyone who wanted it and to provide training. At the end of this training, I wrote an article for Communications of the ACM (on my web site) with Brandon Goldfedder, our trainer. [Goldfedder+96] My company was the first to support this kind of training and the only company in the world to date to train this extensively in patterns. Our project teams began using patterns and were able to show increases in productivity. It became part of my job description to keep the organization current with patterns. I wrote an article for Object magazine [Rising96] and the editor asked if I would like to write a book about the success at my company. My boss supported this and the result was The Patterns Handbook. [Rising98] This book has become a classic for those who are new to patterns. David DeLano, a colleague of mine who also worked with patterns, and I tried to describe in patterns, what had happened at our company to allow other companies to share our success. We held a workshop at OOPSLA ‘96. People came from all over the world. They were able to validate the patterns we had written and also add patterns of their own. The collection was submitted to a patterns conference or PLoP where a "shepherd" worked with us to improve the patterns and, at the conference, it went through a writers’ workshop. Shepherding is a special part of patterns conferences. Usually, when you submit a paper to a conference, a committee of reviewers accepts or rejects it. Many times you do not even receive reviewers’ comments, you only get an acceptance or rejection. This is very discouraging. Even if your paper is accepted, you may not know what you did that was good so you can do it again! When you submit a paper to a patterns conference, a shepherd works with you before it is reviewed by the program committee. It is the job of the shepherd to help you improve your paper so it will be accepted. At most conferences, when a paper is accepted, you will be asked to present it and the participants will listen and perhaps ask questions. At PLoP, you will listen and the participants will tell you what they think of your paper. The process is called a writers’ workshop. It allows you to make your work better by hearing suggestions from the others. Mary Lynn Manns was hired as a consultant in the summer of 1998 to introduce patterns into an organization. She used the patterns David and I had written. She extended the collection and also submitted her patterns to PLoP, where they were shepherded and workshopped. Mary Lynn and I began to collaborate at ChiliPLoP 2000. As we improved the combined collection, we held workshops at OOPSLA 2000 and OT 2001 and presented a tutorial at OOPSLA 2001. The patterns have been submitted and reviewed by people from all over the world. A pattern is a living thing. It is never finished. It continues to grow as people use it. The current version of the patterns can be found at: http://www.cs.unca.edu/~manns/intropatterns.htmlWe know that a pattern solves a recurring problem in a particular context or setting. There is the illusion that when a pattern is applied that there are no more problems. Our experience tells us that this is not true. When a pattern is applied, new problems result. Patterns are needed to solve these new problems. When these patterns are applied, more problems are created and so on. We hope that the problems become smaller and smaller and ultimately vanish but more likely they never end. We continue to solve problems throughout any kind of development. When a pattern author writes a pattern, it becomes apparent as soon as it is written and used, that there are more patterns to be written. A single pattern can’t exist without having a connection to a family of patterns. The collection of related patterns that solves a problem in a particular domain is called a pattern language. Christopher Alexander has written the best example we have of a pattern language. [Alexander+77] It solves problems in building architecture. Alexander begins by considering problems at the global level and ends by solving problems in rooms. If you want to use these patterns, you must start at some point in the language and use a sequence of patterns. These patterns define a path through the language, where one pattern leads to the next. A problem is created as a result of forces. These forces make the problem hard to solve. These are some of the forces that make introducing new ideas so difficult.
The result is—this is a hard problem! Organizations have individual characteristics. They define the nature or culture of the organization. Change is easier in some organizations or in some parts of some organizations because of the local culture.
Let’s travel one of the paths through our pattern language and examine some of the patterns in more detail. You’ll recognize these as the patterns I applied—even before I knew the patterns existed!
To introduce a new idea into your organization, let your passion for the new approach drive you. Brown Bag
Innovators
I started as an Evangelist. I approached the problem of introducing a new idea by being enthusiastic, telling everyone about patterns, showing them the Design Patterns book. I started giving lunchtime talks or Brown Bags. There are always people who will come to hear about anything new. They like new ideas and want to keep up with the latest technology. These people are called Innovators. If you want to introduce a new idea, find these people. They are key to getting things going.
Once you have found the Innovators, keep them interested with some kind of electronic forum or list. Let them know when you have any new information. Expand this electronic forum or list as you find more and more people who are interested in patterns. This can help you grow a community. Every company has resources that you can use. These resources can be people (web developers or trainers) or resources (rooms, equipment, corporate newsletters). Find out about these. Ask everyone for help—you never know who can provide the help you need. Use the new technology in your job. This will help spread the word and convince others that this is a good idea.
Enlisting the help of a respected senior developer can help your cause. A person who is respected by both developers and managers will give your new technology credibility. Sometimes you can find a well-known person who will come to speak to your organization. I was able to bring in people from Bell Labs for free because my company was a subsidiary of Lucent. Jim Coplien made many visits, gave talks in the auditorium, and met in small groups with developers and management. This helped people see the benefit in patterns. Having the chance to meet in a small group with a famous person is a special opportunity. Inviting a manager made a big difference in the support I was able to get for patterns. We have just talked about the path I took through the language. When Mary Lynn was hired, she began her path through the language as a Dedicated Champion. Introducing patterns was her job. Not only did she not have to do some of the convincing that I did but she also had resources—something Evangelists don’t have.
If you are an Evangelist, at some point you must enlist the help of your boss or Local Leader, to allow at least part of your job be to introduce and support the new idea. You will become a Dedicated Champion. If you are hired as a Dedicated Champion, you must still do everything the Evangelist does at the beginning: be enthusiastic; have Brown Bags; look for the Innovators; set up an electronic forum; enlist the support of Respected Techies.
Having resources means you can take the time to mentor projects that are using patterns. You can spend time consulting with other people, helping them find patterns to solve their problems. You can also have food at meetings! Patterns are one form of knowledge management—a very effective one. The message of the patterns community is that we all have something to share and we all can learn. Patterns provide a way to capture knowledge and transmit experience to others. The patterns in our collection have been successfully used in companies around the world to introduce new ideas. Take the ones that can help you and begin to change your organization! I would like to hear from you if these patterns have helped you. If you try these ideas, please share your experience with me! References [Alexander+77] Alexander, C.A. et al., A Pattern Language, Oxford University Press, 1977. [Coplien95] Coplien, J.O., "A Generative Development-Process Pattern Language," Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley, Reading, MA, 1995, 183-237. [Gamma+95] Gamma, E., R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Object-Oriented Software, Addison-Wesley, 1995. [Goldfedder+96] Goldfedder, B. and L. Rising, "Patterns: A Training Experience," Communications of the ACM, October 1996, 60-64. [Rising96] Rising, L., "Patterns: Spreading the Word," Object Magazine, December 1996, 54-57. [Rising98] Rising, L., ed., The Patterns Handbook, Cambridge University Press, 1998. About the Author Linda Rising has a Ph.D. from Arizona State University in the area of object-based design metrics. Her background includes university teaching as well as work in industry in telecommunications, avionics, and strategic weapons systems. She is the author of numerous articles and has published three books: Design Patterns in Communications, The Pattern Almanac 2000, and A Patterns Handbook. She is currently writing a book with Mary Lynn Manns: Introducing Patterns (or any Innovation) into Organizations, to appear in Fall 2002. |
Introduction to Ada95: --------------- FAA DO-178B Basic Seminar FAA DO-178B Applied Seminar --------------- Seating is Limited!
|
DDC-I Online News is published by DDC-I, 400 N.
5th Street, Phoenix, AZ 85004. Editor Jennifer Sanchez.
Comments and submission of articles are welcome and should be sent to the
editor at the address above or via email at editor@ddci.com.