When the Student is Ready, the Teacher Appears

I remember hearing from a 'higher-up' once at a previous company that we shouldn't do Use Cases.  "The customer doesn't like them", something I never heard directly from a customer. Doing a design review with use cases, a domain model, and a set of fleshed-out sequence diagrams was once described as 'over designed'. It was a mystery to me at the time why they would be so ambivalent about better ways to develop software.

Now, in my graduate class at UTA on Software Design Patterns, the assignments are ironically familiar:

• project requirements
• use cases (3 levels)
• domain model
• sequence diagrams, design class diagram
• pair programming
• test driven development

Not even ten years ago, these practices were still gaining acceptance in the industry.  A common complaint up until now has been that colleges and universities don't teach these techniques, which only gave the critics more ammunition.  Now that has started to change, hopefully the debate about these practices will be about how to best implement them instead of how to dismiss them.

It turns out that the solution to the mystery had nothing to do with the merits of any software development methodology but rather had everything to do with the rejection of in-house software development. This company had a long history of developing their own software and over the years had ended up with one of the largest technology departments  I've ever worked in, close to 1,000 people.  When the leadership changed, the attitude shifted from "Not built here" to "Don't build it if you can buy it".  They didn't value the capability to develop software, so trying to improve the process had become moot. Preferring to buy vs. build is a perfectly reasonable approach.  Some company's realize they don't want to be a development shop and make no bones about it.  The harm comes when there is a disconnect between management and the teams doing the work.  Psychologically, this would fall under cognitive dissonance; having a development shop mindset at the same time the departments actions are turning away from development.

It wasn't a surprise then, when it was announced that they were 'partnering' with a large three-letter company to rewrite their web-site, which happens to be the company's main source of revenue.  The team that developed the site was held in high esteem by the department, full of some of the smartest guys and pushing the envelope, all while supporting a truly business-critical app 24/7 with close to zero unscheduled downtime. The site happened to be written in C++, putting the bar high for development skills for recruiting. One of the clues to the mystery was at a monthly meeting of technical leads prior to the partnering decision.  Using C++ was being de-emphasized, the reason given was the difficulty in finding qualify developers.

The interesting question becomes, if you devalue software development skills will you lose the ability to monitor your partner and be a fully engaged partner?  Inevitably, you'll have to take some consultants word on a technical matter and you'll no longer be a partner but rather a simple client.  Keeping your organizations software development skills sharp benefits you even if you don't write the code.

If Gulliver Were a Designer

The term 'Design' gets thrown around a lot in software developer circles. There are constant flamewars over favorite techniques and battles over what good design really entails. When those arguments start getting too ad hominem figure out whether the speaker is a Code Monkey before giving them much credence. Since I've already braved the waters, see "Have Design Will Travel" or "The Age of the Design Review", instead of safely avoiding the issue, I'm going to bravely (or foolishly) join the fray.

Realize that there is more than one type of 'Design'. Design in the large turns into architecture and is something that really only comes with experience. Designing at the lower levels, say at the individual class/object level is easier to cover. Today I'm writing about design in the small vs the large; Lilliput vs. Brobdingnag.

The issues with designing a class is the same regardless of platform or language. The key is whether an object should be autonomous or whether it is better for any given behavior to be spread out among objects with limited scope and distributed responsibility.

For each class the answer might be different. We end up with a spectrum along which we can place classes based upon the Density of Responsibility.

             (Level of responsibility for behavior)
        Autonomy - - - - - - - - - - -  - - Dependence
     High
 C      -   [god object]                [spaghetti]
 l      -
 a      -
 s      -                                
 s      -           
        -                  
 s      -
 i      -
 z      -
 e      -  [template]                   [framework]
      low

Let's say you favor letting the class perform all the behaviors itself, or as many as you can. Starting on the left side of this graph, when you make your class more autonomous, the size of the class will grow unless you continuously refactor it to make it more generic. This leads to a template. If no refactoring is done, the tendency is for the class to become more "god-like" because if there is some behavior it needs, it has a method for that - it can do anything and everything. The number of fields and methods grow and soon become both unmanageable and unavoidable. Since the class already does so much, coders would rather add to the monstrosity than try to piece it apart and cut the Gordian knot.

The right side of the graph has classes that depend on other classes to a large degree. If the dependency level is high but the individual class is small, that is a sign of a framework; each class doesn't do much and requires lots of dependent classes to accomplish some function. On the other hand, a highly-dependent class that also has a large amount of code is a sign that the class is full of spaghetti.

The key to this question is to determine where you feel more comfortable on the graph. In any event, individual classes will end up spread out on the graph unless some organizational principle is applied, which is how you can achieve the results of Template or Framework.

Having just written that, I would say that there is a correlation between class size and degree of organization. Robert C. Martin (or "Uncle Bob") covers similar ground with package dependencies in his very thorough paper on Design Principles and Design Patterns[pdf]. JDepend is an implementation of the ideas behind the graph on page 26 and complements static analysis tools such as Checkstyle and PMD.

The Age of the Design Review

Is programming an art or a science? That question has been asked for many decades and it will probably be asked for many decades to come. We've been searching for the construction equivalent of standardized parts like screws, nuts, bolts with which to construct software. We've treated coding languages and code libraries like silver-bullets and have been disappointed every time.

My question, is Software Engineering showing signs of maturity? In a post named "Leaky Abstractions and the Last Responsible Moment for Design" Jeremy Miller gives a good example of looking at a design and reviewing it.

I believe that we are seeing the beginnings of the common language needed to really improve the ability of practitioners to objectively discuss, evaluate, and correct the designs of others. One solution that is often suggested is to perform code reviews, which assumes that code standards have been put in place. Code reviews are nice but they usually come in two flavors, either examining the syntax or the design. Syntax reviews can be simple 'proper use of braces' to more detailed like patterns for using virtual destructors. There is a limit to syntax reviews because the code has already been written, like shutting the barn door after the horse has already escaped. What is frequently mentioned is the need for a design review which has been the holy grail. How do you do that without a common language? Design reviews no longer seem beyond our grasp. I've seen plenty of stories where time after time, software injuries are self-inflicted by Code Monkeys and Cowboy Programmers. Design reviews might not create world peace or feed the hungry but it might make it easier to keep apprentices or journeymen from masquerading as master craftsmen.

Between Anti-Patterns, Code Smells, and Refactorings I have the impression that the industry is reaching a point where we have the tools to properly review and critique software designs consistently. A common set of terms for describing and understanding problems; a common set of tools for describing and implementing solutions.