Single Responsibility or Changing Growing Responsibilities Principle

Architecture is full of examples of items designed to do more than one thing.  Your smart phone is a flash light.  From my last examples, a chair is also a clothes hanger.  A seat cushion is a flotation device. 

Robert Martin said in his book Agile Software Development, Principles, Patterns, and Practice (http://en.wikipedia.org/wiki/Robert_Cecil_Martin),  that every class should have a single responsibility over a part of the function.  The function-part should be encapsulated and the class should do that and only that. 

I understand the need for this as it makes the class easy to understand.  It also could reduce the introduction of bugs.  Have you ever worked with "spaghetti code"?  You make a change and it causes a bug in another area you couldn’t have imagined in your wildest dreams.   If a class has two different things it does, and you change one thing, it could affect the other piece and thus break something.  Martin gives an example a class that compiles AND prints a report.    If the content of the report changes, the class must change.  If the format of the print must change, then the class changes.  Martin argues that there is no reason for these two things to be coupled because if the format of the print changes, the content does not change and thus should not need to be recompiled and tested. Martin says a class should have only one reason to change (not two, like in this example).  

In an imperfect world, needs of software change over time.  An example: My manager is crazy over this particular module we have to is used to access and configure accounting data.  Over time it has evolved to access security data as well.  This drives him crazy because it violates the single responsibility principle (although he doesn't call it that and doesn't know that Robert Martin invented the term).  I however, think this is OK, and have argued this fact with him.   Given the schedule pressures we were under to combine these two pieces, which are closely related in our system, is not horrific.  Not perfect but not catastrophic either.  

Form Follows Function and Function can also follow Form

We as engineers know this old saying and if you are an SDM graduate, you may remember hearing or saying it classes.   But where did that saying come from?  It can be attributed to a book by Peter Blake called "Form follows Fiasco".  It was a critique of modern architecture which the author said was too focused on form and that the function should be the utmost important in any design.  This is what I always thought "Form follows function" meant - but some interpretations say that if the function is met in the purest, most simple way, the form follows and it will be beautiful.  (1)  .  The chair designs in Denmark represent this principle.  Software, which can so easily get complex, is another example (see some actual code later). 

So if we look at the chair picture from my last blog post, in the last row, that chair looks uncomfortable to me.  If the purpose of the chair is comfort, then without a solid back and full arm rests, this chair doesn't fit the bill.  However, if the chair is to made to fit completely underneath a table, then the design goals are different and conflict with the comfort goal.  To make a chair fit underneath the table, some comfort will have to be sacrificed.

So depending on the goals of the design, what form  will meet the design criteria?  That is the question to ask.  Each design criteria might not be met perfectly but the stakeholders need to decide which one can be sacrificed.  It was more important for the chair to fit underneath the table then for it to be perfectly supportive of the back.  After all people will only be sitting here for short bouts at the dinner table. 

Also what is beautiful in software code? I had my 84 year old mother look at some code and I asked her if she thought it was beautiful. She thought all of it was … very strange.  She could see no beauty in it whatsoever.  (To be fair, she also never liked furniture from Denmark, even when it was all the rage here in the US in the late 1960s). 

Here's an example of some weather data I was working with recently from a web service that needed to be parsed:

The data was in JSON (Javascript Object Notation) format which is a widely used  by web services to return data described with text, and is human readable.  To parse this, we could created one massive class with all the items needed inside. 

However, one could break everything into subsclasses like this design, such as wind, coordinates, etc into separate classes.  Is that cleaner?  Easier to maintain?  Easier to understand?  Beautiful form?  I happen to like all in one, the first case, because I can see it all in one file.  But if I changed wind, I would end of changing the weather class.  That can be a problem to introduce bugs into a larger system. 

Back to my Danish furniture, I found a chair that was brilliantly designed as clothes hanger. 

Is this chair a good clothes hanger?  Yeah, it's pretty good.  It won't function as a full closet but it can hang a few things.  Is it the most comfortable chair in the world?  No but it is supportive and someone can sit in it, even when clothes are hanging on it.   And it also keeps beauty in the curved lines and rounded edges.  Notice that the form does indeed follow function.  This form is not just of a chair that you can sit on.  It's a chair that you sit on and hang clothes on. 

Another example is a seat cushion that serves as a flotation device.  This does two things.  It isn't the best seat cushion in town and it isn't the best flotation device in town, but it works as both.  Tradeoffs occur.  Can you imagine what would happen to this chair if the designer kept iterating to make the chair more comfortable and to hang more clothes?

So while I agree function dictates form, the simplest form and often the most beautiful form will come from meeting the a minimalist set of functions.  

Each Iteration is Better

That's the theory any way.  An iteration is defined as "A process of repeating a set of operations until a specific result is achieved".   Iteration in software works because we can typically build something quickly for stakeholders to review.  From that feedback, we can revise the design.   For stakeholders, sometimes they don't know exactly what they want, so iterating allows them to change their minds without waiting until the final product to discover it wasn't what they wanted at all. 

This funny picture shows all the stakeholders involved in a product and how it can go oh-so-wrong.  Iterating through the project can make this picture not so funny-sad.  Yes the customer will explain the project like the first picture and the first iteration might deliver the second picture.  "But it doesn't swing", says the customer.  OK, we'll fix it to make it swing.  There's the third picture.  But oh, I need it to go around in a circle too!  The fourth picture won't happen because the programmer was already delivering the first two pictures, right?  And the descriptions don't matter, because we are using an Agile development process where "Working Software over comprehensive documentation" is what is at value.  There wasn't a separate installation, the product was delivered in phases so the seventh picture shouldn't occur with iterations.  How software gets supported - remember, all the stakeholders should give input into iterations, including support staff.  Iterations would make this series converge on the last picture.  With each iteration, the first picture would  evolve into the last picture - and with hooks on the rope so it can be more easily replaced by support staff! 

With iterations,  each design cycle should narrow all the possibilities of change so that the project can move forward.    For iterating to work with software or really any product design, all the stakeholders must have a clear picture of the final product.  In practice, this doesn't always work.  For example, the customer has one vision,  and several iterations are completed, and then a new vision emerges.  This is often considered a positive, as iterating is a discovery process for all involved.  However, most stakeholders involved need some kind of finish criteria and often a date is involved as well as money.  If you take the customer on a journey to figure out what they want,   it should be clear that there you can't predict when this could end. 

I've been involved in several projects where convergence didn't happen.  One was a case where the product was documentation to describe an existing architecture.  I couldn't get stakeholders to agree on what the architecture was.  I iterated over it several times and was honing in on something and slowly but surely bringing stakeholders along.  But one stakeholder, who was only marginally involved decided at the last minute that the architecture description was all wrong and that I needed to take a completely different view point.  His idea wasn't wrong, it was actually an interesting take on our system,  but I was running out of time.  It was frustrating.  Since I could not get stakeholders to agree, I drew up a financial statement showing what the company had already spent on this effort and that convergence was not going to occur, and I recommended they give up the effort. 

Here's another twist on iterations.  You need a team that trusts each other and is honest, while still being respectful of course.  One the stakeholders was the president of the company.  He wrote up an architecture a few years earlier and had several people review it.  Everyone said it was good and correct.  I realized that no one had the gumption to give him the feedback they were giving me.   I guess I should feel lucky.  His architecture description was not very good.   So even though it looked like his documentation converged, it truly didn't.  It wasn't used by anyone (except him), there were things incorrect with it, and it wasn't a useful description.  

Iterations often don't converge in real projects because we run out of time and thus we are stuck with what we've got.  I observed non-convergence in iterations when I was in Copenhagen recently, and I visited several furniture design museums.  I was fascinated to see these modern furniture designers used iteration. 

But when I saw these chairs, they all looked wonderful - beautiful designs in their own.  They didn't seem like incomplete versions of something.  In part this is the nature of furniture design versus software.  You have to build a chair and then build another chair for each iteration, versus just the legs.  But in this case, it seems like the furniture designer was not heading towards an end goal. 

I have a hard time figuring out what the designer's goals were with the first row of chairs.  It seems like he started with something more traditional/colonial, made it smaller and more simple, and then made some radical changes with the last chair.  This last chair doesn't look all that comfortable, but it is simple and beautiful.  In the second row is that each iteration - something was taken out, to make the chair more simple.  Each chair in the is functional and beautiful. 

A design that meets all its goals perfectly will not always lead to the simplest design.  And yet the two most simplest chairs are arguably the most beautiful.  From my experience,  the simplest software is the most beautiful as well.

My rule for iterating is stop before you made it too perfect.  Meet a minimum set of goals which may deliver the best form.    

Architectural Niceties

"I'm not going to slip schedule for architectural niceties"

This is what my very-long-time-ago boss said to me when I suggested we make a change.  He was a great guy - very technical and had experience shipping and supporting all kinds of hardware and software products.  But the words stung.  I recalled these words on another project where I was designing something for another group in the enterprise.  They needed the design done yesterday so the schedule pressure was high.  They were already behind schedule.  When I suggested a change that would increase the robustness of the design, but would be more time, the systems engineer flatly rejected it.  "The engineer working on it only knows this one way on how to do things.  Besides we need to finish this."

Oh. 

Certainly, designing for today and not tomorrow is something I adhere to in practice.  In Kent Beck's Extreme Programming (http://en.wikipedia.org/wiki/Extreme_programming) he describes four values, one of which is courage. It does take courage to design and code for today and not for tomorrow.  We engineers love "what if" scenarios.  However, it requires a lot of courage to refactor something - to throw it away and rewrite it when it no longer works or is holding back progress in the overall system.  Management also needs courage to allow engineers to do this refactoring as sometimes it doesn't add any new functionality but allows the system to more agile to other required changes. 

One project I worked on we had management approval to rewrite a whole swath of code that was generated by an obsolete tool.  The tool and the company that sold it were gone but the code we had in our system remained.  When functionality had to be added we coded around this generated code creating solutions that were downright awful.  Finally we had enough and we wiped out the whole thing and rewrote it.  It took months with several engineers involved.  It was completely worth it.  And we had the courage to do it.

In another project we found out we did the wrong design.  Unfortunately we already released the interfaces and they could not be changed. So we added in another wedge of code that was somewhat duplicative but was the design we should have done.  I recently was talking with another engineer and she pointed out the problems in this code.  I cringed.  I remember having to do the work and was just horrified at the solution I created.  But hey, we were under schedule pressure.  We had to fix this and fix it quickly. 

So as much as I want to believe I take the architectural high road, I don't.  I realize I have to have the courage to refactor these things.  Off to talk with my boss…it is a different person so maybe he will appreciate architectural niceties. 

Is Software Architecture Creative?

With my recent focus on building architecture and its comparisons to software architecture, a reader wrote me and said the he often found the field of software uncreative versus building architecture which he found very creative. I was surprised to hear this from anyone because I find software architecture inherently creative. I find living life creative though. So what do others think?

The Software Engineering Institute surveyed leaders in the field of software and asked them to define the skills of a software architect. This page collects those submissions. Out of the 37 or so entries, only eight listed the word “creative” in the description of skills needed.

Again I was surprised. I expected to find creativity as a key trait everyone looked for in a software architect. So maybe my reader was correct? Why do I find it so creative then?

Like any hard work, sometimes I get in a rut. Peter Cripps writes in his blog about keeping creativity flowing:. He has three points that I use in my everyday work.

First, collect the pieces as they come. Architecture in my experience is never designed all up front. We do the major framework and then we implement, then we change it, then we implement that new change, then we add something new to the framework, and we implement and test that. Make sure you don’t ignore that new information when it is fed back to you as the architect. Don’t gold plate your architecture.

Second, stop talking and do it. This of course is the heart of agile. Architects do get blamed for living in an ivory tower. This is why am I still writing code. Not only do I love to write code, but I can actually implement some of my designs. All that said, I know that I get criticized for thinking big picture when there are fires raging. I feel obligated to do that and I don’t consider it a waste of time. If that was all I ever did that would be a problem, but I believe in a combination of hands on work and pie-in-the-sky thinking.

Third, decide the time is now. This means using the information you have at the moment to set a direction and make a decision. I sometimes manage the risk of doing this but making the area most unknown the most flexible in the architecture. But I have also had to completely change directions in my design. Most managers hate when I do this. They feel it wastes time. Of course if I could always be right the first time, that would be ideal. But that is not realistic. Please, managers, allow your people to make mistakes!

So while building architecture is obviously artistic and creative, software architecture must also be. What happens sometimes with buildings is that they are so creative, the architect misses the function of the building. (Dare I point out some buildings at MIT that are like this? Not in this blog post!). In the field of software architecture, we strive to deliver functionality with a form that has the properties we desire over time – like maintainability, readability, extensibility – and other “ilities” that we compromise with depending on the system we are building. To me this is as creative as painting and it is work I could do for a long time.

The Permanence (or Not) of Software Architecture

There is a series of rants in software blogs about software architecture not being the same as building architecture. (http://bexhuff.com/software-architecture-is-not-building-architecture , http://triebert.nl/downloads/072005_swarm_concluding_paper.pdf ). The basic theory is the buildings are permanent where software is ever-changing.

I’m reading a book that throws this theory on its head. How Buildings Learn is subtitled “What happens after they’re built”. I live in a section of Massachusetts that has many old mills. The mills, beautiful sturdy buildings were falling down. An effort was made to rework them and now we have condos, restaurants, and businesses in these beautiful red brick buildings.

And although I agree that software architects are not building architects, we’ve been building for thousands of years and we’ve been creating software for 60 years at most. The book’s author agrees with the software people that buildings are not designed to adapt, but all buildings “adapt anyway, however poorly, because the usages in and around them are changing constantly.”

This line could also be applied to software. How many cases can you think of where the software was designed to do one thing but was called on to do another in later revisions? My team spends a lot of time figuring out what will be or could be desired in the future so we don’t break any needed extensibility. This is the Open-Closed Principle which states: Software entities like classes, modules and functions should be open for extension but closed for modifications.

Several famous building architecture quotes from the book can be examined in the software world. “Form ever follows function”, said by Lois Sullivan, a Chicago high rise designer in 1896 implies that we can always determine function. In software we can’t. In fact with Agile processes, we focus only on the needs at hand, not what could be (because it may never come to be).

Winston Churchill said “We shape our buildings, and afterwards our buildings shape us”. The author points out that this goes on forever. Yes we shape our buildings/software, then they shape us, and then we shape them again, etc. This reminds me of putting software in the marketplace, getting feedback, and then reworking the software to meet the needs of the customer.

“Flow, continual flow, continual change, continual transformation” is not part of the Agile Manifesto although it sounds like it could be. It’s how a Pueblo Indian, Rina Swentzel, describes her home village.

The book points out that more is being spent on changing buildings than building new ones. Most software engineers I know work on older systems modifying them versus building something brand new. The changes in old buildings are caused by three forces: technology, money, and fashion. In software, technology is a huge force in the design. No one would argue that. Money/ schedule/ resources also have more effect on software architecture than anything else in my experience. How many times have you not been able to do it right because of time/money/resource constraints?

Fashion is defined in the book as “non-functional stylistic dynamism”. There are certainly these pressures on software architecture – government regulations, software processes that go in and out of fashion, design patterns, etc. all effect software.

Three types of buildings are mentioned in the book – commercial, domestic, and institutional. I think there are also three types of software bodies – web, start-up and/or open-source, and larger companies/institutions. Commercial/web applications adapt quickly and radically due to intense competitive pressure. Domestic buildings/ start-up code bases or open source change steadily due to direct feedback from the family/customers and designers. Institutional buildings/software bases are slower to change there is reluctance and delay but they do eventually change.

But what in a building or software architecture project actually lasts or does not change? What makes it become loved? In a building, it is age. We have a module in our system that has been around since the beginning and has not changed much. I’m not sure it is loved or admired. But I secretly admire it - there isn’t much in the software world that survives the way an old grand building survives. The module is simple, extensible, and easy to learn.

So while I’ve always believed that Software Architecture is not permanent, I’m beginning to think we can learn more from the building architects. I will be blogging further abut many of the chapters in this book which I found on: http://www.accreditedonlinecolleges.com/blog/2011/20-educational-architecture-books-anyone-can-enjoy/

Why Software Architecture Fails

I have worked on very old software systems. Some are over twenty years old. Many software engineers I know work on older systems. What happens is subsystems get replaced over times by new subsystems, fundamentally changing the architecture. Sometimes when the architectural decay is so great, the entire system must be replaced.

Not so in this system I worked on. It is a work horse, as complex as it is now, with hundreds of engineers contributing to it.

There was one piece of this system I remember well. It was a communications system that allowed subsystems to exchange requests and data with ease. It has had very little change over the many years it has existed. The architecture stood the test of time. Even new users praised its simplicity. We added over the years many new subsystems and they all use this communications system.

But this is a rarity in the software world. George Fairbanks, in his book Just Enough Architecture, discusses a software system that manages hosted e-mail servers. Customers call support for help and support must search log files to see what happened so they can help the customer. The first version was simple and a grep style search was performed on log files on each of the servers. But as the system grew these searches took longer, slowed down the servers, and engineers were required to do the search. This architecture had failed. So a new architecture for logs was needed. The next version of the architecture had the log files copied to a central server every few minutes and the data was loaded into a central database. Support techs could access this database via a web interface. But the central database got slow when the amount of log data grew even more and sometimes the centralized server failed, losing data. The architecture had failed. So a new system was created by saving the log data into a distributed file system and parallelizing the indexing of log data. Ten commodity machines were used rather than one single powerful server using a third party file system. This system finally was able to accommodate their growing data needs and has remained in place.

In his book Why Buildings Fall Down, Mathys Levy says “A building is conceived when designed, born when built, alive while standing, dead from old age or an unexpected accident.” At first glance, this doesn’t seem to apply to software. Software doesn’t die from old age. It can run over and over again and not wear out. That said, software and the design behind it does seem to have a lifecycle. And when the load on it becomes too heavy, change must come or the system will not run, like the e-mail server example.

The book many sections that when read, appear to be talking about software. It has a chapter on redundancy and theorizes that all structural failures are due to a lack of redundancy. There is a redundancy failure with the e-mail server system as well as shown with centralized server.

Most software systems are not made to withstands what the book describes as Big Bangs. Whether directly or accidentally, software architectures make tradeoffs based on risks. If the risk of receiving huge amounts of log data is low, as it was in the beginning of the e-mail server project, then a simple architecture will work. But as the risk grows higher, a system to withstand the big-bang of data is required. Most buildings were also not created to withstand a big bang. An analysis of why the World Trade Towers fell on 9/11 (http://en.wikipedia.org/wiki/Collapse_of_the_World_Trade_Center) reveals that the building was not created to endure the heat of the fire and impact.

Resonance failures of when bridges break are similar to infinite loops in software. (http://www.youtube.com/watch?v=3mclp9QmCGs ). When this kind of loop occurs in a system, it will eventually shut down, just as the bridge broke.

Many buildings are covered with facades or what the book calls “Structural Dermatology”. Software also has a design pattern called a façade. A facade is an object that provides a simplified interface to another software subsystem. Like a building façade improves the look and feel of a building, the software façade can redesign a poor interface into a great interface. Building facades in New York City were causing a lot problems as they were crumbling down, water damages was creeping in, and lack of skilled artisans were not able to maintain and repair the facades. Software facades can also be just as problematic as the original and need to be skillfully added for the pattern to work.

Software can technically last forever. Buildings when they are erected are believed at that time to last forever. But in both cases they often do not. Neglect, abandonment, and replacement often dismantle buildings as pointed out in the book. Neglect, abandonment, and replacement also dismantle software architectures. As with buildings, it is often economically more feasible to demolish what is there and recreate something new.

The book concludes with five factors that the longevity of a structure. They are:

1. Structural theories – this is the mathematics around load and structure.

2. Calculation techniques – the ability to compute various scenarios in the design process.

3. Material properties – how do the building blocks of the architecture work under various scenarios?

4. Communication procedures – how do all the people working on the architecture understand all aspects of the architecture?

5. Economic factors – what can do within a particular budget?

In many ways, this is identical to the issues we deal with in software architecture.

1. Structural theories – what are the design patterns we are using?

2. Calculation techniques – what are our performance metrics?

3. Material properties – what are our assumptions about what data will be flowing through our system?

4. Communications procedures – how do we work together as a team? Do we all understand the systems architecture?

5. Economic factors – what can we do within the given time we have with the people we have?

There are more similarities to buildings than I could have imagined.

For more information on building architecture: http://www.accreditedonlinecolleges.com/blog/2011/20-educational-architecture-books-anyone-can-enjoy/