Summary notes for teams A - O. The first datum recorded for each group is whether they were taught the EB technique or HB. The number recorded immediately after question 4 is the implementation score for the team (a rough measure of the percentage of functionality in the final system which was working as specified in the requirements).
1. What was done? Taught EB. Mainly relied on examples and guesswork (trial-and-error?). Had a hard time figuring out where to start. Tools were too unreliable and slow to use. Examples could be difficult because they didn't follow a consistent pattern. Documentation was vaguely useful, better than nothing. More effort towards end, felt more productive.
2. What base was used? Er - also studied Draw, MiniEdit Draw would have been a better source of reuse then Er, but there was so much extra stuff that it was hard to know what depended on what.
3. How was the team organized? Two team members - had separate files. Had regular meetings, no merging problems, but still needed better communication.
4. How effective?(84) Achieved: one-to-many generalizations. Negatives: overlapping links, not all dialog funct, views resize only Felt they concentrated too much on EB and not enough on obj. model => had to reimplement some functionalities because worked fine for first version but not for final. Would have preferred a mix of approaches. Hard increments were those for which no examples were exactly similar, or for which many ET++ classes were provided with little guidance as to which was the best choice. Able to reuse about 50% of LOC.
1. What was done? Taught EB. Had troubles with EB when: - examples didn't provide all functionality needed. - examples weren't consistent Also troubles with learning curve, integrating team members' work. Followed EB closely at beginning, more ad hoc toward end. Used multiple examples to get different aspects of the same functionality. Went beyond EB: Took examples as a starting point, then went back to ET++ doc to understand internals. Also analyzed ET++ source to see variants of functionality. (Spent a lot of time looking through source.) Documentation made a good starting point, gave ideas how to approach problem. Tools were not useful when needed to know about message passing, event handling. In general they were useful (Inspector, object composition).
2. What base was used? Er - also studied ThreeShapes, Draw, Filebrowser, Dialog, TwoViews, TwoShapes.
3. How was the team organized? Communicated well, but should have started earlier. Worked independently at beginning, less so at end. One group member couldn't contribute as much toward the end. Many integrations.
4. How effective? (94) Achieved: unique links, dialog boxes, resize & add views Negatives: one-to-one generalizations It was hard to get classes to display properly (resize, hide/show). Multiple views were hard because tried to do with Observers at first. Not much verbatim reuse, except from "easy" examples. EB was definitely the better approach, although having documentation would have made it better.
1. What was done? Taught HB. Needed a long time to know where to start. Felt they spent too much time analyzing ET++ classes, although this helped them to thoroughly understand the framework. This approach cost too much time, and wasn't really suitable for a tight schedule. Followed HB for 10 days, then went to examples - should have examined earlier! However it was still hard to build on examples, as they were someone else's code. Used hierarchy browser a lot at first, later it was easier to go directly to source. Also used Inspector tool. Used UNIX tools directly on examples and source. Could have been even more productive with better documentation. ET++ tools didn't help at all with trying to figure out function parameters. Code was poorly commented, and it was hard to understand where functionality was derived from, and flow of control. More productive at end, seemed to be over learning curve.
2. What base was used?
3. How was the team organized? Members were team-oriented and worked well together. Didn't (but should) use scheduling, group leader. Should have integrated smaller pieces of code at a time.
4. How effective? (81) Achieved: one-to-many generalizations, dialog boxes, resize & add views Negatives: overlapping links Hard to build on someone else's code. Also hard to compute and display the geometry of associations. Easiest functionalities were those which were found directly in examples. About 80% reuse achieved - though often had to throw out code that was already developed when found something usable in ET++.
1. What was done? Taught HB. Documentation was helpful early on but not later - needed more on _how_ to implement. Tried HB in beginning but went to examples after 1-2 weeks. Mostly did "learning by doing." Copied examples and manipulated code, recompiled to see what change in functionality resulted. Went back to hierarchy after looking at examples. Mostly used UNIX tools. Tried to use ET++ tools but were too hard.
2. What base was used? Assign3
3. How was the team organized? Each member had own increments, but did a lot of work together. Effort was pretty constant over time.
4. How effective? (88) Achieved: unique links, dialog boxes, resize and add views, one-to-many generalizations Negatives: Wasted a lot of time by incrementing things one way for a particular increment, only to have to redo later on. Hard increments were the ones that had to be redone later, and the ones they tried to do without looking at examples. "Built-in" functionality (two views, fonts) were easy. Also, one-to-many generalizations were easy due to the original implementation of links. Seemed much more effective at end (only 1 night to finish last incr.). Reuse varied by member. < 50% (a lot of customization to examples required), 75%, 80%
1. What was done? Taught HB. Hard to know where to start. Couldn't use HB - too difficult to determine functionality of classes due to lack of documentation, difficulty finding functionality in inheritance hierarchy. ET++ does provide a lot of functionality but can be hard to discover. HB was "the technique I use anyway" but would have been better with documentation. Forced to figure out what classes do by tracing through hierarchy. Went to EB very early, tried to look at examples to figure out which classes related. Used the documentation as much as possible. "Install" documentation was the only useful one, because it gave at least an idea of what classes do, and how to approach the problem. Would have liked the ability to trace execution. Tried to follow the original object model closely (might have been easier if had been more flexible about looking for ET++ replacements). Used obj. model to determine functionality needed, then looked at examples with similar functionality. Also grepped through files looking for names similar to functionality needed. Considered classes used in these examples and related classes. Object model was actually not so useful; redundant and incompatible with ET++. Didn't use tools much - hierarchy browser and inspector were useful but all were unstable and incomplete. By end, much more familiar with classes => more productive.
2. What base was used? Used Er as backbone of new system - also looked at Draw, Dialog, ThreeShapes.
3. How was the team organized? Some communication problems in beginning that got easier when team started working physically together. Worked independently, had lots of integrations.
4. How effective? (94) Achieved: unique links, resize & add views Negatives: one-to-one generalizations, dialog boxes only partly Hard to estimate how long a given increment would take (some bigger than others, and experienced a learning curve). Geometry stuff was very hard, especially since program took so long to compile. Twoviews was also hard; tried something but had to redo later. Easy increments were: fonts, autoresize, stretching, moving, the palette. Not much reuse achieved - only used the basics from the examples, usually had to redesign before using.
1. What was done? Taught EB. Spent most of time learning ET++ via examples, began implementing 2 weeks before due, spent a lot of time at end. Checked over all ET++ examples to see basic structure and how they worked. Found examples similar to increments, and then cut & pasted. Asked other groups about implementation; might find a better way to do the same thing. Didn't learn or use tools. Docs. were useful only in getting started - said what was there, but not how to use it (needed examples for that).
2. What base was used? Er - but needed to choose a better example, maybe Draw. Er seemed better for links, but turned out to be too simple in the end. Also studied: TwoViews, Draw, ThreeShapes, Dialog, FileBrowser.
3. How was the team organized? Lack of communication with one member, who couldn't contribute as much. One member did almost all coding.
4. How effective? (80) Achieved: Negatives: one-to-one generalizations, overlapping links, dialog boxes only partly, views resize only Didn't have time to extend code from examples as much as was necessary. Increments 1 and 10 were hard because they asked for a lot of functionality. Twoviews, hide/show were easy to understand and take code from examples. About 80% reuse - could probably have found more if looked harder.
1. What was done? Taught EB. Object model was well-designed and didn't need many modifications. Hard to get started implementing, getting used to ET++. EB helped in finding the right example, but did not always find an example for all the functionality needed. Used source code, manuals. Documentation was helpful at start but not in looking at examples. Went to examples after one week. Didn't use tools much - used hierarchy browser at first but it was easier to go right to source. Changed code & recompiled to see differences in functionality. Hard because few comments in source. Seemed more familiar at end.
2. What base was used? Er used as base - seemed better suited to first increment, Draw seemed more complicated. Also studied: ThreeShapes, VObedit, TwoViews, Draw, Dialog.
3. How was the team organized? Started late, effort picked up at end. Divided up increments, worked together on intermediate integrations and at end.
4. How effective? (87) Achieved: dialog boxes, resize & add views Negatives: one-to-one generalizations, overlapping links 3-region box was hard because no good examples. Link geometry was hard because it was difficult to find the functionality in examples. Simpler examples would have been better. Styles and links were easy once found the right examples. About 40% reuse - might have been more with simpler examples.
1. What was done? Taught EB. Only needed 3-4 examples. Used ET++ source, handouts. Feel they did increments in right order - first few, and then associations. Stayed close to EB, but didn't do a good job of comparing classes in examples to those in obj. model => led design to stray from original. Documentation too general, but useful once you took the time to learn examples. Didn't use tools very much, they were slow and unreliable - hierarchy browser showed too much at once. Went to source and examples.
2. What base was used? After first few increments went to Er as base - also examined ThreeShapes, Draw.
3. How was the team organized? Communication and organization problems. More effort spent at beginning, not so much after Thanksgiving. Maintained master copy of code.
4. How effective? (76) Achieved: resize & add views Negatives: one-to-one generalizations, overlapping links, dialog boxes only partly Had difficulties because not all examples corresponded to ET++ organization. Increments were hard for which there were few examples, or for which the examples weren't elaborate enough. Increments where the examples fit well were easy. About 50% reuse. Sometimes the examples were too elaborate to reuse directly.
1. What was done? Taught HB. Used ET++ docs from class. Hierarchy browser helpful, but tools too unreliable to use much. Looked at example code soon after start - HB not helpful. Selected examples based on execution behavior, grepping for specific classes. Documentation not helpful for beginners - gave big picture but not how to implement it.
2. What base was used? Built from assign3 - used examples to figure out classes, not as base.
3. How was the team organized? Divided up work badly - tried to give each member 1/3 of project without paying attention to how increments depend on one another => could not work in parallel! Had no group leader or schedule.
4. How effective? (44) Achieved: Negatives: one-to-one generalizations, overlapping links, dialog boxes only partly, views resize only HB works well in developing an object model but not in implementation. Increment 10 was hard because there was so much functionality involved. Hard to figure out how to dispatch events - examples all handled this differently. Hard to get started. Problems when someone used code from an example without understanding it.
1. What was done? Spent more effort week 3 and a lot at end. Used EB as base but traced example code in ad hoc manner. Printed and read examples (and source, when needed). Looked to ET++ source when couldn't find an example for all increments. Tools weren't so useful - only gave a top-level view, still had to look at code yourself. No comments in code made this difficult. Handouts somewhat useful but in general too high-level - didn't really understand until you'd spent hours at computer.
2. What base was used? Built off of assign3 (maybe should've used Er), looked mainly at Draw, Er. Also Dialog, Miniedit, Twoviews.
3. How was the team organized? Tried to work as independently as possible, with 2-3 weekly meetings. Started combining work after 2 weeks.
4. How effective? (77) Achieved: resize & add views Negatives: one-to-one generalizations, overlapping links, dialog boxes only partly Didn't feel more productive at end - felt more familiar with some functionalities but later increments were not very similar to previous ones. EB generally worked well, but had difficulties finding an example for all functionality. 3-region boxes were hard, because no explicit examples. Also hard to find examples for dialog boxes. Show/hide and twoviews were easy, little code needed. Mostly reused - did a lot of cut & paste.
1. What was done? Taught EB. Lot of wasted time in beginning - left a lot to do at end, but felt more productive. Had spent several all-nighters in beginning to get something working but had to throw out a lot of this code later => time would have been better spent learning basics of ET++. It turned out that adding extra functionality to the prototype was harder than was thought => should have compared examples globally, not just for one increment. EB didn't help much for cosmetics at end - maybe EB best in beginning, HB later on? Tools were helpful for debugging, but not for understanding examples. Documentation wasn't very helpful (only after the fact). Began by looking at example source code, but implemented a large part of the project from scratch, without looking at examples. As got more familiar, had own ideas and felt comfortable adding them, because they knew the effects.
2. What base was used? Used Er as base, also examined TwoViews, Draw, ThreeShapes, MiniEdit, Dialog, FindChange.
3. How was team organized? Worked independently but simultaneously - integrated to a "floating" master copy.
4. How effective? (94) Achieved: unique links, dialog boxes, resize & add views Negatives: one-to-one generalizations Had some trouble because couldn't find an example using a dialog brought up from the menu. 3-region boxes were complicated; getting multiple links between the same two classes was hard. TwoViews was easy to find and implement. About 60% reuse - integrated the structure of examples, but had to add extra functionality from scratch.
1. What was done? Taught HB. Began early - first 2-3 weeks spent on learning curve (felt less productive then), before real work started. Couldn't use HB because couldn't determine functionality of classes from source code, and documentation wasn't helpful (too high-level, not enough on implementation). Abandoned HB early. Went to examples to figure out what classes did. Got frustrated with tools (too buggy) and stopped looking for classes in the hierarchy after 1-2 weeks. Looked for functionality in examples; used grep in source directory. Shared lot of ideas with other groups.
2. What base was used? Based on Er - also looked at Draw, Threeshapes.
3. How was team organized? Never worked independently - only one copy of code. No set schedule - "just-in-time" planning - or group leader. One "hacker" member.
4. How effective? (101) Achieved: unique links, dialog boxes, resize & add views Negatives: one-to-one generalizations 3-region boxes were hard because a lot to learn and visuals take a lot of time. Increment 10 was a lot of code but not inherently difficult. Palette was difficult because added more than was needed at first. Menus, font/size were easy. About half was reused. Felt they made good use of existing code, but a lot of original code to customize to the project.
1. What was done? Taught HB. Lack of documentation made HB extremely difficult. HB could have been a lot more useful if knew the behavior of classes. "Install" was only useful document but still not enough. Moved to examples after about 1 week (didn't realize it was other technique). Used source code, asked TA, and read handouts. Spent a lot of time reading code - felt a lot more productive last 2 weeks. Grepped through source and examples (necessary to figure out function parameters) and used hierarchy browser. Tools helped a little when looking at examples but weren't used much. Went back to hierarchy when examples weren't exactly what was needed.
2. What base was used?
3. How was team organized? Worked on different, unrelated increments simultaneously. Some problems with merging source code.
4. How effective? (81) Achieved: resize & add views Negatives: one-to-one generalizations, overlapping links, dialog boxes only partly Should have paid more attention to order of increments and object model. Increment 10 was hard, because used trial-and-error to get dialog boxes aligned right. Easy increments were: twoviews, font, style. Reuse tricky to estimate - took a lot of code from examples but extensively modified it.
1. What was done? Taught HB. Implementation required little variation from design. Slow at beginning (hard to get started), lot of effort last week (but realized some functionality just couldn't get done). Felt a little more productive at end. Would try EB if asked to repeat this project. Maybe the best combination would be EB first, followed by HB? Accustomed to using EB, think HB more difficult. HB better for learning the hierarchy, but easier to learn using examples - can change code and see effect on functionality. Used: source, examples, handouts, notes, TA or experienced group member. Would have liked better (more reliable) debug tools. Documentation was too sketchy - could answer a question but generated even more! Looked at examples but used code from framework.
2. What base was used? Used assign3 as base.
3. How was team organized? Used many separate files and global vars to ease merging work. Well-organized, communicated smoothly. Some integration problems.
4. How effective? (87) Achieved: unique links, resize & add views Negatives: one-to-one generalizations, dialog boxes only partly Increment 13 was hard because didn't know how to approach. Had trouble finding some functionalities in examples. Twoviews was easy - had a good example for it. Reuse was about half.
1. What was done? Taught EB. Stayed close to EB, follows natural style anyway. Felt like finally over learning curve at end. Used "Design & Imp." handout. Helped a little, but mainly relied on examples' source code. 50-60% of time spent looking at examples, rest on implementing. Never used ET++ tools, but relied on UNIX tools.
2. What base was used? Used Er as base, also examined Twoviews, Layout, Draw, Threeshapes, Dialog, Assign3.
3. How was team organized? Two team members. Started soon, but didn't spend much time in beginning. A lot more time needed for integration at end.
4. How effective? (89) Achieved: unique links, dialog boxes, resize & add views Negatives: one-to-one generalizations Had a hard time figuring out where things get called, following flow of control. Increments 5, 10, 13 were hard - had to write a lot from scratch. Links were hard - had a lot of ideas, but didn't really know how to implement them. Twoviews was easy - simple cut & paste from example. About 40% reuse - get a lot of ideas from examples but have to rewrite a lot of functionality.