Computer Science is an Art

Of the many eternal debates that spiral around software development blogs the one that seems the most intransigent is whether the practice of programming is an art or a science.

Chefs have a similar discussion over cooking and baking.  Cooking is an art while baking is a science.  Why?  Because when you put something in the oven, you had better get it right the first time.  Mistakes mean starting over.  Cooking, on the other hand, allows the chef the leeway to make changes as the dish progresses. The chef can take action to keep the dish from heading off course. For example, when making gravy you keep adding flour until it is the right consistency and if you add too much flour you can add some milk to thin it down.  It is incremental by nature.

Context as a commodity

How much context do you need to do your job?  Can we quantify context in any way?

Jeff Atwood has mentioned that he doesn’t shut his machine down every night.  He wants his environment to be as he left it at the end of the previous coding session.  Getting all the apps, tools or other windows opened to the right place takes not only CPU time but mental energy, aka context. 

Some jobs require no context, for example a bank teller can walk in to work on Tuesday and not need to remember any of the transactions that took place on Monday.  Contrast that with a novelist in the middle of writing a new book, let’s say writing the next chapter not editing anything.  They need to remember all the characters, their personalities, the existing story, and in what ways the plot threads are to interact in the new material.

Another good contrast is a professional athlete.  A pro baseball player doesn’t need to remember what happened in yesterday’s game in order to pitch a strike, hit a home-run, or execute a double-play.  The limited context that does appear has to do with the optimizing performance.  A pitcher does need to know the preferences and history of the batter who is at the plate, just like the batter needs to know if the pitcher has a wicked slider. 

Companies want to be “green” these days and have instituted policies to shutdown computers overnight.  This may be pennywise and pound foolish.  Here’s why.  A consultant gets paid $50/hr and it takes 30 minutes to get their workspace ready after an overnight shutdown lasting from 5pm to 8am the next day, 15 hours.  A conservative energy estimate would be if electricity costs $0.25 a kilowatt hour multiplied by 15 hours for a cost of $3.75.  So $25 is spent trying to save $3.75.  That’s motivation to use the hibernate feature at a minimum. It also is a very simple way to quantify the cost of context.

Can we describe jobs by how much context is required?  If so, is there a relationship between  the amount of context needed and the average salary?  Those are interesting questions, maybe I’ll cover those in a later post. 

Programmings Best Kept Secret

Software development is often compared to engineering or construction which has a hidden and debatable assumption that the source code is the product.  One camp has declared that source code is the design .   Other camps declare that programming as a branch of applied mathematics; see Dijkstra's "uncomfortable truth" quotes. Extreme Programming as a movement may have failed, it at least served as the flashpoint for a new examination of the nature of programming. Instead of arguing about engineering we can brag about how Agile we are or that we are Software Craftsmen.

Programmers are not engineers, nor are they artists.  Even when they are compared to craftsmen,  the comparison is always with woodworkers or blacksmiths. Programmers are nothing of the sort, programmers are writers.  Danny Thorpe discusses how you might tell what sort of literature your app may be.

Danny is on the right track but when it comes to software, there is an elephant in the room that needs to be discussed in the open.  Developers do not produce software, they write code.  This means that sometimes they need the logic skills of an engineer but just as often they need the communication skills of a poet.  Reading and writing, thinking about how to achieve a desired affect through the written word, those are the qualities of a writer.  It just so happens that the one of the chosen audiences is a single-minded overly-literal pendantic polyglot idiot-savant, otherwise known as a computer.  The other audience is other humans that may or may not have to actually follow the instructions, they do have to understand them well enough to tell if the instructions are correct.


It would be useful to compare programming to other fields and see how the comparison holds up.  It is not a coincidence that the games industry has adopted the filmmaking model for the production of games. Good choices would be publishing a book, producing a movie, or creating a recipe.


Programming as publishing


Programmers are the authors.  The compiler is the printing press.  Publishers are the companies that agree to fund the process in hopes of turning a profit.  Self publishing would be like creating training manuals for internal use; no profit is involved but the medium is appropriate for other reasons.  The book still needs to be edited, proofread, typeset, marketed, etc. I've covered this ground before but there is still much to contemplate.


Programming as filmmaking

Filmmaking is in interesting comparison because it deals with translating the written word into another medium. Programmers are the writers of the scripts and screenplays.  The producer is the stakeholder who desires the software. The director is the project lead.  Instead of actors and crew  we have the compiler which takes our instructions and executes whatever script of commands we provide; call it a screenplay or call it an application, the actions and actors my be different but it's still a set of commands given to actors to be performed.



Programming as cooking

Programmers create a recipe for a given dish.  The recipe is not the final product, the result of following the recipe is.  You don't buy a cookbook for the fabulous chocolate cake recipe, you buy it because you want to eat the cake.  In this case the compiler would be the tools available to the chef; pots and pans, utensils, and the stove/oven.  Having the right tools really helps but even the best oven won't correct a recipe that calls for 2 cups of vinegar for the sugar cookies.  Eventually software may survive the patent wars and finally be considered on par with a recipe; instructions to a cook in order to produce the desired product.

Summary

Software is  actually a mix of disciplines, all trying to contribute towards a common goal. The game industry may have it right, evidenced by them being to busy producing games and not endlessing debating whether their process is broken or seeking the latest silver bullet.  They use directors, producers, art and sound specialists, etc.  The compiler is their camera, used to capture the intent of the contributors; the CPU the silver screen for which to project the final product for consumption by the audience.

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.

In Search of Wisdom

The other day I was reading StackOverflow, a forum for developers to ask and answer technical questions, and ran across a post from a discouraged student. The responses had one thing in common: programmers know that they must keep learning. Tomorrow's hot new technology is just as soon to be yesterday's lost and forgotten relic. The best programmers are not the experts in a given niche but the ones who are comfortable with learning as a way of life. They know that they do not know and accept it. This makes them resistant to dictated dogma; a good example being Joel Spolsky's "Emperor's New Clothes" treatment of C-style strings. They are then freed from the ups and downs of the technological tide and are not battered by the constant waves of the newest, latest fad, nor do they feel deserted when some favored tech is washed away into the sea or wrecked upon the shoals.

Socrates is said to have walked the streets of Athens looking for a wise man. Wisdom is usually associated with knowledge but since it is impossible to know everything, true Wisdom is the awareness that you don't know. You can know a little about some things or a lot about a few. Those who believe they do know are blinded by their own ego and are thus willing to dismiss all doubts and set a course powered by a self-fulfilling sense of certainty. This describes how many a tribe of men met their tragic fate. Technology is not immune from the siren's song of certainty hence the never-ending search for the always-elusive "Silver Bullet".

When it comes to Wisdom, what sets apart the Codewright from the Code Monkey? A healthy dose of self-doubt. Doubt enough to realize that risks should not be dismissed solely because they are improbable. Doubt enough to allow the most skillful to help do the work, the most far-sighted to help guard the course, the most cynical to help figure the schedule. Doubt enough to keep unjustified self-confidence from enabling acts of hubris. This is just as true for teams as well. The best teams are the ones who understand both their strengths and their weaknesses. A group of individual superstars who can't learn to play together isn't always guaranteed success while a bunch of unknown amateurs who work has a cohesive unit can perform miracles.

Software development as a field naturally attracts those who are willing to accept the reality that there will always be more to learn. It is a good sign, one that indicates our chosen field will never stagnate. There will always be something to discover, a constantly flowing river of new challenges to overcome and puzzles to solve. The search for Wisdom is not for a desired destination, but of a fulfilling journey.

An Apprentice of His Very Own

In my career as a developer, I reached a point where the amount of work that needed to be done was much greater than I had time to do myself. Budget realities aside, there was a lot of coding tasks like writing more unit tests or keeping various diagrams up-to-date that would be tedious but easy to accomplish as long as a basic understanding of development was present. Wouldn't it be nice to be able to afford to hire your own apprentice? Someone maybe still in college who had some exposure to coding but was still wet behind the ears enough to keep quiet and learn by osmosis.

At the time, I had visions of a helper who could take rough UML diagrams, like from scratch paper or from a white-board session, and update the project documentation. As each change came through, they would create new versions and archive old ones like a file clerk from decades ago.

First off, a fresh-from-college developer might consider that type of work as beneath him or her. I'd argue that learning the processes is just as valuable as learning how to code. Did they learn about version control, shared builds or managing a large code-base in school? Of course not, but experience with those types of processes are what most junior developers lack.

Secondly, if your job is consistently repeatable enough to explain to an apprentice, why are you there in the first place? The apprentice is much cheaper and easier to replace. More than likely, you job is one of those ones which is hard to explain because it relies on your experience and training to understand how to approach the problem and the possible/practical solutions.

Usually I stay away from comparing software with construction but in this respect, iron workers have a similar problem: how to bring on new blood without getting anyone hurt or jeopardizing the project. Even the most junior iron worker needs to understand how to do his small part and stay safe. The head iron worker needs to trust that his men won't need explicit instructions for every task and that when a crisis erupts, they'll understand what the priorities are without having to stop and have a meeting.

So, what you end up needing is someone who wants to learn, has the patience to listen, the intelligence to follow directions, the determination to keep doing hard work even when they don't know the importance of their contribution, and the wisdom to understand that not all knowledge comes from a book. The next step is to think about how to carve up your work so someone can help you with it. That will have to wait for another day.