The Myth of Emergent Design and the Big Ball of Mud

Posted on June 17, 2013 by Hayim Makabee

eiffel-planSoftware developers following Agile methodologies often ask themselves how to adapt the traditional Design phase to an iterative software lifecycle. The basic question is how much design should be done before starting the implementation.

There seems to be a consensus that it is not possible to do all the design before starting to code, called Big Design Up Front (BDUF), because at the beginning of the project the requirements are usually incomplete or partially defined. Another reason to avoid BDUF is our understanding that even the requirements that were defined are likely to change.

Some people have proposed the idea of Emergent Design:

“With emergent design, a development organization starts delivering functionality and lets the design emerge. Development will take a piece of functionality A and implement it using best practices and proper test coverage and then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what A and B have in common and refactor out the commonality, allowing the design to emerge. This process continues as the organization continually delivers functionality. At the end of an agile release cycle, development is left with the smallest set of the design needed, as opposed to the design that could have been anticipated in advance.”

I personally do not believe in this concept of Emergent Design. I think it may work only when implementing small projects or prototypes. My experience is that the development of large software systems requires a lot of effort to keep the design consistent when successive changes are made. It is a fallacy to imagine that the design will tend to naturally re-organize and re-structure itself in an orderly fashion. The reality is that software tends to break, to become more complex and deteriorate over time.

This divergence from the desired order is called Software Entropy:

“The second law of thermodynamics, in principle, states that a closed system’s disorder cannot be reduced, it can only remain unchanged or increase. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, always increases.”

Lehman has also captured this behavior in two of his Laws of Software Evolution:

  • A computer program that is used will be modified.
  • When a program is modified, its complexity will increase, provided that one does not actively work against this.

A famous article that discusses the complexity of software systems is the Big Ball of Mud. It says:

“No one really goes into any project blindly. The groundwork must be laid, the infrastructure must be decided upon, tools must be selected, and a general direction must be set. A focus on a shared architectural vision and strategy should be established early.

Unbridled, change can undermine structure. Orderly change can enhance it. Change can engender malignant sprawl, or healthy, orderly growth.

The biggest risk associated with Piecemeal Growth is that it will gradually erode the overall structure of the system, and inexorably turn it into a Big Ball of Mud.”

So the question is: How do you design a system to support orderly changes that actually enhance its structure? My answer to this is Adaptable Design Up Front.

Posted in Adaptable Design, Agile, Refactoring, Software Architecture, Software Evolution | Tagged , , , , | 26 Comments

Meta-Decisions: Agreeing on the criteria before discussing the alternatives

Posted on June 4, 2013 by Hayim Makabee

choicesIn a working environment, meetings may consume lots of time. In general, the goal of meetings is to make decisions based on the input provided by several people. There are normally many different ways to solve a problem or address an issue. When choosing among several alternatives, the discussion is normally based on people presenting their personal opinions.

We would like to be as close as possible to a consensus, because we may not be able to claim that one person’s opinion is more important than others. But very often the participants in a meeting try to convince each other that their opinion is the right one, instead of trying to reach an agreement.

In general, the difficulty in reaching an agreement is caused by the fact that different people are forming their opinions using different criteria. Thus, the solution to reduce the time spent in discussions and to make decisions faster is to first agree on the criteria that should be applied when choosing among the several options.

For example, suppose your team is planning how to develop a new product. One person thinks that first of all you should build a prototype. Another person thinks that you should immediately start implementing the final product. A third person believes that you first need to look for existing components that may be used to build the product.

How is it possible that each person has a different opinion? After all, they are all experienced professionals that have developed such products before. The explanation is that each person is using a different criterion to form his opinion:

  • The person proposing a prototype probably wants to collect feedback from real users before he starts developing the product.
  • The person who wants to start the implementation immediately probably is concerned with the time-to-market.
  • The person who wants to reuse existing components probably wants to reduce the total development cost.

So before this team agrees on the right alternative, they must agree on the most important criterion. What is more important? User feedback? Time-to-market? Cost? After agreeing on the right criteria, choosing the right alternative is much easier.

Deciding about the criteria is what I call a Meta-Decision: It’s a decision about how to make a decision. In other words, a Meta-Decision is the choice of the rules that should be applied when making decisions about some subject or issue.

focusImagine making decisions as a dart-throwing game. If people have different criteria for making their decisions, it’s like they are all throwing their darts in different directions, as if they had different targets. In contrast, when people agree on the criteria for making a decision, they are actually agreeing on the target they want to hit.

Meta-Decisions, Trade-Offs and Software Quality Attributes

In the field of Software Engineering, developers generally need to make their decisions analyzing trade-offs.

Trade-Off: “A situation that involves losing one quality or aspect of something in return for gaining another quality or aspect.”

For example, in many situations it is possible to reduce the execution time of a function by increasing the usage of memory. This is called a Space-Time tradeoff. Therefore, when choosing the algorithms and data-structures to implement a system, the developers must make Meta-Decisions: Do we want to minimize CPU time or memory?

Meta-Decisions are also needed when choosing the focus on Software Quality Attributes. Some attributes refer to the quality of the design or the quality of the code itself, such as Maintainability, Extensibility and Reusability. But there are also dynamic attributes that refer to the system execution, such as Scalability, Throughput and Resilience. Clearly, when comparing several design alternatives it is necessary to focus on a subset of all possible quality attributes.

Advantages of Meta-Decisions

As discussed above, Meta-Decisions are useful to make discussions more effective and thus help us avoid wasting time in long meetings. But applying Meta-Decisions has several other benefits.

Awareness: When you choose an option based on a Meta-Decision, you are conscious. You know the reason you are making this decision. You are following a process.

Systematic Thinking: Using Meta-Decisions actually activates different parts of the brain. It requires Logic and Reasoning vs. Intuition and Personal Bias.

Justification: When you apply Meta-Decisions, you can justify your decisions. You can say “We chose option A because we want to optimize X. If we wanted to optimize Y, then we would have chosen option B.”

So next time you are in a meeting and people are not being able to reach an agreement, the best thing to do is to just interrupt the discussion and bring it to the Meta-level. Say: “Before we discuss the options, let’s discuss the criteria we will use to select an option.”

Do you like the idea of Meta-Decisions? Do you already use it? Please share your experience leaving a comment below.

Posted in Efficacy, Software Architecture | Tagged , | 3 Comments

Adaptable Designs for Agile Software Evolution

Posted on May 5, 2013 by Hayim Makabee

bird beaks“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.” – Charles Darwin

Big Design Up Front (BDUF) is considered a very bad practice in Agile software development. BDUF is problematic because it assumes frozen requirements. The Agile approach is that software must be developed iteratively since the requirements will change and the system will evolve. So we need some Design Up Front, but this must be Adaptable design that supports change: ADUF.

Adaptable Design Up Front

We should never work on the design of a specific system. Instead, we should generalize, designing for a family of systems. Applying object-oriented concepts, our design should represent a class of systems, and each version during the system evolution should be an instance of this class. Thus each new version may have modifications and extensions when compared to previous versions, but if it still fits the same generic design, then it is still an instance of the same class.

Adaptable Software Design: A generic software design for a family of systems which does not need to be changed to accommodate new requirements.

The challenge of creating an adaptable design is making it change-resilient. Adaptable designs should evolve and accommodate new requirements through specialization. When designing for a family of systems, there are two main such approaches: The framework approach and the platform approach.

Frameworks

Framework: “A software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software.”

The framework defines the system structure: The main system components and the relationships among them. Each one of these framework components should have an abstract interface, and several possible implementations for these interfaces. If the design is sound, the components implementation may evolve over time, but the relationships among them should be preserved.

Each component in a framework should be designed to be highly cohesive, and the framework itself should be designed so that components are weakly coupled. If the component interfaces are indeed abstract and if the coupling among these components is weak, each type of component in the framework can be seen as a kind of plug-in.

Plug-in: “A plug-in is a software component that adds a specific feature to an existing software application. When an application supports plug-ins, it enables customization.”

If we are able to define such framework with diverse plug-ins, the system evolution occurs through the implementation of new versions of components. Thus, instead of having a new version of the entire system, we may have new versions for each one of the plug-ins. Building the system means simply combining these plug-in versions in an appropriate configuration.

Platforms

Platform: “Technology that enables the creation of products and processes that support present or future development.”

A platform should support the basic services which are required by the system to provide its functionality. When these basic services can be well-defined and implemented independently of the system which will use them, we have reached an ideal environment for adaptability:

  • The platform may evolve independently of the systems that are built on top of it. If the interfaces are kept intact and if the behavior is preserved, the platform developers are free to improve its efficiency and other non-functional attributes.
  • Several systems may be built on top of the same platform, using its services to provide diverse functionalities. These systems may each evolve independently of the others, and independently of the evolution of the platform itself.

Building platforms is a very effective approach for experimentation. If an essential part of the system behavior can be captured as basic services being provided by the platform, then each version of the system may be seen as an experiment and the cost of failure is low. The resources invested in the development of the platform are not lost in the case one of the system versions is not deployed.

Adaptable Software Design in Practice

Question: How do you identify the components in your framework or the services in your platform?

Answer: We want to think generally about a family of systems, and avoid defining requirements for a specific system. To identify the main entities that should compose any system in this family, we should apply domain modeling.

Domain Model: “A domain model is a conceptual model of all the topics related to a specific problem. It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain.”

Question: How do you decouple the components in your framework?

Answer: To reduce coupling, one should look for appropriate Design Patterns. Most of these patterns are related to avoiding the direct links between concrete classes, through the introduction of interfaces and abstract classes.

For example, when instantiating an object, one should avoid creating an instance of some specific concrete class. This can be done using the Factory pattern.

Summary

Software systems must be able to evolve over time. This evolution should be planned and supported trough Adaptable Software Designs. There are two main approaches for creating such designs: Frameworks and Platforms. Both require the identification of domain entities and the usage of abstract interfaces to minimize coupling between components.

What do you think? What is your personal experience with software evolution, changing requirements and adaptable designs? Please share your thoughts in the comments below.

Posted in Adaptable Design, Agile, Design Patterns, Software Architecture, Software Evolution | Tagged , , , , | 37 Comments

Outliers? The Myth of the 10,000 Hours Rule

Posted on April 4, 2013 by Hayim Makabee

neutralFollowing the “Outliers” book by Malcom Gladwell, some people are convinced that if they “just” invest 10,000 hours in something they will become really good at it. I think that this is not always the case. I don’t believe any person is able to invest 10,000 hours in anything he/she decides. I believe that challenging activities require special aptitude. And I think there are situations in which someone may spend lots of time stuck in some place, doing the same mediocre job for years. Like driving in neutral while pressing down the gas…

Question:  Can you just decide to invest 10,000 hours in anything you feel attracted to?

I believe you can only invest a lot of time in some activity if you really enjoy doing it. And I also believe that you can really enjoy an activity only if you got some talent in performing it. In other words, if you don’t have the innate ability to do some activity you will not be able to enjoy it, and thus even if you try you will simply quit much earlier than you expect.

You certainly know people who have tried all kinds of activities and then decided to quit after a relatively short period of time. And you probably also have your own personal experience of trying to do something and then deciding to quit. That may be trying to learn a foreign language, trying to play some musical instrument, trying to exercise more frequently or even trying to write your own blog.

If you had these experiences, you can ask yourself why you decided to quit. Was learning a foreign language more difficult than you expected? Was playing a musical instrument less fun than you thought? Did you enjoy exercising more frequently? Did you feel satisfaction from your blog writing?  If you decided to quit, this probably means that for these particular activities you did not have enough talent to enjoy and persevere.

One case in point is that of College drop-outs. It’s clear that if a person chose some profession is because he/she felt attracted to it, and was ready to invest a lot of time learning it, believing that with the right amount of dedication and effort success was guaranteed. However, statistics show that 33% of the students drop-out of College. Of course some of these students may have personal reasons to drop-out, such as health problems, but for most of them the reality was different from their expectations, and they simply decided to quit.

Question: May you invest 10,000 hours and still see no improvement?

I believe people can get stuck in some position, for example performing the same job for years without any personal progress or improvement in their competencies. Unfortunately, this probably happens more frequently than it should, since after a certain age people may have very limited opportunities to try something new. So they simple continue doing the same mediocre job they did in the past, because this is the only thing they know.

This phenomenon is known as the “Peter Principle”:

“In a hierarchy, members are promoted so long as they work competently. Eventually they are promoted to a position at which they are no longer competent (their ‘level of incompetence’), and there they remain, being unable to earn further promotions.”

The Peter Principle has two corollaries:

“In time, every post tends to be occupied by an employee who is incompetent to carry out its duties.”

“Work is accomplished by those employees who have not yet reached their level of incompetence.”

These people who have reached their levels of incompetence are probably not enjoying their jobs anymore. But they will continue working because they are being paid and they may not have any other alternative. So in this case they may actually spend 10,000 hours doing something, not enjoying it and not improving.

In Summary:

  • Aptitude is required: To invest 10,000 hours doing some activity you must enjoy it, and to enjoy it you need talent.
  • No guarantee of success: If people reach their incompetence level they may spend 10,000 hours doing the same mediocre job, not enjoying it and not improving.

People like to believe that if they work hard enough they can become very good at anything they want. I think that people should first understand what are the few things they are already good at, and then work hard to become even better.

What do you think? Do you agree or do you have different experiences?

Posted in Efficacy | Tagged | 9 Comments

A Social Watching Experience for Yahoo! Connected TV

Posted on March 18, 2013 by Hayim Makabee

Connected TV is one of Yahoo!’s most innovative products. The basic idea is that your TV set should be as smart as other devices such as your smartphone or your tablet. In other words, the Connected TV is always connected to the Internet and is able to run its own Web-enabled applications. And, of course, the Connected TV also has a store from which you can download these applications.

CTV boxingOne of the most interesting technologies in Yahoo!’s Connected TV is called Broadcast Interactivity (BI). BI allows the automatic identification of the show that is being watched in the TV set. This real-time knowledge about the show being watched creates a context for the enrichment of the user experience. For example, it is possible to supply additional content that complements the TV show, or targeted advertisements that take in consideration the show being watched.

We at Yahoo! Labs Haifa decided to develop an application to investigate the possibilities of BI combined with social networks. Our idea was to help the user to share his TV watching experience, through the automatic location of related content that could be posted in social networks. For example, if the user is watching a movie, he may want to post on his Facebook wall a YouTube link to the trailer of this movie. In a different scenario, the user may want to check the Facebook page for this movie and read what other users have been saying about it.

This application was called the Social Companion, and it was developed in one semester by two bright Technion students, Eitam Amit and Roy Velich, under my supervision together with my colleague Amit Kagian. I must say that Eitam and Roy did an outstanding work, learning in a short time how to develop applications for Connected TV, combining content from multiple sources and proposing several additional features to our initial concept. You can check their project site for more information, and see below a screen shot of the Social Companion application.

CTV social companionWe hope that this project will motivate other young programmers to develop applications for Connected TV, and that in the future it will become a platform as popular as the other smart devices. If you want to learn more about Connected TV or about the Social Companion application, please use the comments below.

Posted in Social Networks, Web Development, Yahoo! | Tagged , , | Leave a comment

On Developer Wisdom and Software Quality Attributes

Posted on February 7, 2013 by Hayim Makabee

EcclesiastesWhat is wisdom? In order to answer this question, we will look into some ancient Jewish texts.

From the Talmud (Tamid 32A), compiled 1500 years ago:

“Who is wise? He who discerns what is about to come to pass.”

In other words, the wise man is the one who sees the consequences of his actions.

From Ecclesiastes (14:1), composed 2300 years ago:

“The wise man, his eyes are in his head; but the fool walks in darkness.”

Rashi, the medieval commentator (France, 1000 years ago), interprets his eyes are in his head to mean: “In beginning of the matter he foresees the outcome.”

From Pirkei Avot (2:10), written 1800 years ago:

“[Rabbi Yochanan] said to them: Go and see which is the best trait for a person to acquire… Said Rabbi Shimon: To see what is born [out of one’s actions]…

He said to them: Go and see which is the worst trait, the one that a person should most distance himself from…. Said Rabbi Shimon: To borrow and not to repay…”

In this case, a person who accumulates a debt which he will not be able to pay is the ultimate example of not being wise enough to foresee the future implications of your actions.

Wisdom and Decision Making

From the sources above, we conclude that the wise person is able to foresee the future consequences of his actions. Of course this ability is useful only if it is applied to the decision making process.

If at the present moment you have several possible courses of action and if you are able to predict the implications of each alternative, then you can choose the option that will produce the more favorable outcome.

chessThe decision making process is very similar to a game of chess. It is a well-known fact that chess masters have the ability to foresee several moves in advance. This vision allows them to build a successful game strategy. In the case a chess master must react to a surprising move from his adversary, he is able to rapidly consider several alternatives, analyzing their likely outcomes, and choosing the best one.

Some artificial intelligence algorithms are also based on this notion of exploring the future consequences of present actions. For example, the Minimax algorithm builds a game tree in which each node represents a move. The algorithm tries to maximize its chances of winning the game, while at the same time it minimizes the chances of its adversary to win the game. This algorithm has been used to implement chess-playing programs, employing heuristics to evaluate non-final game states.

Wisdom in Software Development

But how is this ability to foresee the consequences of our decisions related to software development? From Wikipedia:

“Effective software design requires considering issues that may not become visible until later in the implementation.”

We could also ask: What characterizes high-quality software? Is this the ability to satisfy customer needs? Is quality the correct implementation of the requirements?

The answer is that correctness is just one of several software quality attributes. What about other attributes such as maintainability, extensibility and reusability? All of them have in common the fact that they address future needs:

Maintainability: In the future, the system will need to be maintained, for example to accommodate changes in requirements or to improve its performance. We would like this maintenance to be as easy as possible.

Extensibility: In the future, the system will need to be extended, for example to add new features or to support new functions. We would like these extensions to require minimum effort.

Reusability: In the future, we would like to reuse some modules of our system, for example to create a new product or support a new customer. We would like this reuse to be as simple as possible.

In other words, designing a system to be maintainable, extensible and reusable requires from software developers the capacity to plan for future needs.

But what happens if a team implements a system without taking in consideration these future needs? The answer is that this team is accumulating Technical Debt.

Technical Debt: The consequence of implementing poor design decisions in order to save development time. Like a debt is a value you know you will have to pay, technical debt is code that you know you will have to refactor.

As we have learned above from Pirkei Avot, a person who accumulates a debt which he is not able to pay cannot be considered wise. The same can be said about software developers who accumulate technical debt.

Conclusion

As we have learned from the ancient Jewish sources, wisdom means knowing the future consequences of our actions. Accordingly, developer wisdom means understanding the future implications of our design decisions. A programmer who is only concerned with the correct implementation of the current requirements cannot be considered wise.

What about you? Are you a wise software developer?

Posted in Agile, Efficacy, Jewish Sources, Software Evolution | Tagged , , , | 10 Comments

My first computer, 30 years ago…

Posted on January 27, 2013 by Hayim Makabee

CP 500So we have reached the year 2013, and this reminds me of my first computer, which I got in 1983, or 30 years ago. It was a Brazilian CP-500, compatible with the original TRS-80 model III. It had 64K of RAM, two drives for 5¼ floppy disks and a monochromatic monitor. Each floppy disk could store 180K on each side, and this was enough for saving several programs.

I was 13 when my father bought me this computer. Of course, it was a gift for my Bar-Mitzvah, and I was one of the first boys in my class to have a computer at home. I was very excited, but did not have any software to run on it. So I did what I could: I read the two manuals that came with the computer, and tried all the commands.

The first manual was for the operating system, the TRS-DOS. I learned everything about manipulating files on the disk. This was useful, but not very fun.

The second manual was for the BASIC programming language. I immediately started writing my own tiny programs, copying the examples from the book and making small modifications. This was much more fun, but still very limited.

SinclairThings got more interesting when one of my friends gave me a book with printed listings of source code for games in BASIC. I tried to copy them, typing line after line, but got many errors. I soon understood that these games were written for the Sinclair computer, which was not compatible with mine.

Then I decided to fix these games so they would run on my computer. I remember spending many hours trying the different instructions, especially the ones related to the graphic display, which was completely different in the two computers.

In the end I was able to convert all games and had them running properly on my machine. It was a double win: Now I had games to play with, and now I had learned to program in BASIC. And this was the very start of my career as a software developer.

I was very effective in my early years as a teenage programmer. I was extremely curious and looking for challenges. My first computer was a great source of new things to learn and problems to solve, and I had lots of free time.

Today I’m still curious and looking for challenges, but now of course I do not have the free time I had as a teenager. Thus I’m very happy to be still learning new things and solving interesting problems at work. Currently, Recommender Systems for millions of users instead of small games in BASIC.

I feel lucky for having this passion for programming, which is already 30 years old. What can be better than your hobby becoming your profession? Is there anything nicer than being paid to do what you love?

Posted in Programming | Tagged | 4 Comments

IASA IL meeting with Prof. Rick Kazman

Posted on December 7, 2012 by Hayim Makabee

KazmanThe International Association of Software Architects (IASA) in Israel organized a special event with the participation of Prof. Rick Kazman, who talked about ”The Metropolis Model for Software Development”.

Dr. Rick Kazman is a Professor at the University of Hawaii and a Visiting Scientist at the Software Engineering Institute. His primary research interests are software architecture, design and analysis tools, software visualization, and software engineering economics. He is the author of over 100 papers, and co-author of several books, including “Software Architecture in Practice“, and “Evaluating Software Architectures: Methods and Case Studies“. Kazman was one of the creators of the SAAM (Software Architecture Analysis Method) and the ATAM (Architecture Tradeoff Analysis Method). Dr. Kazman received B.A. and M.Math degrees from the University of Waterloo, a M.A. from York University, and a Ph.D. from Carnegie Mellon University.

The Metropolis Model for Software Development

Abstract

We are in the midst of a radical transformation in how we create our information environment.  This change—the rise of large-scale cooperative efforts, peer production of information—is at the heart of the open-source movement but open source is only one example of how society is restructuring around new models of production and consumption.  This change is affecting  not only our core software platforms, but every domain of information and cultural production.  The networked information environment has dramatically transformed the marketplace, creating new modes and opportunities for how we make and exchange information.  “Crowdsourcing” is now used for creation in the arts, in basic research, and in retail business.  These changes have been society-transforming.  So how can we prepare for, analyze, and manage projects in a crowdsourcing world?  Existing software development models are of little help here.  These older models all contain a “closed world” assumption: projects have dedicated finite resources, management can “manage” these resources, requirements can be known, software is developed, tested, and released in planned increments.   However, these assumptions break in a crowdsourced world.  In this talk we will present principles on which a new system development model must be based.  We call these principles the Metropolis Model.

These are the original slides of Prof. Kazman’s presentation:

Here is the video of the entire talk and the Q&A session:

This event was hosted by LivePerson at Raanana.

The audience was composed of experienced software professionals, who clearly identified with the subject and asked many questions.

To participate in our future meetings, please join the IASA IL group on LinkedIn.

Feel free to share your comments below. Thanks!

Posted in IASA Israel, Software Architecture | Tagged , | Leave a comment

On Information Hiding and Encapsulation

Posted on November 25, 2012 by Hayim Makabee

This month I participated in IBM Haifa’s Programming Languages and Software Engineering (PLSE) Seminar. There I had the opportunity to have lunch with David Parnas, one of the world pioneers in the field of Software Engineering. Parnas is the father of Information Hiding, a term he coined and which became popular through his seminal paper “On the Criteria to Be Used in Decomposing Systems into Modules“, published in 1972.

My personal conversation with Parnas at lunch was mostly about places to visit in Israel, but during the seminar it was great to hear him talking about the challenges of modern software development. He expressed his view that software developers must have a solid education on the principles of software engineering, and focus less on particular technologies which will soon become obsolete. This is my motivation to write this post about Information Hiding and Encapsulation.

In the conclusion of his above-mentioned paper, Parnas writes: “… it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing.”

This idea that modules should not “correspond to steps in the processing” can be considered one of the principles in object-oriented design. In OOD, each class has some responsibility and different classes collaborate with each other, as proposed by the class-responsibility-collaboration (CRC) approach. The methods provided by a class may be used at different times, on diverse parts of a system. Thus it is clear today that in OOD we do not decompose the system according to the steps in the processing, but in 1972 this was a revolutionary idea.

In another section of his paper, Parnas describes the Information Hiding decomposition criterion: “Every module … is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.”

The ideas expressed in these two lines are the essence of what today is called encapsulation. We know that in OOP each class should have a clear and well-defined interface that hides its implementation details. Modern object-oriented languages provide constructs which allow the programmer to define the visibility of members of a class, such as public or private.

When a programmer uses encapsulation to hide the “inner workings” of a class, he is assuring that this class will be:

  • Easier to maintain, because changes will not be propagated to other parts of the system.
  • Easier to extend, by adding new functionality while preserving the original interface.
  • Easier to reuse, since this class will not depend on the details of the rest of the system.

These benefits of encapsulation are well-understood by programmers today. It is natural to hide the details of a class when using object-oriented programming languages. But in the past people did not have appropriate abstractions to implement it.

Because Information Hiding is a principle, it was true back in 1972, it continues to be true today and it will still be true in the future. It could be applied in technologies that are now obsolete, it is an essential part of modern object-oriented technologies, and it certainly will continue to play an important role in new technologies in the future.

Software Developers must learn about the principles of Software Engineering. This is a principle. Specific technologies are good for the implementation details.

Posted in OOD, OOP, Software Architecture | Tagged , , | 9 Comments

Three rules to keep your sanity: Avoiding trouble on Facebook

Posted on November 2, 2012 by Hayim Makabee

Facebook is a wonderful tool for communication. It allows you to keep in touch with people whom otherwise you would have lost contact completely. It’s great to have news from our old friends and to see pictures from relatives who live far from us.

However Facebook may also be very dangerous. It may cause you to waste your time and distract you from tasks that should have much higher priority. If you are not careful, you may also have some very unpleasant experiences on Facebook.

Summarizing my own experience, here are three simple rules to avoid trouble and keep your sanity on Facebook.

Never post anything that may be offensive to someone

When posting on Facebook, you should behave as if you were talking to a public. Imagine that you are on a wedding and someone has invited you to make a toast. Of course you would never say something that may be offensive to someone.

Don’t behave as if it’s your own party, assuming that you are the host and you can say whatever you want. It’s true that you are posting on your own wall, but your posts will appear on the news feeds of your contacts. Did your contacts ask your opinion?

The more contacts you have, the more difficult it will be not to offend someone. Among your friends there may be liberals and conservatives, homosexuals and homophobes, Jews and Muslims. And if you have many such “friends”, most probably you simply don’t know them well enough to be sure if they will be offended or not.

Never talk to strangers

Do you talk to strangers in the street? Probably not. But people on Facebook frequently have discussions with strangers when commenting on the post of a mutual friend. Unfortunately, this kind of conversations may easily become unpleasant.

First of all, when talking to a stranger you may never predict how he/she will react. You may be surprised to discover that this particular person has very radical views about the subject. Worse yet, this stranger may be emotionally unstable and become aggressive.

But you may claim that “friends of friends” are not really strangers, right? Wrong. You have no idea what kind of friend you are talking to. He/she may be just an old acquaintance of your friend, or a co-worker. Be careful.

Never post negative comments or criticisms

If you don’t have something positive to say, it’s better not to say anything. Some people simply don’t know how to take criticisms, even if you make an effort to be polite. And on Facebook this is much worse because your negative comments and criticisms are public.

For most people, when they post something on Facebook, their main motivation is to collect positive feedback. They hope to get as many “likes” as possible, as well as many friends telling them how they are smart or funny.

If you make a negative comment or criticism, you are spoiling everything, and may make your friend very upset. There is a reason Facebook does not have a “dislike” button. People go to social networks in search of support and reinforcement.

In summary

In summary, if you want to avoid trouble and keep your sanity on Facebook, you must make an extreme effort to always be the nice guy. As nice as possible. Good luck!

Posted in Social Networks | Tagged | 2 Comments