Power of Presentations

No, I am not talking about Powerpoint today.

I am talking about the presentations that are less obvious—the ones we do every day. We are constantly doing presentations, although we are unaware of most of them.

You are writing an MSD paper---that’s presentation. No matter how well thought-out your content is, if you cannot spell correctly, you’re dead. Your readers will think, “s/he can’t even spell—s/he obviously cannot say anything intelligent!”

You are serving food on the table---that’s presentation. If the noodles look like worms—no matter how tasty they are, no one may touch them.

You are sending out a wiki page to your teammates---that’s presentation. You may be wanting feedback on the content and the format, but if the pictures are awry, you may get some different kind of feedback.

My grandma told me a story when I was a kid.

A great king once saw a dream. He saw himself waking up one morning to find out that all his teeth have fallen, except for one. Terrified, the king woke up from the dream (and made sure that all his teeth were still remaining).

The next morning, he called the royal wizard and asked him for the meaning of this dream. The great wizard thought for a while, and his face darkened. He said with a sad face, “Your Majesty, this dream means that all your relatives would die in front of you. You’d be the last one remaining, all alone.”

The king was so angry at this bad news that he took out his sword and killed the wizard instantly.

The following day, the kind summoned the wisest man in the land, and asked him the meaning of the dream. The wise old man thought for a bit, and his face brightened up. “Your Majesty, this is great news,” he exclaimed, “You will be the longest living among all your relatives!”

Call it euphemism or call it polishing, the wise man survived because of the way he presented.

So lastly, when you are communicating with others---that’s presentation also. Be very aware of what you say, as you may be presenting something you don’t mean to present.

Why is it so hard to talk about Architecture?

Through my experience in the program I have revised various software literature about architecture. And I have noticed tremendous advancement in the area of Software architecture and a huge effort to unify concepts. However, I have also perceived that software architecture is still young field of study. That is not yet well spread in many parts of the world.

My opinion is that the majority of the ambiguities in software architecture are mainly caused by the following factors: vocabulary, representations, abstractions levels and unawareness of factors that impact architecture.

Vocabulary

Vocabulary is important for communicating in any area of study. However, in this abstract world an architectural term could mean thousand words, just think in architectural pattern name and see how many words you can write about it. Having said that now just imagine an architectural discussion with several colleagues interchanging hundreds of these types of loaded terms. What is the possibility at the end of the meeting that the participants are in the same page? The point I want to make is that we need to be careful with the terminology we use. The architectural flaws have proven to be really expensive when these are caught at advanced stages of software development [Watts Humphrey]. So it will be worthwhile agreeing in terms and definitions as the SQUARE process does in its first step [Nancy Mead].

Here are small examples of some terms I find to cause confusion:

o What is the difference of these terms Software Design, Detailed Design and Software Architecture? Isn’t the size of the system affect meaning of these terms?

o MVC Pattern – Does this means the same thing to everyone? If you were going to express this pattern would it be in static perspective or dynamic perspective?

o Layers vs. Tiers – Are these the same? Why people used them interchangeably?

Seems like in different part of the world in both industry and academy there are continuous effort trying to come out with the most popular architectural dialects. As future software engineers we should be aware of this reality and be aware that when we go out there we should be careful how we communicate and introduce terms, because as in any change there will be resistance. Note that more important than the term itself, we should be worried about the meaning behind it. We see this clearly with the quality attributes names like reliability, maintainability, and which could mean anything if not defined.

Representations

As seen before, terms in the context of software architecture could mean thousands words. So, what can we expect about pictures or graphics trying to represent aspects of a system? My answer would be, even more implicit words than terms. As mentioned by Tony Lattanze in his book Architecting Software Intensive Systems, a picture could mean thousand words, but it will not be the same thousand words for everyone. That is why I consider representations a huge source of ambiguities when communicating architectural topics.

To help solving these ambiguities, it is important when providing graphical architectural representations that these should be accompanied with good legends specifying the different elements in the picture and their relations. However, this is not enough we should always write explanatory prose to complement and explained any underlying assumptions and responsibilities of the elements. Another important part when presenting documentation is to explain what is the perspective of this diagram and make sure the perspectives are use consistently.

It should be easy to determine whether it is it static, dynamic of physical perspective? Knowing the perspective of the provided structure is critical to know what properties of this structure assess when revising the diagram. For instance, knowing that a diagram is in the dynamic perspective will help reasoning of attributes such as performance and availability, which is not possible in the static perspective.

Abstractions levels

The nature of software is already considered abstract. And making abstraction of something that is already abstract is challenging. This show us that software architecture is not easy, and it is even harder if we do not speak the same language.

It is also important to know that additionally to perspectives to reason about structures. We also have within perspectives different levels of abstractions. These levels of abstractions are used to remove unnecessary details, which facilitates the reasoning about certain properties of the structure in context.

For instance just think in Google earth we can see the planet earth at different levels such as continent level, country level, city level and even street level. As you zoom in you will get more and more details. We can thing of this as abstraction levels when comparing this when representing the structure of the system. The problem in the architecture world is that we do not count with the “altitude” which helps Google earth to maintain consistent levels of abstraction. Knowing what is the “altitude” of our models is one of the biggest challenges to keep a consistent level of abstraction. Mixed perspectives and mixed level of abstraction is a huge source of ambiguities.

Factors that can impact architecture

I consider this point very important because, even before the project is conceived there are many decisions made that will have considerable impact in the final architecture and therefore a big impact in the project. If upper management knew a bit more how can business decisions such as deadlines, resources and team collocation affect architecture they will include an architect from the creation of the business case. However, in the majority of the cases there is not much to negotiate with the business that is why these are thought as constraints, but at least showing red flags at the beginning will contribute to avoid big surprises later. I do believe that a good management will appreciate knowing this upfront.

Another, type of decisions that have huge impact are technical constraint, generally seeing when there is the need for integrating with existing systems. Also, it happens a lot that companies constraint their self through technology selection. It is important to be aware that this decision will have an impact in the final structure. We should be critical about what quality attributes the selected technology will inhibit or promote and see if this is aligned with the system goals.

In short, it is obvious that requirements and quality attributes will affect the architecture, but is not always obvious that business and technical constraints will.

As mentioned by our architecture professor Tony Lattanze these are like loaded bearing walls because they are constraint and are not negotiable having a huge impact in architecture, so we should be aware these and communicate their importance at early stages of the project.

In conclusion, knowing the critical roll of software architecture in software projects and also knowing the high probability of miscommunication when communicating it due to factors mentioned above vocabulary, representation, level of abstraction and unawareness. As Abin mentioned in his post is crucial to be proactive to and try to surface ambiguities. I will recommend focusing in these areas because they a huge source of misunderstandings.

Deciding to use Pair Programming

During the construction phase of our project, the team decided to use XP. Of the 12 XP activities advocated in the first edition of the XP book we used 9, choosing to skip the metaphor (since we already had a solid architecture), simple design (not that we advocated complex design, just forward thinking), and having an onsite customer (since our customer was...not on site). Of all the XP practices, the most controversial for the team (and probably everyone else in the world) was pair programming.

According to our estimates, the schedule was extremely tight. We weren’t sure whether we would have enough time to complete all the features, let alone complete them working in pairs. Luckily I was introduced to some interesting data through a class I was taking, Significant Papers in Software Engineering taught by Mary Shaw. One of the papers we read was an article by Laurie Williams, Robert Kessler, Ward Cunningham, and Ron Jeffries titled Strengthening the Case for Pair Programming (PDF) and published in mid-2000. The data was a little old, but the essence of programming in pairs hasn’t changed that much.

The paper outlined two interesting findings which had a direct impact on how we might work during the summer. The first finding was that pair programming requires only a little more effort than programming alone. This study found that pairs require between 15% and 80% more programming hours to complete a task, not 100% more hours, than programming alone. In the data presented, a pair would usually start out requiring more effort and over time become more efficient, almost but never quite to the point of a single programmer. The second finding complements the first - pair programming gets work done faster. This study found that pairs are between 20% and 40% faster than programming alone. And on top of all this, the code quality was found to be superior compared to programming by on your own!

There were some problems with the data presented that made me skeptical. The first was that the projects used in the experiment were really just toy programs - small applications that were self contained and can be started and finished in a few hours. The second problem was that the teams were made up of undergraduate students with little to no industrial experience. The most novice person on the Square Root team has just over two years of experience and the team average is over three and half years. That’s three and a half years of coding habits (both good and bad) that we would have to reconcile to make pair programming work - something the undergraduate teams didn’t have to deal with as much.

With these things in mind, I created some projections to see if we could even afford to use pair programming, assuming the Square Root team performed similarly to the teams from the experiment. As you can see from the graphs, the findings were interesting from a planning perspective. The team decided that we were going to use some kind of code review, either pair programming or Fagan inspection.


In terms of effort, if the team operated in the 15% efficiency range, it was conceivable that pair programming would require less overall effort than Fagan inspection.


In terms of completion time, it appeared that we would be able to write more lines of code faster with pair programming than working alone (individual LOC/hour is derived from previous MSE studio rates in Java).

With these projections in hand, we decided to commit to pair programming for the first two iterations. Personally, I was extremely curious to see how we compared to the numbers presented in the paper. So, following the first two iterations, I pushed hard to conduct an experiment. Our experiment combined informal replication and lessons learned approaches to assess the efficiency of the Square Root team compared to the previous experiment. I’ll talk more about how the experiment was set up, the specific results, and what we learned in future posts.

Creating some projections on how pair programming would affect the team's plans turned out to be a great way to create buy-in for the process and instilled the team with more confidence. I don’t think pair programming would have been used as much had we not created these early projections to show that it wouldn’t completely explode in our faces and prevent us from finishing the project by the end of summer. On top of that, these projections and the data presented laid the groundwork for a series of interesting experiments that further solidified the team’s processes and use of XP.