What is Quality Software?

Like any discussion of quality, one must first recognize that quality is never a single attribute but a collection of attributes and their relative presence in the item of interest. When we speak of a car that we believe is of high quality, we generally do not mean one where it has a beautiful interior and exterior with flawless fit and finish but suffers from poor acceleration and breakdowns. Yet a small, inexpensive car may have relatively poor performance but a superb dependability record and prosaic but serviceable interior amenities can be seen as a car of quality, although usually stated a good value. What the first example lacks is a good balancing of the various attributes in the vehicle while the second offers good tradeoffs that allow its purpose for use to more nearly fit our needs. So quality is not a single attribute but some collection of attributes that reflect the decisions a designer made when during the design process.

Software is no different. Microsoft has properly taken heat for creating operating systems that seem to regularly crash causing confusion and pain for the consumers who must use them while simultaneously loading them with features that only some minority of the consumers want or need. The driver behind the feature bloat is the marketing engine which is interested in growing market share and selling new products to replace the older while the cause of the software errors is a rush to market and a corporate culture that does not value engineering excellence over profits. What results is a product that is shaped by the forces at work in the design and build. It is a combination of various attributes including price, dependability, functionality and performance in some relative levels. At least at the Software Engineering Institute at CMU, those attributes of software systems are called qualities.

There are different categories of qualities and their treatment varies. For example, the one quality that has historically gotten most of the attention has been functionality. Since this is vital and the very essence of correct functioning, that is no surprise. This owes to the fact that in the decomposition from need to solution a software engineer must eventually express the solution in for the formalism of a mathematical function since that is what a machine will execute. However cost is a much more difficult attribute to tie determine since it is bound up in business processes, management, markets and economics. There are a group of qualities that can be grouped together under the heading of qualities in use. Performance, reliability, usability, security, and availability are qualities in use since they are directly observed by the user. There are another group of qualities that are not seen by the user but are important to the owner of the software system. They include buildability, maintainability, testability and modifiability to name just a few.

What we have just started exploring is a taxonomy of software system qualities. (from wikipedia, "Taxonomy (from Ancient Greek: τάξις taxis "arrangement" and Ancient Greek: νομία nomia "method"^[1]) is the practice and scienceof classification. Taxonomy uses taxonomic units, known as taxa (singular taxon). In addition, the word is also used as a count noun: a taxonomy, or taxonomic scheme, is a particular classification ("the taxonomy of ..."), arranged in a hierarchical structure. Typically this is organized by supertype-subtype relationships, also called generalization-specialization relationships, or less formally, parent-child relationships. In such an inheritance relationship, the subtype by definition has the same properties, behaviors, and constraints as the supertype plus one or more additional properties, behaviors, or constraints. For example: car is a subtype ofvehicle, so any car is also a vehicle, but not every vehicle is a car. Therefore a type needs to satisfy more constraints to be a car than to be a vehicle.")

It is always tempting to develop a complete taxonomy. However we will see later that while interesting from an academic perspective, it is unnecessary for the practice of requirements gathering.

Traditionally all of these qualities, except functionality, were grouped under the heading of non-functional requirements. While functional requirements have been gathered with some success in the past, non-functional requirements were largely ignored. We shall see that this has been a stumbling block to achieving Quality software since many design decisions are predicated more on the basis of the non-functional requirements than they are on functional requirements.

So the Quality (big Q) of a software system is the fitness for purpose of the system as measured by the gap between the various qualities (little q, or attributes) of the system and the client's needs.

An Outline for a Course on Software Architecture

This is taken from the Shaw and Garlan book, Software Architectures: Perspectives on an Emerging Discipline

Introduction (3 lectures)

• Orientation. What is the architectural level of software design, and how does it differ from intra-module programming?
• What Is a Software Architecture? Constructing systems from modules. Some familiar kinds of architectures. Some common kinds of modules.
• Classical Module Interconnection Languages. (from procedural to object-oriented)

Procedure Call (3 lectures)

• Objects. Information hiding, abstract data types, and objects. Organizing systems by encapsulating design decisions, or "keeping secrets."
• Modular Decomposition Issues. Keyword In Context, KWIC, problem introduction. Considering how to weigh the benefits of various decompositions for a system.
• Formal Models. Basic notation of the Z Specification Language. The schema calculus.

Dataflow (4 lectures)

• Batch Sequential and Pipeline Systems. Systems where data flow linearly through a sequence of discrete processing steps. Contrasts executing to completion at each step with continuous flow through a system and incremental processing
• Tektronix Case Study. Specific example of a pipeline system used as part of a larger application. Example of formally modeling components and connectors.
• Implementation Using Unix Pipes. The Unix paradigm connects independent processes by dataflow. The organization of the processes, and the style and tools for connection are substantially different.
• Formal Models for Dataflow. Formal model of pipes and filters. Use of formalism to explain what a software architecture is and to analyze its properties.

Repositories (3 lectures)

• Databases and Client-Server Systems. Databases and client-server systems use a centralized, persistent store of information. This contrasts with dataflow architectures.
• Blackboard Systems. Sharing complex knowledge about a problem; making progress when you can't tell in advance what order to impose on the subproblems.
• Architectural Evolution and Industry Issues. Historically, the requirements of users coupled with advancing technology have produced an architecture evolution from batch sequential systems through pipelines to repositories. Consideration of how industry deals with choices.

Events (2 lectures0

• Models of Event Systems. Distinguishing implicit invocation from client-server communication and point-to-point message passing. Using formal models to define a general architecture which can be further specified as needed.
• Implementations of Event Systems. Examines and compares two implementations which enable components to communicate via events. Presents alternatives for the underlying implementation of implicit invocation mechanisms.

Processes (2 lectures)

• Communicating process architectures. Topologies and techniques for orchestrating multiple, independent but communicating processes to collectively solve a problem.
• Formal Models for Processes. Introduction to CSP for modeling sequences of execution. Comparison between CSP and Z schema calculus.

Other Architectures (1 lecture)

• Interpreters, Process Control and Heterogeneity. Two examples of architectures frequently found in practice. Examples of how "pure"architectures often appear combined in implemented systems.

Design (9 lectures)

• Design Assistance. The selection of a software architecture should depend on the requirements of the application. This example of a system shows how to make the structural design of a user interface explicitly dependent on the functional requirements.
• Classification of Architectural Constructs. Presentation of a partial taxonomy for architectural styles, components and connectors.
• Interface Matching.
• Aesop
• UniCon
• Heterogeneity and Mismatched Parts.
• Information Architectures for Cyberspace.
  
• Architectural Languages
• Patterns and Pattern Languages. Identifying patterns in the use and combination of architectural styles and components, as well as recording and communicating the patterns in useful ways.

*************************

One section that must be added is the documentation of non-functional requirements. Without an agreed upon way to capture the requirements, it is difficult to explain what is meant by quality software or the power these requirements can exert over the shape of the system.

What's Wrong with Being a Progressive?

When I was growing up oh so long ago, we have liberals and conservatives. The liberals wanted to see a fairer world and the conservatives were primarily a party that favored the rich and those who wanted to be rich, that is, pro-business. But both sides were civil, there were interesting debates on the issues facing our society and I always thought most people had a relatively open mind. Back then no one would shun you because you were a self-professed progressive. Those days are long gone. But what is wrong with being a progressive now?

Conservative has taken a much more hard-edged meaning over what I remember. I never met a conservative growing up who didn't believe in a better and different future from what we knew. We were putting men on the moon, there were new inventions every week, everyone seemed to want to be an American and join our parade to the future. Now conservatives not only want to stop all change forward, they want to actually go backwards on many issues. I am really shocked at the amount of money and effort groups are putting into resisting things like the Obama healthcare plan, gay marriage and mosques. Their attitude now seems to be that majority rules until we are the majority and then we'll work to reverse every change the other side made when they had the majority. This is not progress, this is even worse than stagnation. This is just treading water until we run out of energy to stay afloat.

How did we get here? I do not doubt the sincerity of the positions held by the tea party folks. They truly believe in a small government and self-sufficiency. But it is as if they read Ayn Rand and never got beyond fiction. While she makes a compelling plea for a libertarian form of government, she never had an ailing, widowed grandmother, or a worker who lost a limb in an industrial accident as a main character. No, they are not worthy of her praise since they cannot aspire to the Nietzsche superman. You don't need to have much imagination to understand that such pure ideology just doesn't work in the real world. What you create in embracing this idealism is a return to the jungle and the worst human treatment found in the gilded era. This is not something that I aspire to and most of the people who espouse this ideal would not want it either if they really had a chance to experience it.

I think that the main driver for this kind of reactionary position is a response to the extraordinary changes the US has experienced in the past 40 years. We went from envisioning a future so different from the present that would bring prosperity and fulfillment to everyone to fearing that our children will have shorter, less healthy lives than we did, a belief that our stagnating economy will not create the jobs needed to achieve full employment, and social changes that are at direct odds with the strict judeo-christian laws inculcated into society during the post war boom. In looking for the cause, people do not look into the mirror, they look at what has changed and blame that for their deteriorating status.

Chicago was a predominantly white city before WWII. The 1950s brought a flood of southern blacks to the city all looking for a better life in the north. What the white population saw was this black wave over the city and they were not ready to embrace integration. Even the rumor of a sale of a home to a new black owner would cause home prices to tumble as everyone scrambled to sell their house before prices fell. The speed with which this would happen was staggering. Entire neighborhoods would be converted from exclusively white to exclusively black in the span of a couple months. The fear was palpable. Of course this type of extreme reaction could not be sustained and eventually market forces worked their magic and integration, painful as it was for many, eventually began. There was prosperity for all and we all went forward together.

But things began to change under Reagan. While there is always a good argument that government can do harm as well as good, and in some cases do more harm than good, but the reaction to all of the new government regulation of the 70s began to be challenged, if not rolled back. The first to go were many of the limits on financial institutions. This release a great deal of good as many of the Glass-Stegal rules were for a different time and no longer applied to a world-integrated, almost internet financial world. Lowering tax rates became a holy quest and the right still worships at that altar even though most of them have no understanding of the dynamics that made some of those changes necessary or reasonable. It was good then, it is good now and it will be good in the future. Things became watered down to sound bites for the congregation that worshiped at the church of Reagan.

Along with all the other changes in the world, the war-ravaged nations of Europe entered the world markets in the late 70s. Bankers would queue up to lend them money and at first everyone had a good time. Americans saw a flood of new products enter their markets; quality cars, cheaper clothing, innovative appliances. But the downside of all this was to expose the weak underbelly of american manufacturing which had gone soft in the easy days of selling to those war-ravaged countries who had no one else to turn to for heavy manufacturing and capital investment. Instead of investing the profits from those halcyon days in the 60s into innovative (progressive) techniques and more efficient processes, the money went to management salaries, worker salaries and shareholder dividends. Then when faced with stiff competition from the new factories and able workforces around the world, american business could not always compete. (yes, there were unfair trade practices but on the whole I don't believe this changed the outcome). Now instead of enjoying the better value of the new appliances and cars, they found the less expensive clothing and other values of the imported good from China helpful for being able to maintain their lifestyle in the face of a stalled american economic engine.

No one really saw this erosion of the american supremacy as everyone was fixated with the internet and all the other get-rich-quick schemes that seemed to flow endlessly out of New York. With the controls off the markets, they were free to soar to unbelievable highs but now were also go into free fall with staggering losses of wealth that hadn't been seen in a generation or more. It was like cowboy economics compared to the church bingo of the past.

Together with the sexual revolution and women's lib, the right decided that it was all just too much to bear. The problem is all caused because Washington just gets in the way of business and if they just kill that beast everything will be great. So now every change of the past several generations is being questioned and an earlier time that never existed is being held up as some sort of paragon of the "America" that can again be the beacon to the world. The concept that American does not mean financial success, necessarily, but freedom, fairness, and equality don't seem to be enough anymore. Now they don't seem happy unless they kill all the progressives and by that I mean anyone that doesn't fit into their vision of what that fictional past looks like in their mind. I just hope there is someone there that looks a little like me and I fear for us all.

Software Architecture Design and Analysis:SEI's view

I have registered for SEI's Software Architecture Design and Analysis seminar Aug 10,11 in Pittsburgh. I need to refresh myself on their outline so I might as well bring you along for the ride.

Bass et al take up the issue of design in Chapter 7 of their book Software Architecture in Practice, 2nd ed. The chapter is written by Felix Bachmann. In his Evolutionary Delivery Life Cycle, a Preliminary Requirements Analysis results in a small handful of "architectural drivers, ... the highest priority business goals." (p155). Not all of the business goals may have an impact on the structure of the software system however so only those that will have an impact on the architecture are chosen.

One question that comes up in class that is difficult to answer is how to square the interative methodology of the Evolutionary Delivery Life Cycle (and Agile methods in general) with the waterfall approach that is described elsewhere. In short, I cannot except to say that at some point you need to move forward. Hopefully you won't make too many mistakes. But it is clear that some of the earliest architectural decisions constrain those that follow. Once made, they are difficult to revisit without risking a great deal of prior work. My answer has been that it requires judgment and experience to know. Ironically these are the two qualities of the team members that management seems to ignore when they advocate adoption of Agile methods.

The selection of the architectural drivers sets the stage for the beginning of the Attribute Driven Design methodology(ADD). One good aspect of ADD is that it puts the focus on the quality (non-functional) attributes desired of the system and not the functionality. I think this is key and I don't find a satisfying explanation in the text.

At the lowest level there are only functions. Yet what is desired is non-functional. How can this be? Somehow non-functional attributes emerge from a collection of functions. What the ADD does is focus the designer on those non-functional aspects of the system to be delivered and make them reason about how their selection of functional decisions will cause these non-functional attributes to emerge. But I digress from their text...

At the beginning of the design, the designer is faced with the software equivalent of a blank page; a single box with input, and output. Like a surgeon making the first cut, the designer must decompose this single module into two or more with relationships between and among them. The justification for this decomposition must be the furthering of some non-functional attribute.

The book doesn't explicitly say this but after the decomposition the non-functional attribute has either been satisfied by this decomposition or it follows one or more of the newly created modules. So the new modules will inherit a combination of functional and non-functional requirements from this decomposition. The clear implication here is that some combination of functional elements with the correct relations between them create the non-functional attribute. As the decomposition progresses, it eventually reaches a level of decomposition where the designer is no longer concerned that the attribute will not be achieved. One of two things will have happened by that time: either the design no longer pushes non-functional requirements onto decomposed modules leaving purely functional specifications for those modules; or the achievement of the non-functional requirements is self-evident, at least to the designer.

ADD stresses the choice of pattern or tactic to be used to achieve this decomposition. Since these patterns are know to further specific non-functional attributes, this makes sense. I think in my teaching I did not emphasis this quality to functional relationship that is seen in these patterns. From the standpoint of possible research and tool development this is an exciting aspect. While hardly mechanical, once the desired attributes are identified, the system can prompt with possible patterns/tactics that can be tried. The designer can pick the most likely candidate and have the system assist with moving functionality and qualities to the appropriate modules. Some modules will inherit all the functionality or qualities of their parent. But often the functionality or quality will attach to some subset.

Bachmann makes an astute observation on page 158 re the possibility that not all design proceeds strictly top-down. When it is a mature domain with experienced designers, there are probably few surprises that would cause a rethinking of prior decompositions. However this is a high bar and even mature domains when met with novel business requirements can pose challenges. In this case, the decision tree may proceed to a relatively low level (for architecture) before the designer becomes aware of a dead end or an unacceptable trade off. Or perhaps it is unclear whether or which decisions will lead to the achievement of a particular attribute. In those cases prototyping or some other form of contingent design is needed. The design space must be explored so as to ascertain that a particular choice will lead to the needed result.

This chapter helped me answer a question that came up that I did not give a satisfactory answer to: what is the difference/relationship between a tactic and a pattern? Tactic is defined in opposition to strategy. Where strategy is the overall plan which will encompass many operations, a tactic has to do with the execution, the doing. In software this will be the equivalent of implementation. So while architecture deals with the strategic element of the project, the decisions that commit to a course of action are the tactics. I would say that the choice of how to divide a given module, even when that module is the first one attacked, the entire system, that choice is a tactical decision. If it is possible, the subsequent decomposition decisions will be at least roughly known and anticipated. However this definition of tactic doesn't get me where I need be for this explanation.

On page 100 in chapter 5, Bachmann, Klein and Wood define tactic as "a design decision that influences the control of a quality attributes response". This at least gets us into the domain of software design. It also gives me the crack I need for my piton. If the tactic is the decision, that decision will result in some form. The pattern is the form that results. To apply a pattern is to make a tactical decision or to employ a tactic. I can forgive the students for not working their own way through these semantics.

In ADD, a pattern is chosen to enhance the attribute desired. But patterns rarely promote a single attribute and often diminish one while advancing another. Therefore each decision causes an evaluation of the tradeoffs between these attributes. If the designer is lucky, the attributes diminished by the choice are not critical to the success. But if they are, other patterns must be sought to achieve considered. The book offers the example of using an interpreted language to achieve modifiability. While the use of HTML does improve modifiability, it also comes with a performance price.

Software Architecture: Definitions

I'm trying to create a set of notes to use when teaching software architecture. This post is to work out how to define it.

Software architecture depends upon a metaphor with building architecture for its definition. Like a building, a software system is composed of many pieces in relation to each other. The architecture is not visible by looking at the individual pieces but only apparent when looking at the complete structure. Likewise, there are many ways to describe what is going on within programs or even small collections of programs (class, inheritance, is-called-by relationships, etc) but they only capture individual details, not the overall impression that is made by the complete assembly.

When trying to convey this point, the language gets difficult. We speak of architectural styles when we refer to a building as international style, or prarie style, gothic, etc. What we mean when we say style is that the structure embodies a set of attributes that together provide a category for the expressive elements of the structure. For example, to say that something is romanesque style immediately suggests that the windows do not have gothic points but are instead semicircular at the top. When we see this style of window, we can look for the other attributes. If it has all or at least most of the stylistic attributes of that category, we can say it is a member of that style.

But while the expressive elements of building architecture are relatively approachable for a lay person, software architecture is less so. For example, the 3 tiered architecture style is very familiar now. When we say that a system is 3 tiered, we immediately expect to find at least one, and usually many clients that communicate with one or more servers via a shared communications channel with the data for the system kept in a back-end database. The deployment of the client, server and database are the expressive elements that define this style. This is far less obvious than the shape of a window but workable as a way of discussing software systems. The student must first make this leap.

Sadly, things can go off the track very quickly here. The work on patterns of the 80s mirrors the idea of style. But the scale at which patterns can be used spans from the grand-architectural to the program level code style. Which of these patterns are architectural? Is a pattern any different than a style? To the second point, I say no, a style and a pattern are essentially the same thing but the context does make a difference.

When we are discussing architectural style, we are looking at the most apparent features of the assembly. This may be worked out more by trial and error than by any great theory. The attributes that make the style useful become the defining elements of the style. The shape of the romanesque and gothic windows were not mere ornamental choices, they were a direct result of the way the stresses of the structure are worked out and arranged to give the structure solidity. Likewise the 3 tiered architecture evolved as a way of making a more scalable system than the monolithic mainframe architectures of the past. In a 3 tiered arrangement, the hardware could be maximized for the task; a Sun server for the Oracle database, Windows servers providing application logic and an assortment of clients to support the machines used by the end user.

The central point made by the authors regarding patterns is that a pattern is a logical response to a recurring problem with a solution that has been used repeatedly and has known attributes. That is to say, if I apply pattern A to the problem, I can be assured that it will exhibit properties X, Y and Z. But if I were to use pattern B for this same problem, it would exhibit properties W, Y and Z. I would know this because of the amount of analysis that has previously been done using those patterns. If the properties W, X, Y and Z are the most important properties of the complete system that are desired by the client, then it is reasonable to call these architectural patterns or styles.

Another point that is confusing to the students is that this is distinctly different that an architectural view. Architecture is complex enough that it is impossible to describe in a single representation. For this discussion to make sense it is first important to realize that EVERY building and EVERY software system can be said to possess AN architecture; architecture is not something that can only exist if it is designed in. While a wigwam may not strike some as architecture in this context it is a valid as a Frank Lloyd Wright prairie style home. The first is an example of an organic or historic style that is done unselfconsciously, the second is considered more of an art form which requires deliberation and conscious effort on the part of a designer who is not the inhabitant. Even the humble wigwam is difficult to depict on a single diagram and a modern skyscraper absolutely impossible.

Historically building architecture has evolved a standardized series of depictions which collectively can be considered the expression of the architecture. There is a of course the scale model which helps the client get an idea of the overall shape and appearance of the intended structure. But that is insufficient for the many detailed decisions that the architect may need to convey to ensure that the project comes out as envisioned. There are framing plans, electrical plans, HVAC plans, plumbing plans, plot maps and a great deal more. Each of these plans is a particular view of the architecture. It represents an abstraction of the information that stakeholder has in the project. That abstraction is a representation that enables that stakeholder to efficiently participate in the project.

Software projects are no different. To achieve some anticipated future modifications, a software designer may provide a particular class hierarchy that, if followed, will make an anticipated change later easy to do. To achieve performance, there may be a great deal of attention given to the particular hardware that the various software modules may be deployed to or even consideration given to other software that may run, or be prevented from running, on that hardware so as to ensure the hardware availability needed to achieve that performance goal. The ways these design decisions are captured into artifacts to be shared with other members of the project team are each specific views of the architecture. No one by itself completely captures the architecture but collectively they do.

Another point that will inevitably come up in this discussion is the extent to which architecture is high level design. The answer must equivocate because, yes architecture is certainly high-level but no, it may not always remain solely high level. For example, to achieve a particular usability goal, the team may actually need to experiment with completely coded UI designs and run human experiments to see how people react. This may not be a production grade system, most likely a prototype. But to be sure the final design will have the usability specified the UI will be worked out to a relatively low level leaving very few decisions for the implementors. This is generally not what people think of when they talk about high level design.

What is required is for the architect to determine which of the many attributes desired by the client will be the most critical to the project success and in particular which attributes will require careful tradeoff because of confounding.

I think if a student can be led through these points, the definition of software architecture is complete.

What is artificial intelligence? NYT 6feb2011 Richard Powers

This op ed piece was written before Watson's appearance on Jeopardy. While Jeopardy did offer a great challenge to artificial intelligence, I think comedy will up the stakes. When a computer can do what John Steward or Stephen Colbert do with the daily news, I'll really be impressed. Until then I'll be inclined to view it as an exploration into how the human mind assimilate such a large disparate collection of information for efficient retrieval. Intelligence is the adaption to a changing environment. The news changes every day and to remain funny requires skills that I don't think we have any inkling of yet.

When is a tree not just a tree?

When it's a hazard.

I have been in conflict with my neighbor almost since the month we moved in. He's not a nice man. But lately it has mellowed into a form of benign ignorance since we have no reason to talk to each other. There is only one issue which will not go away and that is a large oak tree growing over my bedroom. From any angle, it appears that the tree is on my property but it is actually growing on his side of the fence at a 30 degree angle toward my property. Virtually the entire crown hangs over my property like some kind of pool umbrella.

Now comes the interesting part. Tree law is both well developed and maddeningly vague. There is a near absolute law that allows a neighbor to trim an offending branch at the lot line. Since the trunk of this tree passes over the lot line below the crown it is tempting to argue that I can just cut it down at the lot line and be done with it. There are two problems; first a more recent court decision limiting that right and second the fact that the tree is a protected species.

In the past 20 years there was a precedent set that limits self-help which prevents trimming of a tree that would harm the tree. I saw one site that goes so far as to suggest that even ruining the symmetry of the tree could count as damage. But more reasonably it limits the amount of trimming to 30% and prevents cutting any roots that would cause harm. Since the trunk of this tree would still hang over the property it would do little good in removing the hazard.

The tree is a river oak. That species requires a permit to trim after its trunk reaches 12" in diameter. The county came to take a look and agreed that it could be removed. However only the owner of the tree has the ability to do so.

When confronted with all this, the neighbor replied that the tree hasn't done any damage yet and therefore it is ok. I won't even discuss the speciousness of that position.

So on closer examination the law comes down to two points. Is the tree subject to premature failure? Of course an oak can live for many decades in the right environment. This one clearly cannot due to its angle of growth which places a great deal of stress on the roots and its limited land. As a young tree it has a significant tap root that will give it stability. But as a tree of this species matures the tap root is replaced by horizontal roots which cannot maintain this torque.

If there is no foreseeable damage to be cause by a tree falling, the law is not inclined to coerce action. However when the premature failure of a tree has a clear target it falls into a category known as a hazard tree. Since the trunk and major branches are inches from my roof there can be no doubt that this is a high-value target should this tree fail.

Previously this same neighbor had a group of liquid amber trees, one of which was rubbing his gutter. Whenever there was a light breeze you could hear the gutter pop as the trunk rubbed it. During a storm it broke at that point falling in my yard damaging my gutter and fence. Since he claimed it an act of god he refused to take any responsibility for it despite the fact that he could have and should have know that allowing the tree to repeated rub against his gutter was injurious to the tree. By failing to properly maintain his tree he took on liability for its damage. However the prospect of taking his to court over the damage wasn't worth the trouble.

This prior experience with his makes me wary of ignoring the potential hazard and I am not willing to wait until the tree falls. Where I come from you avoid injury instead of waiting for it to occur and then arguing about it. Perhaps my neighbor comes from someplace outside the galaxy.