Measuring Software Architecture

I found interesting approach on the subject being developed by Structure 101 team. They introduced Excessive Structural Complexity, XS in short.

They pointed that an architecture may be seen in two dimensions: Tangle which is structural complexity on design level and Fat which is "too much code in one place". More precisely:

Tangle

it's set of items being in a cyclic dependency; tangle is counted on packages level; for each set of tangled items a Minimum Feedback Set (MFS) is calculated which is a minimum set of dependencies that would need to be removed in order make the graph clean

Fat

for methods it's Cyclomatic Complexity, but for clases and packages it's a number of dependencies between them

XS is an excessive ie. unnecessary complexity, so some thresholds must be given. Indeed, you are able to define thresholds for Tangle, and also for Fat on each method, class, leaf package, package (design) levels. You may also trust the defaults. Those come from Structure 101 team experience.

After normalization, XS gives one single number expressing an excessive complexity of a piece of code. Depends on code level, a XS might be Fat mean, Tangle mean or sum of these two.

It is very interesting because it gives fancy measure for each architectural level. It works well on: methods, classes, packages, layers and more abstract components levels.

Intersecting XS and number of commits to a repo, we might more accurately say what is worth to be refactored and what is not. (Idea of this intersection comes from Michael Feathers, but, as far I remember he use the Cyclomatic Complexity instead of XS)

For more information read the whitepaper or try out the tool.

Frame-of-our-work

Working with a software and repeatable tasks, teams walk form a hard-coded solution to a generic framework and back with confusion. Let's search for the third way.

Table below presents some attributes of those two types of approaches:

	adding a new code	maintaining a design	redesigning	as time goes by...
comment	How much time is needed to add new functionality which respects a framework architectural boundaries?	Any piece of code must be maintained from now to the end	Sometimes new functionality is out of a framework architectural boundaries. So that one need to be redesigned and refactored	What will be happening with the code in the future?
hard-coded solution	offhand	n/a there's no a design	n/a there's no a design	maintaining becomes really hard
generic framework	easy if one knows how a framework works	needs some effort	might be hard and expensive	two scenarios might happen: a framework becomes more and more generic till someone decides to kill the project or a framework becomes more and more coupled with business-specific code and then it goes toward a hard-coded solution

Frame-of-our-work

If both of extremes are wrong what is the third possible way? This is: don't build THE FRAMEWORK. Build THE FRAME-OF-OUR-WORK instead. Please, pronounce these two words: framework and frame-of-our-work. I am serious. So now:

• What a responsibility do you you put on framework and frame-of-our-work?
• What is possible to do with framework and frame-of-our-work?
• What is impossible to do with framework and frame-of-our-work?
• What would you give up changing a focus from framework to the frame-of-our-work or opposite?

You know, naming is important. When you label a project you give a team the direction of work and it determines what kind of work will be done or undone. Focusing a team on building a framework you are at lots of cognitive biases. A framework word is so imprecise that you may do more work than you intended to. Besides we do really like to build frameworks - check Source Forge or Google Code :).

Frame-of-our-work focus you on what are we really doing now? You need to inspect tasks a team do, before you start building a frame-of-our-work. This is nothing but Single Responsibility Principle.

I put a characteristic a frame-of-our-work into the table:

	adding a new code	maintaining a design	redesigning	as time goes by...
comment	How much time is needed to add new functionality which respects a framework architectural boundaries?	Any piece of code must be maintained from now to the end	Sometimes new functionality is out of a framework architectural boundaries. So that one need to be redesigned and refactored	What will be happening with the code in the future?
hard-coded solution	offhand	n/a there's no a design	n/a there's no a design	maintaining becomes really hard
frame-of-our-work	fast	easy	needs some work but it's acceptable	it's sensitive on rapid changes of business processes because it's highly coupled with them
generic framework	easy if one knows how a framework works	needs some effort	might be hard and expensive	two scenarios might happen: a framework becomes more and more generic till someone decides to kill the project or a framework becomes more and more coupled with business-specific code and then it goes toward a hard-coded solution

Although a frame-of-our-work is not so sexy as a framework does, my observation is the cost of redesigning a frame-of-our-work is mostly lower than the cost of maintaining a generic design of a framework.

A simple example

You build desktop application and you search for a good way to implement the GUI logic. It's not trivial in Java:) Focusing on framework you might decide to implement a generic Presentation Model with fancy widgets binding. This is very flexible solution, but...what kind of flexibility do you really need in your project?

On the other side, building a frame-of-our-work you might decide to prepare very simple Presentation Model where you have one stupid POJO per one user screen.

Both are well known approaches, but the difference is how much work will be done.

At last...

What if you really discovered a generic domain and a generic framework would be very useful? What then? Fork the project, find a sponsor in your organization and build the framework. But never ever build a generic frameworks as a part of your regular workflow.

The Developer and a developer

As an employer I have a privilege to decide who I work with. I hire people and also have fired some of them. I've noticed there is kind of employee who does right anything one has touched. And opposite: some people screw up even simple stupid tasks.

I cannot say what exactly is the difference, mostly I feel one is the right one. But I have some observations:

The Developer	a developer
is focused on the task	is focused on options of the solution or on 'the best solution'
is patient	wants to have things NOW
when failed feels a frustration or a sadness	when failed feels a guiltiness
assumes oneself of being a cause of one's mistakes	assumes others of being a causes of one's mistakes
argue with people	blame people
has own daily routine	does things impulsively
wants to know what was done right or wrong	afraids to know what was done right or wrong, so avoids it
takes things happened as a result of work and constant feedback	takes things personally
takes the responsibility for a relationship between involved stakeholders	takes the responsibility for tasks one was told to accomplish

Taking a responsibility

I always hear from team leaders: I want a developer to take a responsibility for assigned things. I was unable to understand what was 'a responsibility'. Now I think I should ask them: What are those 'things' you want a developer to take responsibility for?

Personally I am sure team leaders didn't mean responsibility for a task. A task is nothing. Having a task completed is not always directly related to increasing a business value. It may be, but this is not the rule.

Having said responsibility team leaders had in minds responsibility for a relationship. That's right. The core of being responsible for something is responsibility for a relationship between all involved stakeholders. Doing tasks is part of it. But meeting stakeholder needs and increasing business value always comes with taking care of relationship.

About payment

I won't write anything new. But spending our own money I convinced myself that cheap is expensive if about employee's salary. We used to hire employees only by reason of their financial expectations. Mostly they were unskilled. We invested our time teaching them. When they picked up some knowledge they left the organization. So we decided to hire the best people we can afford according to our business goals.

What Exactly Are Patterns?

I found very interesting paper: Developing GUI Applications: Architectural patterns Revisited by Alexandros Karagkasidis

Implementing presentation layer is a really tricky. It is at least so complex as implementing a domain layer and not at all less important. There are lots of approaches to the subject, from the most comprehensive MVC, MVP, PAC and HMVC to the most detailed being described by Martin Fowler or vendor-specific approaches i.e. MVVM (which might be described in a Flowler's language as well).

According to Alexandros all these share same problem: work well for simple cases. My own understanding is the core is how a GUI functionality should be exactly mapped to structural elements of a pattern.

Let's take MVC pattern. One may use this pattern on widget, container or window/frame level. Decision is left to a developer. Besides, from my experience an approach is highly coupled with a functionality flow and refactoring is really hard. Let's say you decided to implement MVC on container level and then a CR requires some small interaction between a frame caption, button, and tab color. You may hardcode it or extract a smaller MVC triad. With this, a refactoring is quite time-consuming.

My point is: non-GoF patterns define a general idea but it is not enough to implement them in a complex case. My observation is teams sometimes needs lots of iterations to find their own way to implement an architectural pattern. It may takes months or even years.

Mentioned article doesn't contain any solution, but it is worth to be read to give you an insight into a complexity of GUI development.

Conversation Patterns: Upward Generalization Pattern

This article is part of my work on Conversation Patterns for Software Professionals

---

Finally I've done Upward Generalization Pattern. I am really glad because the one and also Downward Specification Pattern are the 80 from the Pareto Principle.

Mastering both of them is essential for a developer to looking for the business needs and then system features effectively.

Sold out!

I had the agreement with my wife: we will buy new bookcase, when we will change the flat. Because changing a flat takes some time, so that the old one is still with us. But I found it overpacked.

I was standing looking on that 300+ books I had being collected for seventeen years and realized that a few of them really influenced my life. I realized I have read lots of books (there were times I was reading ten hours a day) and I know a lot of things, but it's a few things I have truly mastered.

For example, it has taken almost three years since I read Getting Things Done to implement it in my daily routine. It has taken thirteen months to implement some personal finances habits. Learning takes time, it takes plenty of time. God, I wish I could fully express what the difference between knowledge and skills means to me!

I packed all that books into bags and went to sell them. They picked out bestsellers and gave me 500PLN, its about 120EUR. 500PLN for seventeen years of collecting the books.

I feel strange now. I am terrified from one side and freed from the other one. Having books sold I only wish I met more friends instead of reading all that stuff.

What next?

---

Update: and I think I felt a shadow of the News is bad for you

There Is No The One Way in Software Architecture

At last they publish the presentation I did at Confitura Conference. It's in Polish, sorry.

This presentation contains my thoughts on software architecture. I'm talking about:

• importance of a technical context
• importance of a business context
• core domains which may belongs to the both technical and business areas
  
• few points being my own-made steps to verify vision of new architecture

I wish they published my 33rd Degree presentation, where I was talking about looking the Holly Grail and all that *Driven madness.

Conversation Patterns: What is "a need"?

This article is part of my work on Conversation Patterns for Software Professionals

---

We work with stakeholders needs hidden by wanted features, we try to fulfill our needs hidden by wanted refactorings :) I've already posted two entries in the subject. These are: A User Story Template Revisited and Don't Confuse a Need with a Feature.

But what is actually "a need"? I clarified this term in the Need Structure article on the Conversation Patterns for Software Professionals.

Conversation Patterns: Questions for Setting Priorities

This article is part of my work on Conversation Patterns for Software Professionals

---

Before we we'll talk about questions for setting priorities, we need to take a look at this issue from a stakeholder point of view. So, you are Stakeholder and I am Developer. Context is you want me to to deliver hot dogs to your team :) Here is our conversation:

You: Listen, we are waiting for hotdogs for four hours and we are starving. So, hurry up, pleeeease... Me: Ok, ok! We are doing our best. When do you want them delivered? You: When!? Four hours ago! Me: I have a solution for you. Let's talk about your priorities. What is the most important for you: bun, sausage, or ketchup? You: What? They are all equally important! Me: It's impossible. Choosing priorities allows you to have your wants at least partially done. It is for your own good to prioritize your requirements. Besides, there is no two things in the world being equally important. So, again: bun, sausage, or ketchup? You: But they ARE ALL important for us !^%@!#&!

Maybe the dialogue above sounds funny and you discovered a solution during a first reading. But it presents the structure of a typical conversation between a stakeholder and a developer.

The main issue is two points view. For most stakeholders their requirements are atomic. No matter how large they are: one LOC change or four-week long teamwork. For a stakeholder requirement is mostly atomic by design.

What Is The Need?

To set priorities the stakeholder need must be recognized first and this may be one of: an expected benefit or a problem to be solved.

To be clear, a human being is a really complicated object and the only things we have are models of its behaviour. All models are simplifications, but the may by useful or not. My model assumes that every requirement (functional, architectural or so on) of a stakeholder is driven by a need (an expected benefit or a problem to be solved or both). This model is extremely useful, so that I recommend it.

Questions for Discovering the Need (in the Priorities Context)

A stakeholder is mostly focused on the thing he wants, so it is good for your conversation to help him/her to name the need.

We'll use the Drilling Question Pattern. We'll ask a question with a presupposition there is a need back to the requirement. Because there are two types of a need (an expected benefit or a problem to be solved) you may ask two questions. One for presupposing an expected benefit and next one for presupposing a problem to be solved.

A structures for these questions are:

• If you would to start [a benefit presupposed] now, what it would be?
• If [a problem presupposed], which one you would give up first?

As you can see, assuming a benefit we asking for "achieving", but assuming a problem we asking for "avoiding". Some explanation of it you may find in article Don't Confuse a Need with a Feature.

You probably wondering: "Ok, but what kind of an expected benefit or a problem to be solved I should presuppose in my case"? Obviously it depends :) I'll give you a tip how to start.

There are two typical needs when you're asking for setting priorities in the business context:

• One wants to use a system feature - that is an expected benefit
• One is under pressure of time or money - that is a problem to be solved

So, now our questions for setting priorities might be:

• I you would to start using a feature now, what would you choose in the first place?
• Assuming you're lacking of money or time, which one of these features you would give up first?

I have mixed tenses intentionally, because benefits refers to the "future", but a pressure is being felt "now". So, if you are a native speaker, let me know how it sounds for you.

Let's Back to The Hot Dogs

You: Listen, we are waiting for hot dogs for four hours and we are starving. So, hurry up, pleeeease... Me: We are doing our best. I want to ask you something. If it takes next two hours to deliver all hot dogs, would you mind to give up bun, sausage or ketchup? You: !^%@!#&! We are taking buns, but NOW!

:) The dialogue above might happen, but it's trivial, huh? Let's take a look on the more realistic one:

1| You: Listen, we are waiting for hot dogs for four hours and we are starving. So, hurry up, pleeeease... 2| Me: We are doing our best. I want to ask you something. If it takes next two hours to deliver all hot dogs, would you mind to give up bun, sausage or ketchup? 3| You: Are you crazy! We want hot dogs! 4| Me: I see you are starving and I know we're late. I need more details to deliver hot dogs faster. May I ask you something? 5| You: Hit me. 6| Me: What it will happen when we don't deliver hot dogs on time? 7| You: I am afraid my boss will kill me. 8| Me: Listen, I'll give you two hot dogs off-hand for you boss. Would you mind to convince your team to wait? We will try to deliver hot dogs in two or three hours. 9| You: Hmmm...sounds interesting...

Again I tried to find a need (I assumed it is a problem to be solved = a hunger). This was line [2]. But my presupposition didn't meet your real need. So, I tried one more time in the line [6]. Your boss was your problem, not a hunger :). Starting from the 'boss problem' we build an acceptable solution.

That's all for now. Watch the blog for more Conversation Patterns.

Photo Credits: Bun, sausage, ketchup :)