AO_UMLFEVER\nAO_GETTER_SETTER

I agree with the opinion of Allen Holub in that getter and setter functions are only needed in extreme cases where you can’t get around them using objects. The fact that getter and setter methods were originally used in procedural programming is still apparent today even though we use object oriented programming. In most of the introductory programming courses in college today getter and setter methods are emphasized in accessing variable data, but that defeats the idea of OO programming. Since we are geared to that mind set our code becomes hard to maintain and update do to type constraints. We should be taught not to use them instead of being encouraged to.

Alex Bell treats the idea of UML as a disease hampering software engineering. The article read like medical report listing a ridiculous amount of signs of the disease. The fact that he listed so many is just a sign of how most companies may still not understand the correct implementation of the UML idea. Bell’s article told us how to identify the fever but he did not go into how to go about curing it.\n\nGrady Booch’s article stands agreement to the opinions expressed in Alex Bell’s article “Death of UML Fever”. Booch gives a bit of a historical background of what UML is and what it was meant to do. Those companies who have trouble with the implementation of the UML design don’t truly understand it. \n\nIt just goes to show that a good idea in the hands of people who don’t know how to use it is a dangerous thing.

BO_UMLFEVER\nBO_GETTER_SETTER\nBO_SYDNEY\nBO_WNAA\nBO_TD\nBO_IR\nBO_LL\nBO_ENTROPY

I think the effects of software entropy are not only caused by revision cycle, but also in changing developers. A number of codes I have reviewed were originally created by a developer who left the project to another who eventually left the code, etc. until it reached me. Looking back at some of the codes, one can see a definite "personality" in the coding style of the programs. Reviewing old codes many times feels like listening to a person talk that switches between Texas, Cajun, and New Yorker accents. There is no elegant flow from one code segment to another. It takes a considerable effort to make the context switch from a segment filled with for loops to a segment rich with while loops.\n\nIn response to DC: \n\nIf I did noting on a computer other than software development, I would definitely choose OS X today. I agree that the OS X interface is much more intuitive than the XP interface. I also believe that people assume certain aspects of their environment. Code cleanliness is probably one of them. A clean interface is much more pleasing to interact with and less frustrating.\n

When faced with the question of whether to write a getter or setter for a private variable or make the variable public, one must decide whether encapsulation is beneficial in the given instance. The article seems to argue that encapsulation is a good thing. “All things in moderation” is what I say. In certain instances one may want to override the encapsulation principle to make an application more efficient, easier to understand, or maintain.

Information Radiators are priceless to the development of any engineering endeavor (software or otherwise). I work in an experimental lab that has many different types of systems (thermal, vacuum, water pumping, electric, etc.) that run the experiment. Not only is the status of the systems important to the progress of the team, it could be a safety hazard. Our white board (the information radiator) with magnets lets anyone entering the lab know if any system is “un-safe.” Knowing the state of co-workers responsibilities has many times helped me to plan my work as I walked between the front door and my desk.

I totally agree with the idea of having a large GO, NO-GO indicator in the work area. The goal for the team should always be to continue progress. One the Red light comes on, many tasks are blocked from continuing until the specific error is solved. In an agile team where collective ownership is accepted, the NO-GO indicator will spark many minds to begin searching for the root cause the error. It may be a simple error, solved by a single individual, but the collective solution may mitigate other issues down the road.

This example right here shows how inadequate the waterfall model is to any complex project. The customer (the government) changed the requirements before the “analysis” and “design” phases were complete. The project was years behind before implementation had begun! Once construction had begun the “customer” modified the design further by requiring two additional theatres be constructed. It’s no wonder the project completed after 16 years (12 more than predicted)

After reading a number of articles from the internet about technical debt and thinking about my professional experiences, I believe that a technical debt will be paid, one way or another. Sure, quick and dirty code may work. It may work for a long time, until one day when the project needs to add functionality without degrading timing or memory usage for certain sections of code. Either the developer must refactor the existing code to compensate for the burden of the new code, which will take longer because it is badly written, or take extra time optimizing the new code to run within a very small footprint. Maintenance, no matter ho insignificant, is greatly complicated by any code written quickly (borrowing from “Technical Bank”). The same applies to quick and dirty designs as well.

Bell’s article, “Death by UML fever” makes light of the tenacity that many developers fell when clinging to UML and refusing to move on with the project. Bell points out that UML is not the perpetrator, but the victim. Just like the abuse of prescription medicine is disastrous, so is over-using UML. I believe UML fever is a new strain of what I would call “Block Diagram Fever.” I have seen a number of system diagrams for engineering projects that were so detailed on could not see the forest through all the trees.

As a newcomer to the large scale software projects (projects involving more than 1 or two developers), the debate over what an architect “is” does not strike me as the most important tidbit of knowledge contained in the article. The discussion on irreversibility and the immense adaptability (compared to other engineering disciplines) of software struck me as key. An architect, to me, is a person that makes the design of the application more efficient from a topological standpoint, easier to understand by developers, and easier to maintain or implement new functionality.

BT_SYDNEY

The construction of the Sydney Opera House was grueling. It seemed to be an agile process with a lot of designing. The reason why the project took a long time was that the government did not trust Utzon. The other reason was that it was one of the first immensely complex geometric buildings created. Lots of designing had to be done. The design changed in the middle of the project. I think there was a lack of communication from producer and client, which created tension. Thus no progress could have been made within a negative environment.

DC_SOMME

CG_UMLFEVER\nCG_GETTER_SETTER

For the most part I will agree with that author that large scale projects need to stay away from accessors in favor of a more abstract purely object oriented approach. Sure it will take a lot more time to think up and plan properly but it will save trouble later when changes need to be made. However I think that in smaller projects going for full out OO approach might be a bit overkill and overly complicate the development of said project, causing it to take much more time to develop than with a more linear approach to the problem. [Venkat's note: So, in this cases, why not drop the accessor\nand add them when you really find a need for them?]

I think the author unfairly casts UML in a bad light with this article. Sure he mentions that UML is not the DIRECT cause of the fever, but since all his examples usually include instances of UML abuse, it doesn't really help. In my opinion a more generic title would have been more appropriate since the cause of the fever in general seems to be more related to big business and corporations, rather than any specific method of doing things.\nFor example, the company I work for has grown quite a bit since I started my employment, and has just recently gone through a merger with another equally sized company, to become what I would call a "big business". On of the newer upper management fellows seems to have be afflicted with "blind adoption", but instead of pushing UML down our throats his vice is Microsoft. He moved our company away from using very flexible and free methods of communication to very slow, locked and bloated MIcrosoft software. And so far the processess has been very painful and expense vice, and simply because the manager had this "blind fever". For clarity, my company does web hosting, and has upwards of 20,000 servers. 90% (a made up number, but probably close) running RedHat, and as such most of the people who do the actual work in the company use linux.\n

DC_UMLFEVER\nDC_GETTER_SETTER\nDC_SYDNEY\nDC_WNAA\nDC_IR\nDC_LL\nDC_TD\nDC_SOMME\nDC_ENTROPY

Software Entropy is a seemingly benign and simple concept. Yet upon a closer look, it is clear that Software Entropy is existing and constant in every project. I find the concept especially applicable when I am joining an existing project. Often times, I find the existing code clumsy and needs improvement. However, instead of discussing improvement with my teammates, I would continue the trend and develop patches of code which keep the code messy. On the other hand, if I find the code to be in good shape, I will continue to keep it "well-groomed". \n\nI also find that there is a fine line between Software Entropy and Meticulous Syntax Rules. A syntax convention promotes readability in codes by different developers at the cost of initial adaptation effort. There is also the factor of editor. Certain editors will only speed up certain syntactical convention. This makes the adaptation to a new convention even more challenging. Thus, I did a little research and found that most team would adopt an editor and stick to it. I also see an interesting trend in developers moving to Mac. Maybe this is just my personal opinion, but it seems that the OS X interface provides for an unobstrusive and clean experience which promotes code cleanliness. Does anyone have some thoughts on this? \n

I read the article "Why getter and setter methods are evil" by Allen Holub along with several comments from our class members. What I found interesting is many of our class members are used to the practice of implementing accessors. Albeit this is not a good practice as the article has showed. All comments I have read so far agree on this. The article does provide a introductory method to programming with minimal use of accessors (via CRC cards). However, I was hoping that the author would cover some material on how to move an existing project from using accessors to not using accessors. Albeit, starting from scratch is a possible choice as the new implementation would save much effort in future maintenance, I can't help but wonder if there is a better way?

I have seen countless of time when a group try to facilitate information exchange through electronic documents, instant messaging and any other high-tech solution they can think of. Yet, they oversee a proven communication method: paper and pencil. The article on Information Radiator by Mishkin Berteig and several pictures on Wikipedia regarding this method are eye-opening. \n\nWe people tend to complicate things. Well, at least we try to use one tool for as many jobs as possible. We all miss the fact that we are slowing down as we digitize our communication. Being able receive information as soon as possible is the very core idea from which our collaboration software is built. Information Radiator takes this requirement and change it around. Why do we need to click buttons in order to get information, why not let the information come to us. By the use of whiteboard, stick-it-note we can create a presence of information. That way, it is always there ready for us (to update, to create, to notify). I think that the idea of information radiator with simple tools is fascinating. It is like using something that people have used for years and creatively reinvent it. \n

I think that the Lava Lamp Project Automation is an awesome idea. It puts another dimension into the communication for the team. I would love to be able to see the lamps and hear the "clap" sound of the relay switch. I think this is something that makes the team feel special. Something that the team can feel proud of as they work toward a bug-little product. Definitely a fascinating aspiration as the work comprise of integration multiple products both hardware and software. \n\nNow if only I can get one of these kits at ThinkGeek.com instead of building it myself.\n

The Battle of the Somme proved to be a costly lesson for the British Army as they found many of their rigid practices no longer applicable. There were conflicting ideas between Haig and Rawlinson which were, later on, compromised. This compromise creates a bad combination of tactic: uniform attack waves trying to cover a long distance of no-man land. \nAfter the planning stage, during the attacks, the British knew of several big gaps in the German defense. Yet they do not carry out a surprise attack and instead chose to stick to their plan. The end result was much more costly the capture of those gaps at a later time ( e.g. Ovillers and Longueval gap, Mametz Wood gap).\n\nOverall, the Battle of The Somme is a clear evidence that planning should be continuous and sticking to a plan will have detrimental effect on the outcome. However, I also believe the general Haig and Rawlinson has done their best according to their knowledge and estimation. The lack of sufficient and on-time communication seems to be the delivering blow to this dramatic and life-costing battle. \n

It is with little doubt that the Sydney Opera House is an achitectural masterpiece of Utzon. This architecture is in fact, so ahead of its time that even its creator cannot comprehend many different technical difficulties. This difficulty leads to a waterfall approach with a small twist. \n\nThe construction was a waterfall process because there are clear stages as the time progress. There is the requirement step with Utzon's design winning the competition. Then immediately followed are the building step with different stages for the building exterior and interior. However, due to technical difficulties and the uncooperation [noncooperation] from the government, the building step was started even before Utzon has figured how his design can be implemented. This is similar to being rushed by the customer, the engineer has to skip the analysis and design step and start implementation right away. This is the reason behind the huge cost overrun of the project. \n\nI found it very interesting that Ove Arup & Partners 's modus operandi is collaborating creatively with architects has established the company as one of the world's leading engineering firms. It was the same collaborative thinking with which the 2nd prize winner architects took when they try to finish the tasks of the Opera House after Utzon left. This collaboration and pride in their work is a signature traits of Agile Development. In fact, it is this effort that has saved Utzon's masterpiece and has allowed it to see the sun light from Bennelong Point. \n\nSource: Design Hub - Building a masterpiece: The Sydney Opera House - http://www.dhub.org/articles/741\n

As I read along and learned more about Technical Debt, it hit me harder and harder every single page I visited. I knew that was me seeing myself in the mirror. I looked back and saw numerous occasions where due to a certain (big or small) reason, I would opt for a shorter solution that I knew (in the back of my head) would come back and cost me in the future. Yet I chose the shorter solution. Whether it was a time constraint, a resource constraint, a dependency or bureaucratic problem, I now know that I need to take a harder look at the debt I am about to incur. \n\nAt this very moment I have some problem at my work where my previous decision has come back to haunt me now. I have spent much more time on this specific issue. Much more than if I would have planned better. So much for Technical Debt. No more. \n

Alex Bell's article "Death by UML Fever"gets its idea across with its humorous tone. The article proved to be both entertaining and informative. In fact, I believe that the creative humor factor plays an important part in helping the readers recognize their symptoms. Alex does try his best to document as many symptoms as possible and categories them. While the amount of symptoms might be overkill, its number emphasizes the widespread and easy-to-misuse nature of UML. I greatly enjoy Alex's article due mostly to its creativity and cleverness. This article, however, did not provide the cure to these UML diseases in details. Alex did explain the recovery step in a separate article "UML Fever: Diagnosis and Recovery", however. Overall I like Alex's article not only because it is informative but also because it breaks free of the boring rigid approach of most other articles relating to this topic.\n\nGrady Booch's article is an attempt to briefly scratch the surface of UML : its history and potential hazards if used incorrectly. He gives the readers some background information of UML then goes on to confirm and emphasize the validity of Alex's article. I found Grady's approach intriguing at best. To me his article main purpose is to bring curiosity to and emphasizes Alex's article. It is safe to assume that people who are interested in his emphasis or Alex's article are those who are familiar with UML. Thus it makes little sense to include half a page of details about the history of UML. On the better side, this history detail might help explaining why UML is not the ultimate solution for every problem.\n\nAlso, as a side note, I have read some comments of other students on these readings and I find some very interesting and would like to know more about their ideas to certain aspects of these articles. Should I send my reply to their comments to this email also? [Venkat's note: Sure, you can discuss anything technical on the mailing list]

Martin Fowler's "Who needs an architect" was a fascinating read. He wards off the common misconception of the definition of an architect, instead suggesting a more concise definition of this term. I found it particular interesting that an architecture can take different parts and forms depending on the problem and the developer team. This is yet another addition to the number of agile aspects in software development. Not only are the code, the plan and the requirement continuously evolving, the architecture of the project can also change. I wondered what is the defining element in Agile Development - the element that would put all these changing aspects into a concrete product. Then I realized that it is always the team members that would navigate and find the perfect combination of these aspects. No wonder Agile Development emphasizes Individual and Interaction.

DN_UMLFEVER\nDN_GETTER_SETTER\nDN_SYDNEY\nDN_WNAA\nDN_IR\nDN_LL

Allen Holub brings us completely new perspective on commonly used accessor methods. His negative attitude towards "getters and setters"\ncaught me by surprise, since I use accessor methods in all of my object oriented code. I thought that I was fully implementing "information hiding", but it was obviously not the case. I have a few issues with his article. Mr. Holub mentions that "the system that heavily or inappropriately uses accessors simply isn't object oriented", and I wonder where the line between appropriate and inappropriate use is. Who is to decide if you have just enough accessors or you have 'one too many', making your code suddenly not object oriented. Also, I did not see from his article clear solution what to use instead of accessors. They are bad, but how to program without them? Only very experienced programmers can stop using accessors. If I have to make a program that uses several classes, I would again use accessors. I think that not using them is something that we should strive to, and as we are programming more and more, one day we will be able to live without 'getters and setters'.

It is similar to whiteboards, but it seems to me that is far superior.\nMy experience with whiteboards is mainly negative, since whiteboards were usually filled with static information, which were not updated for months.\nThe whiteboard we used on my work was erased only once in a year, when new cleaning lady did her job. Later we put the sign 'no borre la pizarra' [don't erase the board] and the content of our whiteboard has not been changed anymore.\nInformation radiator with charts, index cards, post-it notes, whereas editing and updating will be encouraged, has a promise to actually inform. Nice benefit is that someone completely new to the project can get a very good insight into project just from looking at the information radiator.

I don't particularly like the idea of lava lamps as a visual feedback device about project status. The red light is a symbol of failure, and I can imagine the lava device glowing red on my desk 90% of the time.\nThe message it would convey would be 'you unsuccessfully compiled - your build has failed – your project has failed – your project has failed AGAIN - you are a failure…'\nNegative enforcement has already proved unsuccessful in education – even teachers in high schools will not use red pencils anymore In my opinion, the device similar to a sand clock would send much more positive message to software developers/managers. Sand box would be filled as you advance with the project, and after successful build you would start filling it again. You can have more sand clocks, but noooo red color! \n\n[Venkat: Certainly not. The focus is not about failure, but to keep the application in a runnable state at all the time. Start this the first day and drop everything else you do if you don't have a working code and see how it helps. It is like keeping a clean kitchen. If something is not right, you can either fix it right then, or let it infest. The notifications (whatever form) can be used as a great positive feedback cycle. Besides, it has to be taken by the team in the right spirit for the right purpose.]\n\n[DC: At first I also have the same feeling that my lavalamp will always be red and this would be a negative influence on my productivity. However, coming back to the same arguments that was made in class about continuous integration. Whatever work that we are submitting must integrate well with other components. Otherwise, other people's work will be a waste. This comes back as a technical debt and also a factor of respect. I would rather fix this error right now and not to worry about it in the future. If I cannot, maybe I should call for help from my team. ]

What I found interesting is that the chief architect of the Sydney Opera House, Mr. Utzon, changed the design of the House many times.\nReportedly, he "alter[ed] his design as he went along." It seems to me that the process of building the Opera House was like a nightmare, and not something we would like to happen in Software Engineering.\n

Alex E. Bell is making a lot of points in his article "Death by UML Fever". He is very funny and entertaining. My impression is that he probably had some traumatic experience in his childhood, and that is how he developed extreme anxiety against UML. He was right in pointing out same problems related to UML and difficulties that companies have in implementing UML. I think he failed to recognize the difference between cause and effect. It is not UML that is in fault, it is responsibility of companies to make proper use of it. Grady Booch in his article "The Fever is Real" also points out that "a systemically troubled development process" causes problems, and the cause is not UML.\nI think that very effective would be the mixture of these two articles, with problems that Mr. Bell is pointing out (which are existing), and the conclusion by Mr. Booch, that we can and have to have to control UML fever.\n

It is interesting to see how the status of some words has changed.\nThat is what happen with "architect", the word which lost the status of the desirable buzzword. Martin Fowler in his article "Who Needs an Architect", points out the differences between reality and dictionary definition.\nIt would be interesting to track the frequency of other words, and see how their usage has changed in time. For example, today words that are blacklisted are 'managed', 'supervised', 'team player', 'independent worker'. These words lost their meaning because they were greatly overused. It is true that they capture the attention of the reader, but, in my opinion, in absolutely negative way. My favorite word is 'challenging', and it is always funny to see a resume that contains objective that is 'challenging'!\n

DT_GETTER_SETTER\nDT_UMLFEVER

DT2_GETTER_SETTER

I can see where Allen Holub comes from. For large scale programs i can see why getters and setters could run someone up a wall in problems and how accessors violate the encapsulation. The problem is that some professors teach that getters and setters are important in oop design. Accessors expose info about how classes are implemented and given the examples they can also make code harder to maintain.

This article gives good points about object oriented programming. I am a person who uses getter and setter methods a lot, and realize that all this time my code was not efficient. I got a new perspective in writing maintainable code. I agree with the article in that a programmer should avoid getter and setter methods because it will make the code more maintainable over the long run.

I think this article is a wake up call to many software organizations that might be over using the modeling tactics of UML. The diagnosis of the symptom UML FEVER is expose along with a how to recover section. This article is a great help to beginners as well as experts in the subject of software engineering. For a beginner like me in software engineering, this article makes me see where UML stands in the entire process of software development. This will help me to not overuse modeling techniques, UML, during my software development process.\n\nFever is Real: This article gives off the impression that UML can be powerful if used appropriately. It says that some organizations have thrived with UML and some have not. And he makes a point that UML is not the problem but that the problem lies in the organization’s software development practices. I agree with him and think he has a better point than Alex Bells, UML FEVER article.

AO_GETTER_SETTER\nBO_GETTER_SETTER\nCG_GETTER_SETTER\nDC_GETTER_SETTER\nDN_GETTER_SETTER\nDT_GETTER_SETTER\nDT2_GETTER_SETTER\nJE_GETTER_SETTER\nJW_GETTER_SETTER\nMF_GETTER_SETTER\nRP_GETTER_SETTER\nTT_GETTER_SETTER\nWB_GETTER_SETTER

HJ_SYDNEY

The Sydney opera house was designed by architect Jørn Utzon who won a competition for the project in 1956. He got many disputes from his unpractical design at that time.\nthe construction began in 1959 spending over 4.7 Us million dollar. it is unrealistic figure.\n\nUtzon has created a style marked by monumental civic buildings and unobtrusive housing projects. He incorporates the balanced discipline of Asplund, the sculptural quality of Alvar Aalto, and the organic structures of Frank Lloyd Wright into his designs. Influenced by architectural tradition, he attempts to create architecture for living that adheres to a strict structural and constructive process. \n\nUtzon always considers site conditions and program requirement before he designs each building. He transcends architecture as art and develops his forms into poetic inventions that possess thoughtful programming, structural integrity and sculptural harmony. These his aspect caused many people’s criticism. From his empirical philosophy and belief. He convinced that the construction is not unrealistic. That is the way we should know how he convey and achieve his sensational idea.\n\nReferences\nDennis Sharp. The Illustrated Encyclopedia of Architects and Architecture. New York: Quatro Publishing, 1991. ISBN 0-8230-2539-X. NA40.I45. p155.\n

HM_UMLFEVER\nHM_SYDNEY

I think that the construction of the Sydney Opera House is much similar to the Iterative and Incremental Development in software Engineering process because they Divide the process into three processes, each process has its own design,planning and implementation.Except the first stage which is similar to Agile software Engineering process because they began the construction before the design was completed and this has led to some problems with the client.

I liked the topic by Grady Booch about "UML Fever".I agree with him that UML fever is real not because UML is bad.UML is a good tool for software design but the fever exists because some organizations make blind Usage of UML (because it is a new tool) without knowing how to make the UML addresses their needs.Some organizations don't understand UML and they use it for purposes other than its main porpose.Not only UML can become a fever, any software tool that is used in a wrong way, or they just use it without knowing its main purpose can become a fever.\n

BO_IR\nDC_IR\nDN_IR\nJE_IR\nTT_IR

JE_UMLFEVER\nJE_GETTER_SETTER\nJE_TD\nJE_IR\nJE_LL

The article "Why getter and setter methods are evil" by Allen Holub pretty much sums up Intro to COSC part two. Many of the points Allen made refreshed my memory of why we do certain things in OO programming. In a specific sentence, he writes: \n\n"…accessor methods often wind up in the model because you must provide as much access as possible since you can't predict whether or not you'll need it."\n\nAllen points out the only reason programmers allow a good deal of "access" is because they didn't actually plan out the dynamic model, and that they don't fully understand the problem at hand. I have to admit, I am guilty of such actions, and such ignorance. I rarely devise a plan when trying to create programs. When ever I receive a homework assignment, I start writing code without ever knowing exactly what the outcome should be. I figure sooner or later things will come together. By the time I'm finished, I've revised my code several times, I've remedied many flaws, and deleted tons of useless code. \n\nThere were many things in the article that I liked, e.g. Cunningham's CRC cards, but there is one line in particular that I find most useful and poetic. "Don't ask for the information you need to do the work; ask the object that has the information to do the work for you." Basically, instead of having many functions pass information back & forth to each other, create a class that can do as much of the work as possible. [Venkat's note: This\nis also know as TDA "Tell Don't Ask" Principle]. When I first started using classes, I merely thought of them as nothing more than "structs" in C++. It wasn't until a week and a half later, when I was able to do this:\n\nDeck cards;\ncards.shuffle();\n\nthat I realized just how powerful OO programming can be.

What I learned from the usage of an information radiator (a display of any sort that is used to display the progress of different teams in an agile environment) is that feedback and status are not only buzz words in computer science, but they seem to be a key factor that many companies are now following. The mere fact of being on a certain phase in a "radiator" chart for too long would be encouraging enough to make me work harder. And to be honest, after reading the "lava lamp" and "information radiator" articles, I realize that sheer peer pressure seems to be the tool of choice for higher productivity.

After reading a couple of articles on the lava lamp automation, I realized that the reward/punishment strategy is a very clever way of altering common errors made by computer scientists. Although it is supposed to embarrass programmers into becoming better coders, I doubt that's really the case. It's more of an encouragement to not "screw up," rather than an encouragement to do better.

Technical debt I believe is a good metaphor, but also something to be judged based on project requirements. In my 4 years of computer programming I'd say I've acquired dept in about half of my computer science projects and homework. But it my case, it was an okay thing to do because my requirements were to create programs that got the job done. I didn't have a boss constantly reminding me about deadlines. But I do agree that technical debt is a bad thing to acquire when it involves your career. It's much better to do things right the first time, even if it requires some extra work, than to have to waste even more time in the future, with what could have been the simplest of effort.

Alex Bell identifies everything that I hate about UML, and then more. I honestly only envisioned 3 or 4 drawbacks to using UML, but Bell identifies 22 different so called "fevers." I actually liked the illness analogies he uses. I even found the inclusion of the New England Journal of Medicine in the article to be very funny. Most of the fevers I found to be quite far fetched, which is why I'm giving the article a thumbs down for exaggeration (at least I hope I'm wrong about the exaggeration part). I just don't buy the notion that many computer scientists are that stupid. There were only a couple of "fevers" that I agreed with. The Utopia fever (forgetting that complex software has been built without UML) and the Gnat's eyebrow fever (extremely detailed UML diagrams) are by far the worst of these so called "UML fevers." \n\n"The Fever is Real" by Grady Booch was by far a much better read than Alex Bell's "Death by UML Fever." What I liked best about this article is that Booch was clear, and got straight to the point. He made sure he pointed out that UML fever is indeed an ailment, but that it is not the fault of UML itself. Rather, it is through bad software engineering practices. I think Bell's article would've been as good as Booch's article, if only Bell was as concise as Booch. I really like the brief history of how and why UML came to be. I think Booch was much more positive about UML than Bell was, but he still realizes that it can become a waste of time and recourses. He made references to Bell's UML Fever article, and he did it without wasting time writing long analogies.

JH_UMLFEVER

UML seems too large and too complex, considering its purpose. It is merely meant to act as a universal way to diagram and describe methods in an easily readable way, and yet can often fail because there is so much room for misuse and mistakes. Whether its because the developer went into too much detail within their diagrams, or the incorrect focus on what to diagram was used, or any of the mistakes mentioned in the "Death by UML Fever" article, it is just too easy to hinder progress rather than help it. \n\nWhat I don't understand is how UML became so adopted and widely popular that some would blindly claim that it solves all problems in development. Documentation is hardly the major problem encountered in the software developmental process. Granted, proper, easy-to-read documentation of code and diagramming the complex structures of your program's object classes can help give a clearer picture of things, but that is as far as the help will go.

JW_UMLFEVER\nJW_GETTER_SETTER\nJW_WNAA\nJW_TD

While I agree with the premise that using a public get/set to merely hide an integer is not optimal code, I do not agree that Getters and Setters are "Evil". After all, if you do have a public get/set that wrap an internal variable, literally the only thing you are doing is adding extra steps for a compiler and over time you'll have performance degradation. But is having the following evil? (written in C# ... a somewhat crude caching):\nprivate DeductionContainer _MonthlyTaxDeduction = null; public DeductionContainer MonthlyTaxDeduction {\n get\n {\n if (_MonthlyTaxDeduction == null)\n _MonthlyTaxDeduction = _CalculateDeductions();\n return _MonthlyTaxDeduction;\n }\n}\nprotected virtual DeductionContainer _CalculateDeductions() { /// Code that takes a while to run, so we only run once }\n\nI propose that is is not evil simply because it is a Getter. But, it does have some unique attributes to the get/set of an integer, namely\n1) It returns an object that we can extend at a future point and 2) it does not set.

the question is, if you just program to the "good enough" solution, does that just build technical debt? [Venkat: What you mean may be is "hey it works!" kind of a solution.]

"Death By UML Fever"\nWritten to get attention, the main point is that using UML alone does not guarantee success. To date, if pressed, I would describe UML as a good tool for Software Design, but not all that useful for Software Development. It also seems hard to get started using UML if a product already exists and you're in maintenance mode or subsequent release versions, which in my experience is the majority of work for professional developers. The article was sensational, but has a good base argument: You can't just say you're using UML and expect success.\n\n"UML Fever is True"\nGrady Booch's short article agrees that UML does not solve problems on its own, but is also proud of the successes that some organizations have achieved with UML. He does make a statement that if an organization is "using" UML but is not having success that it is probably indicative of "a systemically troubled development process." This is probably true -- if you are attempting to adopt a process and failing, it's probably due to the organization only paying lip service to the adoption. Where managers say they want UML, and the architects and developers agree, and create the pretty documents, but create code without referring to, or updating, the documents.

The lightbulb moment of the Who needs an Architect was the statement that "software is not limited by physics." This is one of those ideas that doesn't get enough attention and is very profound. Usually, management makes the analogy that changing your design is the same as asking your home builder to add on an extra room: there's the foundation work, the extra materials, the timing problems, etc etc etc...\n\nBut for software? there's no reason the change should cost anything less than the same as close to the time to create originally.\n\nI think this is great; there are numberous times in development where I've seen that if you postpone decisions or postpone the hard work, it's extremely harder to fix than if you had just fixed it right in the first place.

BO_LL\nDC_LL\nDN_LL\nJE_LL\nYY_LL

MF_UMLFEVER\nMF_GETTER_SETTER\nMF_SYDNEY\nMF_TD

Although I have little knowledge about Java, as far as I can tell, this article is trying to tell that encapsulation is important to OO design, since objects with implementation detail kept private make the program more maintainable. In that way, neither changing the implementation of object nor the external environment will bring too much trouble. Rather than a procedural decomposition, software should be decomposed to several independent yet interactive parts. I really don’t know much about programming, but as I see it, it is just like functions in programs. By defining a function outside main, not only the codes are made more readable and maintainable, those functions have also become transferable.

Greetings, I looked it up on Wikipedia and googled an article about the Opera House. It is analogous to SE development and I think the model here is somewhere between waterfall and spiral. The construction of the Opera House as a whole proves that the only constant is change - the government changed its mind (what most users do) and Utzon himself changed his mind (the original design was not well-conceived)- which inevitably led to schedule and cost over-runs. Also rushing into implementation stage of the whole project (according to the government, it was because of the pressures from public) which later on led to significant integration problems, was also responsible - although it looked like taking advantages of spiral model, it actually emphasized its disadvantage: the cycle and the scale was too large that making changes became extremely expensive. \n \nThere was also a problem of communication between Utzon and the clients (local government) - the clients wanted to see some actual demonstrations yet Utzon was reluctant to do that - which led to considerable tensions. Eventually those tensions escalated and led to Utzon's resignation. However, I think he was, more likely, a victim to a politically low balled construction budget. This reminds me of the case when "there's no one to blame, blame the government", only this time the government found a patsy. \n \nSince it managed to succeed in the end, I can only say that Sydney Opera House is a costly masterpiece, instead of a fiasco.

I've read about this interesting term. It is sometimes useful when adopted properly. E.g., when there is a conference in one month and you want to display the demo of your software, I think it is ok to take on adequent "technical debt" - considering the best situation, no tests, etc. However, you would have to carefully weigh between the opportunity it might bring and the unfavorable consequence it might have. If one is unable to do that (either he is not confident with the outcome, or he has a practical solution to develop before deadline), the suggestion is not doing it because the interest rate of this debt is unknown.

Death by UML Fever: This article is obviously more entertaining. I bet some of my classmates are diagnosing themselves according to the symptoms yet I am pretty lucky to be ignorant on this issue and thus immune to this fever, or I might be categorized as one of the victim types already. The bottom line is, despite of this long and thoughtful analysis, whatever you use, use it wisely. By the way I also enjoyed those aphorisms.\n\nThe Fever is Real: It talks about the history of UML, along with its initial intent, summarizes some abuse and overemphasis of UML, and substantiates the ideas in “Death by UML Fever”. No other comments, period.

Topics:\n[[UML Fever]]\n[[Getter_Setters_Evil?]]\n[[Sydney_Opera_House]]\nWhoNeedsAnArchitect\nTechnicalDebt\nInformationRadiator\nLavaLamp\nBattleOfSomme\nSoftwareEntropy\n\nOpinions of:\n[[AO]]\n[[BO]]\n[[BT]]\n[[CG]]\n[[DC]]\n[[DN]]\n[[DT]]\n[[DT2]]\n[[GS]]\n[[HJ]]\n[[HM]]\n[[JE]]\n[[JH]]\n[[JW]]\n[[MF]]\n[[RP]]\n[[TT]]\n[[WB]]\n[[YY]]

RP_UMLFEVER\nRP_GETTER_SETTER

i found this article very interesting. the crc index card process is a very original way to force people to stop thinking procedurally which is a problem that i often have. His ideas for keeping unnecessary interaction between objects and outside of them is also a very thought-provoking concept although it means i will need to design my programs differently from my current approach. I do like the idea of using higher abstractions for return types to minimize implementation changes though.

I found this article to be a template that could be used to describe human tendencies as opposed to describing just UML. Replace the word UML in this article with another process or system and you will still have a valid article. People find something that they like and often have a hard time not getting too wrapped up in their fondness of their new way of doing something that they become blinded by other, newer ways. I know quite a few people that will only buy a certain make of car because they have had a good experience with that maker. That doesn't mean that the maker will be making the same standard of vehicle 5 years from now or that other makers won't improve their quality. This won't matter to these individuals though because they have already been sold on the product forever.

Your opinions on various topics.

Your Comments!

BO_ENTROPY\nDC_ENTROPY

BO_SYDNEY\nBT_SYDNEY\nDC_SYDNEY\nDN_SYDNEY\nHJ_SYDNEY\nHM_SYDNEY\nMF_SYDNEY\nYY_SYDNEY

TT_GETTER_SETTER\nTT_TD\nTT_IR

One thing the author brought up about how to get rid of setters and getters is to design use cases. I'm currently doing some RnD stuff on CAB (CompositeUI Application Block - from Microsoft), which I think would help with getting rid of getters setters. CAB has the concept of Work Item, which is like a use case. The way the project is set up and designed is pretty interesting. They have the concept of EventBroker that lets parts communicate with each other without knowing who the other is. One publishes the event and the other subscribes to it. \n \nAnyways, if anyone is interested, the following link has more information about CAB, hands on labs, etc.\nhttp://msdn2.microsoft.com/en-us/library/aa480450.aspx.

Technical Debt is very interesting term. In a fast pace environment, most programmers would "make it work" and forget to "make it right". They either don't have time or think that "making it right" could wait until the whole project is done. However, the problem is when you get your project done, there's always another project around the corner waiting. Hence, you won't have the time or chance to go back and make it right. Some programmers are not overly worried about the technical debt because the program works and they would not have to bother with it until someone wants to make a change, an upgrade or add a new feature. At that point, that programmer is probably on another project and the badly done project would be given to someone else or some other team to handle. Hence, the one that has to pay the debt is not the same as the one who created the debt.

Information radiator is necessary but sometimes if it's not well maintained or organized, it could waste a lot of time. Also, a good information radiator does not help if no one does anything about it. If the information about bugs is posted but no one would take the time to fix it, bugs would just keep piling up and it will get to a point where no one would even look at the information radiator. From where I work, they have a excel worksheet of stuff they need to fix or add, the list kept growing for a while but no one ever looked at it. Some of the stuff were already done but no one took it out of the list. Right now they're trying to tackle it but with 200ish things, that requires some courage. Sad thing is, most of the items on the list could have been done within 5-10 minutes.

BO_TD\nDC_TD\nJE_TD\nJW_TD\nMF_TD\nTT_TD\nYY_TD

[[JH]]

AO_UMLFEVER\nBO_UMLFEVER\nCG_UMLFEVER\nDC_UMLFEVER\nDN_UMLFEVER\nDT_UMLFEVER\nHM_UMLFEVER\nJE_UMLFEVER\nJH_UMLFEVER\nJW_UMLFEVER\nMF_UMLFEVER\nRP_UMLFEVER\nWB_UMLFEVER

WB_UMLFEVER\nWB_GETTER_SETTER

I found this article, especially the way it was written, thoroughly amusing. It was almost written as if it were being published in a medical journal. I really believe that this article is important to listen to in terms of learning appropriate use of UML. The many different "strains" of UML "fever" are basically warning signs that UML is being used inappropriately. This something to watch out for because I believe the consequences he describes are all too real and very serious even if the author's manner in describing these situations isn't. I know that I will keep myself on alert while learning and beginning to use UML, specifically for these cases that the author has outlined. \n\nFever Is Real: This was a thoughtful and tasteful article designed to express an opinion of value. Namely, that UML is and can be misused. And just by using UML, it doesn't mean that you are able to excuse yourself from the software development process. The author did a great job in stating that UML itself is not the problem, but that the misuse is a symptom of something else wrong in the development process.

I very much enjoyed this article. It really makes me wonder about earlier OO programming classes where our standard way of creating classes is with accessors. I would also like to discuss whether you have ever used the CRC card approach, even if it was with UML, and if that was useful to you from a practical standpoint. This fills in a few holes in logic I had when learning accessors. At the time, they didn't seem to follow OO programming. They never really made sense to me, as far as protecting implementation.

BO_WNAA\nDC_WNAA\nDN_WNAA\nJW_WNAA

YY_SIDNEY\nYY_TD\nYY_LL

While reading articles on lava lamps, I found interesting relationship between agile development and Panopticon. (I am not sure whether any other Agile Development experts already pointed out this\nrelationship.) Panopticon is a type of prison designed by Jeremy Bentham, an English utilitarian philosopher in 18th century.\nLiterally, it means all-seeing; a warden observes every prisoners without revealing his/her position while prisoners are not able to tell whether they are observed or not. Bentham insisted that Panopticon is "a new mode of obtaining power of mind over mind, in a quantity hitherto without example." And he argued that it is the most economic and functional penal system.\n\nI definitely agree that programmers are not prisoners and project managers are not wardens. Still, Panopticon and Agile Development have many things in common. Prisoners in Panopticon always know that they are under surveillance by an invisible warden. As they are accustomed this emotional blackmail, the prisoners are trying to keep away from wrongdoings -- they are eventually reformed. In a similar way, we can illuminate a programmer, who could not even hide in his/her own cubicle ignoring red lights in a lava lamp!\n\n[DC: Absolutely great metaphor and knowledge. On the side note, I have actually seen myself as prisoners to several projects at certain point of time.]

Compared other branches of engineering such as civil engineering, software engineering is really nascent field and has many interesting characteristics which differ from those of 'old' ones. Unlike other construction projects, however, the Sydney Opera House bears several striking similarity to modern software projects even though the construction commenced 50 years ago.\n\nWhen Aussie chose a Danish architect Jorn Utzon's construction plan, he protested that he had not yet completed the design. After the construction begins, the state government changed the building's requirements to allow another theater in the Opera House. The original design was badly conceived that they have to spend four years of research to improve the design structure. Due to these problems, the architect was blamed for delays and cost overrun. The new state government withheld to support the construction, which forced the main architect to resign. A new architect team took over and overhauled the proposed function of the building. After these painful processes, the Opera House officially opened at 1973 after 15 years had passed by.\n\nWe could witness these situations more in software development rather than civil engineering. People begin the project even though they still do not know exactly what they are supposed to do. The client changes the proposed functions at whim. The original architect has gone away and another team has to take over and overhaul the entire system. The construction plan survived this ordeal only because this project is huge enough to draw public attention. If it was a software project where all we need to dispose of the wreckage is throwing out the code, it would not survive.\n

The author tries to argue the importance of cleaner design, but this article enlightens me in the opposite way. I had some kind of enthusiasm for simple and elegant code, to the point of obsession.\nSometimes I spend too many hours refining my codes, even though I have many other things to do. Writing quick-and-dirty codes may be sensible in some cases, just like when you pay in credit card rather than cash!