Thinking Backwards or Forwards

I've heard references to a new style for documenting requirements. Greg Young talks a little about it in his post on business requirements at CodeBetter.com



I think he is onto something, as it is usually fairly obvious that business customers can handle some pretty complicated procedures and process flows, so why do they struggle with a machine, or state, based approach?  The difference I suspect is that they focus on the action and not the state. The specs he describes are centered around a state, lists an action and only then describe the behavior that results from said action; let's write it thusly:




State ->Action->Behavior.



I'd be willing to bet that the users are really thinking like this, "I want it to do X (Behavior) so I have to push the yellow button (Action) but it only works if the red light is on (State), or



Behavior<-Action<-State





The style of documenting has enough in common that they understand what is being asked for even if, to them, it is listed backwards. As an aside, another major difference is I've never had a business user ever want to have a meta-discussion on how they think, so we tend to have to take it into account when designing the requirement gathering process but that will have to wait for its own post.

Programming as an Individual Activity

I've decided to come back to Weinberg's classic 'The Psychology of Computer Programming' since it is at the heart of why I took up writing about programming in the first place.  At my first job oh so long ago, it was obvious that we were nowhere close to a solution to programming-in-the-large.  With applications small enough to be written by a single developer we could manage to deliver software that works, maybe it was inefficient or clunky but it worked well enough.  Sure large systems were built using the waterfall approach but they would invariably overrun both their budget and their schedule.  The industry was by no means young, even though the PC revolution was in full swing, the underpinnings had already been discussed ad nauseum. You could dismiss the waterfall method but would still be left with the same questions, 'what do they want?', 'how do we build it?', 'how long will it take?', and so forth.  The Agile or Lean movements have been able to change the discussion to ask 'what is the smallest amount of work that we need to address at one time' and go from there.

I believe that we have been avoiding the most important questions - which are uncomfortable to contemplate - like, "what is the largest single aspect that controls a software schedule?" or "How do we plan a project when the members of the team are not pluggable resources?"

This brings me back to one of the biggest unresolved question of our field, "Why can't we engineer software like we engineer buildings or spacecraft?"  I ask this not for serious comparison since the differences are legion, but rather to point at the single most important advancement in the field of engineering since the advent of the first simple tools (the lever, the wheel, etc), calculus. 

Why calculus you ask? because it gives us a way to plan for infinite variability and still have confidence in the result.  Planning a trip to the moon would be impossible without being able to calculate how much fuel is needed since how much fuel is needed depends upon the weight of the rocket which creates a recursive dependency.

Software will have no equivalent for calculus because the variability comes from the people participating in the project.  Until we accept that people are a first-order component of any software project we will continue to look to silver-bullets, the next development process fad, or the latest new-fangled technology for relief.

Computer Science or Software Engineering - An Elemental Problem

What is the difference between Computer Science and Software Engineering?  That depends on the nature of the problem you are trying to solve -  is your problem one of Silicon or one of Carbon?

In my 20-year career in working with software, the single biggest issue has also been an elephant in the room: the abysmal success rate of large software systems.  Plenty of books have been written on the subject with lots of great, if unheeded, advice.  Scope creep, ambiguous or missing requirements, poor communications, bad risk management; lots of reasons have been documented and just as many if not more solutions have been suggested.  Brooks gave us "The Mythical Man-Month", Yourdon writes of "The Death March", Tom DeMarco has "Peopleware". All of them attempting to answer the question, "Why is it so hard to write software?"

If you take the all the books on writing software and put their suggestions in one big list, the first question would be, "If we have all the answers, why don't we use them?"  That might be nice for getting it off your chest but isn't has helpful in pointing us in the right direction. At its core, this question does have a useful kernel, it assumes that 'we' are the problem.  If only we used this process, if only we implemented that practice, if only we hired the right people, if only we kept our teams motivated.  As an aside, most of the reasons for failure are management reasons, not technical ones.  It should be no surprise that many find the case study on the sinking of the Vasa in 1628 to be very instructive. The blame is as much, if not more so, on the King's unrealistic demands as on the builder's efforts to failure to meet the royal requirements. In our endless efforts to build bigger, more complex and complicated software solutions in the face of almost certain failure, should question our sanity; one definition of insanity being, "doing the same thing and expecting different results." Biting off more than we can chew, choking, and then doing it all again time after time only shows how our hubris can get the better of us, allowing us to continue on our Sisyphean task.

This brings me to an interesting observation.  There is a long running debate over whether computer programming is/should be considered a form of artistic expression or of engineering prowess.  Computers have such a wide scope that many sub-fields have crept up, hardware and software being the most obvious. Hardware is typically the realm of the engineer, designing circuit boards or embedded sensors.  This changes as the hardware gets larger in size or scope.  CPUs have microcode, missiles have on-board navigation systems with programmable targets.

Most universities that offer degrees related to programming computers name the department Computer Science.  Now, being considered a 'science' may be just a way of expressing the notion that computers are deterministic and worthy of comparison with mathematics or engineering, having likely grown as an offshoot of the field of electrical engineering.  Whether it be data mining, security, networking, or pure algorithms, most of the areas seem to ignore the question of why software is so hard. They assume the problem is in the silicon computer chips.  Curiously, these fields don't even attempt to address this most difficult of questions, assuming improvements of our silicon constructs or their usage will somehow mitigate our human foibles. If only we had better tools, or faster computers, etc. then our carbon-based brains could somehow ascend above the project management miasma and become a beacon to those who struggle and toil without end. Considering the gargantuan number of man-hours and humongous amounts of money wasted, such an accomplishment would be of heroic proportions, mythic even; a modern-day retelling of Prometheus or Sisyphus.

The truth is that Computer Science may bring improvements in areas where the problem is in the silicon, it is mute when asked to provide answers to problems of a carbon nature.  Software Engineering attempts to develop solutions that include how humans work together.  Software Engineering does not assume that software development is as cut-and-dried as putting the right circuits on a board to achieve the desire product, or breaking down a complex problem into constituent algorithms to make the problem more manageable. There is no magic bullet, no single development process, no single answer.  To understand why humans have a hard time developing software, we must admit that humans are part of the equation. Doing is brings with it a cold truth about humans - they are non-deterministic by nature.  Alistair Cockburn describes it as people being non-linear, first order components in software development.   To answer the question of what is software development, we might have to take detours through Psychology, and may be surprised to end up working with Philosophy even.

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.

Martin Fowler, Alistair Cockburn, and Optimism

The effort to make Software Engineering actually live up to the 'Engineering' part has been greatly helped by Martin Fowler's book on refactoring. Martin recently posted about his decision to not participate in an effort by others in the industry, not lacking in optimism, to define a common process for software development.

Martin Fowler declined to get involved in a similar effort and for the same reason.  The key quote is,

“Why this is so was primarily crystallized for me by Alistair Cockburn who explained that since people are the central element in software development, and people are inherently non-linear and unpredictable - such an effort is fundamentally doomed.”

While my previous post about Alistair's paper covers much of the same ground I felt it was worthy of an update.  There will always be souls who crave consistency just as there will always be salesmen willing to offer the illusion of it.  Facing our own nature is one of life's hardest lessons. Some of those who ignore the human factor are optimists seeking to improve their chances of consistency, which has driven many towards the latest and greatest geegaw, a new language, a new GUI, a new design tool. Others are simply deluding themselves in the hopes that if only people would sit up and fly right (read this to mean 'do it their way') all our problems would be solved. 

Studying the process of computer programming has been around for decades.   Even so, we still have trouble internalizing human foibles - people aren't predictable and follow "standards" about as well as a random-walk.  So the most successful way to get people to be consistent is to lead by example, blaze a trail ahead and show them the way.  In this manner Extreme Programming was its own worst enemy and its own best cheerleader. By showing how a set of practices work in situ, it created a much-needed focus. The "Waterfall" model was the favorite whipping-boy, essentially dead, and the iterative approach was in its infancy.  So XP served as a lightning-rod for discussions on the craft of software development.  It provided an example of practices that could be emulated and provided an easy target for the doubters, disbelievers, and denialists; no doubt the negativity coming from the critics was channeling  their innate understanding of the darkside of human behavior.

While Extreme Programming hasn't become the standard development model, that doesn't mean it failed.  When the history of Software Development is written, XP will be given credit for re-introducing the most important factor; not tools nor process, but people.

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. 

Of Rockstars and Bricklayers

Today we're going to start with a thought experiment.  You are one of the better coders in your company.  All the proof I need is that you're reading this.  Ok, that may be a little self-serving but it is true that the better coders I know are always reading something about coding.  It might be a new language, or a new technique, a programming question and answer site, or even a site that likes to rag on bad code. 

Based on how many Code Monkeys you know, it's easy to figure yourself in the top half of programmers, a 'good' coder if you will. An assumption that is easy to make is that the higher your productivity the higher your pay.  Is this true?  If you base it on simple experience, the answer is no.  It's too easy to get a job right out of college and get mediocre raises and then find yourself interveriewing candidates for openings in your own group where you have to offer 'market rates' to attract anybody.  If you've been there for 5+ years, given a company desperate to hire warm bodies, it doesn't take much for the new guy to be making 15-25% more than you even if he is a two-finger typist and can't spell SQL if you spotted him the 'S' and the 'Q'. 


Now, I'm happy where I am but it didn't take much to trigger my bad habit of thinking up 'what-ifs'.  The Stackoverflow podcast has been a good one for this sort of pondering.  Jeff and Joel have enough real-world experience to bring a ton of wisdom to the discussion on programming as it's own topic and in episode #42 discuss underperforming programmers.  I'd been reading about how star actors can command huge salaries based on their past work and the expected effect on the box-office if their name appeared on the marquee.  That major-league sports can have individuals who make 10-times what the lowest paid athlete makes on a single team, it doesn't take much to ask why programming doesn't see the same effect. 

I submitted this as a question to the Stackoverflow podcast which they spent a good 10 minutes on in episode 77. It didn't fit so well as a question on Stackoverflow itself, I suspect the culprit is the lack of code snippets. Interestingly enough I discovered the podcast when they were at episode 65 and decided to start listening back at #1 and was up to around #42 when I decided to contribute my question.  So anyway, when I saw the summary for #77, I didn't have the audio handy so jumped over to the transcript wiki for #77 and read the transcript.  It was a pleasant surprise at how engaged they were and that the question wasn't dismissed out-of-hand.  When I downloaded the audio, to hear their discussion it only reinforced my reaction.

The range of talent can be mighty wide even if there is some disagreement on the empirical numbers.  Joel Spolsky talks about the difficulty in finding great programmers, and uses similiar metaphores in a comparison with opera singers. Jeff has a similar take on Coding Horror.  Finding great talent is hard because there are only so many people who can do what you need done.

There have been some good discussions that has surfaced.  John Cook has a good argument based on lack of meaningful metrics.  It's a question that has been around for awhile.  Frank Wiles makes the claim that hiring average (or below) programmers actually costs your company money (followup post). Obviously when a company says they only hire the to 10%, they are deluding themselves or at least paying lip-service to wanting good programmers.  Joel does a great job of shattering that particular illusion. 

What about sales? In some fields top salesmen can bring home seven-figure incomes so we know that the wide range of incomes aren't limited to Hollywood and the big leagues.  James Kwak picks up on John's post and supports Joel and Jeff contention that paying the top performers much more than the average, outside of easily measured areas like sales and movies, has a corrosive effect on the group and the best coders end up leaving for greener pastures while the dregs hang on for dear life or are eventually pushed out.  I can't disagree.  It seems that if you are underpaid you have to ask yourself Ann Lander's question, "Am I better off leaving or staying put?"  Just realize that it's no use complaining to the company, the status quo works for them.

Life's Too Short To Work For Clowns.

One of the cliche's of our culture is the little boy who rebels against his parents and dreams of running away to join the circus. His mind is filled with the glamor of the Big Top, the exotic animals, the independence of wandering the country from one town to the next. He hasn't really thought about what it means to work in a circus. The Ringmaster did many menial jobs before arriving in the spotlight. The animals have to be cared for; double the time it takes to feed them when you consider both ends of the animal. Traveling from town to town may sound romantic until you realize it means you spend more time traveling than in one place, lots of lonely nights on the road regardless of the weather or climate because 'the show must go on" after all. The life of a circus is not just popcorn, parades, and pretty girls.

I ran across a quote in Christopher Duncan's, "The Career Programmer: Guerilla Tactics for an Imperfect World" that made me both laugh and sigh.

You need to consider one additional thing when trying to convince management the current approach to developing software needs improvement. What do you do if non of this sways them and they insist on continuing with chaotic development approaches that consistently create disasters and stress? Update your resume. Life's too short to work for clowns.

So the question becomes, do you work for clowns? Does the development process at your company make a circus look like a well-oiled machine? You might work for a clown.

I plan on putting together a complement to The Joel Test where instead of a list of things a company does before you consider working for them, The Clown Test would be a list of things that indicate you might work for clowns.

This might describe your boss,

• if he thinks an estimate is a promise,
• if he thinks developers are interchangeable with no effect on the schedule,
• if he thinks its ok for the lead developer to publicly berate a junior developer,
• if he thinks requirements documents are a waste of time,
• if he thinks the only place for designers is at a fashion show,
• if he thinks he just needs one good programmer who can code anything,
• if he thinks that people whine too much about teamwork,
• if he believes in Silver Bullets,

he might be a Tech Clown.

My apologies to Jeff Foxworthy.

When you run across a good example of a Tech Clown, send 'em my way and I'll add it to the list for every one's enjoyment.

Extreme Programming is People

There has been an enormous about written in the blogosphere on ways to improve how we write software. Much of the virtual ink spilled on the Internet about Extreme Programming, or Agile, or SCRUM, gathers at opposite ends of the spectrum. Some focuses on how those practices make things better, usually in a overly enthusiastic way which invites the curt dismissal as nothing more than hype and hyperbole. Others constantly remind everyone that they've tried it and it didn't work which invites observations about anti-social programmers.

Both camps need to call a truce. They'll get much farther - and be happier - if they stop throwing grenades at each other and start talking to each other.

We can get both sides to agree that the previous ways of software development is problematic and certainly non-optimal, at least if the goal is to develop acceptable software in a reasonably quick, consistent, and effective manner.

Once we've agreed on common goals, we can discuss typical obstacles and plan ways to avoid or mitigate them. One of the biggest problems, and least discussed, is how people affect the processes in which they participate. There is a good article by Alistair Cockburn about this phenomenon. His paper is titled "Characterizing people as non-linear, first-order components in software development".

The Story of Joe and Al

So let's examine more of the laws and how they affect an effort to introduce Extreme Programming. People who use the 48 Laws as a handbook for how to live their lives are usually label as evil, justifiably so. I don't want this discussion to degenerate into name calling or dismissed because of guilt by association so let's create two personas as our antagonist and protagonist. We'll call the willing and manipulative one Joseph (think Stalin) and the unwitting and hapless one Al (think Flowers for Algernon).

Law #1 "Never Outshine The Master". Humans are sensitive about losing face in front of others. Joseph uses this to his advantage to keep from attracting the wrong kind of attention. Al is proud of his achievements and doesn't understand why others don't share in his celebration.

Law #2 "Never put too Much Trust in Friends, Learn how to use Enemies" - Joseph keeps reminding himself to watch out for number one. He doesn't want to put his fate into the hands of others which means fewer allies but also fewer fair-weather friends. Al, on the other hand, cannot comprehend the idea that people have hidden motives even while having repeated instances of being taken advantage of.

Law #3 "Conceal your Intentions" is "Do unto others before they have a chance to do it to you". Keep the knife hidden from your intended victim. Joseph believes that life is a zero-sum game. Since he values himself over all others, he won't lose any sleep taking what he wants so he'll have more. He's interested in power and control, if he takes it from you it means you'll be powerless to respond after his power grab is fate de'compli. Al doesn't have the mental capacity to think one thing while saying or acting another. George Orwell's "Doublespeak" would be a foreign concept.

Law #7 "Get others to do the Work for you, but Always Take the Credit". Some poor soul on StackOverflow called this a "Seagull Manager - a scavenger who takes all the credit for your hard earned work and hangs around you like a bad smell." This will be a common behavior for Joseph who lacks scruples and thinks those who let him get away with it deserve to have their credit stolen. Al believes what society preaches in public, the value of hard work, work hard and keep your nose clean and you'll get what's coming to you, etc. He has the pride of the workman where good work will be recognized and rewarded. Combine that with no ability to detect deceit in others and you end up with someone who becomes the pawn of others. Naively believing the promises of their antagonists.

You can't approach a social situation as if everyone has the same motivations. Workplaces have plenty of Josephs blending in waiting for any situation to turn to their own personal advantage, and Algernons trying in vain to be accepted. If we don't recognize that, we'll be like farmers watering their crops with beer, "It tastes good to me so it must also be good for growing corn."

Peanut Butter Programming

When I first started messing with dynamic web pages it was using Perl and CGI. It was fun at first getting a page to respond based on some algorithm. It was also easy to overlook the growing mound of HTML strings embedded in your program. It soon became apparent that this approach doesn't scale very well. Keeping track of which tag needed to be closed and when was too much like keeping track of dynamic memory allocations in C.

Java came along with Java Servlet Pages (JSPs) and it seemed like a huge improvement. By inverting the relationship between code and HTML, you didn't have to have your HTML all strung out in little bits in the program. When you wanted to include some program logic in your page, you had two choices: write an extension so your logic could be expressed like an HTML tag, or you could embed it as a code-snippet directly in with the HTML. While there were plenty of examples of how to create your own tags, the overwhelming amount of JSP code I've seen took the other approach. To the extreme. When some behavior was needed in multiple places, sometimes it refactored into a common file and then referred to from multiple pages. Other times (which translates to whenever possible), it was copied and pasted around with the justification of "I just need it to work". The result was a file with little bits of program strung out through your HTML. Sometimes mixing two things can prove to be a good thing. remember the the TV commercial for peanut butter cups? "You have your peanut butter in my chocolate! No, you have your chocolate in my peanut butter!" Unlike that TV commercial, mixing HTML and code is a recipe for heartburn. Peanut butter may be tasty but will stick to everything it touches and you'll end up with a greasy mess to clean up if you're not careful. That's why I call this "Peanut Butter Programming".

Why do developers keep using approaches like 'cut-n-paste' even though they usually know better? When the choice is between doing the expedient thing and the right, people typically want to do the right thing but only to a point. If 'cut-n-paste' is simpler or easier than doing the right thing, the playing field becomes so tilted that some other motivation needs to be strong enough to deter choosing the short-term solution. Code standards are one example of that kind of motivation. They express a value judgment that the increasing maintenance costs of supporting bad code is not worth the time saved by taking short-cuts. If the programmer knows he'll have to face his peers and explain why he took a short-cut, his choice becomes "I can do it quick-and-dirty (QaD) in 5 minutes instead of the right way which would take 15 minutes. But if I do it QaD, I'll have to spend 30 minutes arguing at the code-review. It's not worth the argument so I'll just do it the right way and save myself the trouble." This sort of balancing act shows up naturally during pair-programming where having the second coder around makes it harder to justify writing messy code on the first pass.

Recently, I went to a class on Microsoft's ASP.NET technology. Setting aside any feelings for the company, the way they approached the problem of mixing code and HTML was to make it easier to do the right thing. They introduced the concept of a separate 'Code Behind' file which contains the C# or VB code for a given page. By making it easy to manipulate objects on the page and respond to events while keeping the code separate, they've made the right way also be the easiest way.

Even experienced developers will justify taking a short-cut, however short-sighted, if doing the right thing is hard enough to do relative to the short-cut. Different people have different tolerance level for short-cuts. Understanding why people do the things they do isn't easy but gives us the perspective needed to address the problem.

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.

We Have Met The Enemy

In the previous post "Why Extreme Programming Fails"I attempted to shine a light on a dirty little secret of software development. The biggest obstacle was, is, and shall be, the people writing software. Do I condone the 48 Laws of Power, of course not. But to ignore the realities of human behavior in building software would be as foolish as building an elaborate sandcastle on a beach below the high-tide line and expect to hold back the water from destroying all your hard work. Programming is a social activity. See my review of Weinberg's book at http://codewright.blogspot.com/2009/04/programming-as-social-activity.html.

Sun Tzu wrote that you should know yourself and your opponent to have the best chance of victory. Understanding your team is the best place to start to ward off non-technical issues. Admitting that people have hidden motives is not to say those motives are good but to realize how situations should be approached or to understand why a given developer is so hard to work with. The 48 Laws are stated in an almost malevolent way in an effort to illustrate how people act at the extreme. Law #1, "Never Outshine the Master" can be taken either as a command for those who want to curry favor or it can be taken as a reason why a long-time developer may not take it well when showed up on a coding task by a new hire. At their foundation, the laws show behavior issues where ego, mistrust, control, and laziness are the motivations instead of loyalty, honesty, or integrity. We don't have the luxury of assuming everybody in the workforce is on the up-and-up or motivated to do a good job; once we learn that lesson we can begin to steer our own course, taking detours around those who put obstacles in our way instead of being at the mercy of those whose desires are as capricious as they are destructive.

Why Extreme Programming Fails

In the decades of the young life of software development, we've discovered many behaviors, processes, and techniques which have nothing to do with software yet continue to hold back progress. We ask time and time again why the mythical silver bullet is still searched for by those who have already agreed that it is a fools errand. Why are death-marches allowed to form when the futility is obvious to all but the oblivious? Why are proven techniques not mandated by management or agreed to by the workers who constantly complain about the current poor practices? This is true whether we're discussing XP or Agile or SCRUM.

We can use rational thought to decipher the mystery, attempting to achieve clarity. However much success is possible in finding rational explanations, there comes a time when we must recognize the difference between clarity and understanding. We can state things extremely clearly and succinctly and still fail to understand why people continue their unproductive habits or why change is viewed by those in charge with such disdain.

Submitted here for your edification, The 48 Laws of Power.

Why does that developer refuse to pair with someone? There are lots of reasons, i.e. Law #1 - Never Outshine the Master or law #30 - Make your Accomplishments Seem Effortless, are good places to start. Why is Continuous Integration scoffed at? See law #11 - Learn to Keep People Dependent on You

The words 'politics' or 'management' may seem like pejoratives but they serve as simple placeholders for the understanding of human behavior. At their worst, they can be weapons in a Machiavellian conflict while at their best they can be the protective shield against those who see your efforts as a challenge to their plans. Is every use of these laws an instance of plotting and scheming? No, never forget that human nature operates below the level of conscious thought; these behaviors are ancient artifacts used for thousands of years to survive in a violent and irrational world. Disagree with them all you'd like but ignoring them can easily cost you your job.

Realistic Irrationality

When faced with management's abdication of responsibility for their own decisions, the pragmatic developer will be faced with a decision: to live in the manager's fantasy world, which may involve constantly beating their head against a brick wall or looking for greener pastures, full of craftsmen wanting to deliver software on-time, that works, and is maintainable. This must be closely related to the management style which is unable to prioritize. The hallmark of this occurs during the negotiation desperation of a late project; trying to reign in project scope and attempting to decide which features to cut from the current iteration. When the question is, 'Which features are the highest priority? ' an answer of 'They're all top priority' is not only suspect but probably irrational. The trade offs between better, faster, cheaper are not to be trifled with; this article at softwarereality.com has a good take on the subject. If only this was a tall tale meant to scare young developers; sadly I've experienced this one myself. Feel free to send me your 'Irrational Management' stories, they make good telling at those Agile 'standups' like ghost stories around the campfire...

http://thedailywtf.com/Articles/Deploy!--Deploy!-Deploy!.aspx

In My Estimation

There I was at my first real programming job and my team lead comes by and drops a bomb. "How long will it take to make the change?", he asks. I hope I kept the panic from my face. "Wait a minute!", I was thinking, "Did I miss the class on estimation in college?" No, I didn't. They didn't have one. Hmmm, what do I tell my boss, "sorry, can't help you!", "I have no idea", or even better "they didn't teach that in school"? If I close my eyes and pull a number out of my estimation orifice I could look like a ill-trained idiot programmer by guessing too high or try to please by low-balling it which could easily backfire. Why did I want to be a programmer again, someone remind me. It surely wasn't to look incompetent to a guy that hasn't coded in over 20 years.

Why is estimation still so hard and what are we doing about it?

Chapter 3 - How Can We Study Programming?

This is a continuation of the review of Gerald M. Weinberg's book, The Psychology of Computer Programming. The review begins here for Chapter 1 - Reading Programs. The post on Chapter 2 can be found here.

What chance have we to understand the human factor? How do you study programming when the important majority of it takes place between one's ears?

Perhaps programming is too complex a behavior to be studied and must remain largely a mysterious process.

INTROSPECTION

Although some modern students of human behavior tend to discredit it as nonscientific, introspection has always been the first foundation stone of their science.

The author tells a story about a student having difficulty with a particular PL/I programming problem:

ANGLES(I)=2*ATAND(SQRT((S-A(IND(I,1)))*(S-A(IND(I,2))))/(S*(S-A(IND(I,3))))));

When it was finished the author asked the student to recall the thought processes -- the difficulties -- he had experienced with this statement, here is that list.

1. He had trouble getting the parentheses matched, because there were so many of them.
2. The original ANGLES(i) was a structure, not an arry, so the compiler complained of an illegal subscript list, but he had not been able to find the problem because there were so many subscript lists.
3. When the program finally got into execution, there were these further difficulties:
1. IND was a matrix on another page of the listing, and he had trouble finding it.
2. Even though the parentheses were now matched, one pair was in the wrong place and was most difficult to find.
3. The last difficulty turned out to be a problem of precision caused by capricious declaration of different data types, by the large expression, and by the division--which would not have been necessary if the two-argument form of ATAND had been used.

The student provided a number of insights, from the proper size of statements, the choice of data structures, to the design of compiler and execution-time diagnostics.

None of these insights could be obtained without introspection of this sort, yet thousands of programmers [millions now days - ed.] each day have theses same problems and simply grumble that they are having "bugs." Without the introspection, they will simply continue to have "bugs" until, in the end, the bugs will have them.

From this single instance of introspection, we could come up with "Laws of Programming"

1. The mind cannot cope with more than five levels of parentheses.
2. Compiler diagnostics should be more explicit.
3. PL/I precision rules are too complicated to use.

Although each of these statements might turn out to be a "law" in the psychology of programming, writing it on the basis of a single introspective example hardly qualifies it as a law. To be a "law," a principle must be explored so as to set limits to its application, because all laws have limits. Indeed, the limits are Usually more important to know than the laws themselves, and it is only by investigating a multitude of cases that limits can be set. Thus, without introspections, investigation would be sterile, but without investigation, introspection will be of questionable value in application.

OBSERVATION

One way to follow up introspection is by observation of what people actually do, as opposed to what they think they do.

Like the study of parentheses and how many levels of nesting programmers use.

One of the problems with observation, however, is that it tells us what people do do, but not necessarily what they can do.

If your census showed that programmers never nested parentheses more than 5 levels deep, does that mean they are unable to?

A second problem with observation is deciding just what it is we are observing.

All you know about the programmers who limit themselves to 5 levels of parentheses is a simple fact, to know why they don't use 6 or more would of course require introspection on the programmers part. If you were designing a language, would you limit the size of arrays to three dimensions simply because you've never seen anyone use more?

A third problem with observation is the problem of interference of the observer with the subject being observed.

This is called the "Hawthorne Effect". The act of observing workers actually affected their performance, a kind of uncertainty principle.

EXPERIMENT

Here is a very interesting section where the author describes the costs of conducting experiments on programmers using typical experimental psychology methods. How do you collect data without influencing the results. To a degree it is somewhat like the problem of testing the performance of a program. The modifications necessary to observe the programs use of memory or CPU time actually uses memory and CPU time so how can you know your results haven't been skewed?

You could do experiments using programming majors in school but would the results apply to professionals? You could study professionals but that could be prohibitively expensive. The author describes doing an experiment using one-quarter time of nine experienced programmers for three months. The average salary was $14,000 [I'm assuming annually - ed.], add in overhead (workspace, machine time, etc.) came to $20,000 apiece, or $1250 apiece over the course of the study. Add to that the experimenters salaries and so forth and the bill comes to $30,000 for nine subjects. [In 1970 dollars! - ed.] Using the Inflation Calculator ($30,000 in 1970 compared to 2009) this comes out to a cost of $163,254.90. Serious money, just to study programming.

... we must deal with one other problem, which is important because of a seldom-questioned view of programming. That view is that programming is an individual activity, not a social activity.

Not that the individual level is unimportant, but we might start by asking why, if the average programmer spends two-thirds of his time working with other people rather than working alone (yes, it's true!), that 99 percent of the studies have been on individual programmers.

The answer is that it is expensive to study programmers in groups. Plus, you can't put a number of trainees together and call them a 'team'.

Putting a bunch of people to work on the same problem doesn't make them a team--as the sloppy performance in all-star games should teach us.

The neglect of social effects also casts doubt upon all individual studies, since these studies force the individual to separate himself from his normal working environment. In one of our studies, one of the programmers came to me when he had finished coding and asked who could check his work. In his home group, this was standard practice at this point in development, but it was not allowed during the study -- lest it should "invalidate" the results.

Looking back, it seems that forcing programmers to work in isolation is like trying to study the swimming behavior of frogs by cutting off their legs and putting those legs in the water to watch them swim. After all, everyone knows that the frog swims with its legs, so why complicate the experiments with all the rest of the frog?

PSYCHOLOGICAL MEASUREMENT

For the present, most of the work in the psychology of programming is going to have to be "looking for questions."

I conjecture that we will move beyond looking for questions only when we start believing and acting on the questions that we've found over the almost 40 years since this book was published. This is definitely not a programming problem. When the software managers are able to dictate practices based on a whim or the local political winds, "We don't have time to do code reviews! Why can't you just make it work? I don't understand why it's constantly breaking!", you might start looking for answers in the abnormal psychology section of the library.

USING BEHAVIORAL SCIENCE DATA

Because of the nature of programming, there is not much hope that actual results can be transferred directly from other fields to ours. Our use of results has to be for insights, not for answers.

So maybe all those comparisons with engineering and construction are invalid on the face of it. We might look at Paul Graham's book Hackers and Painters for insight.

Finally, as we pass successfully through all this, we may find ourselves in a sufficiently objective frame of mind to examine some of the myths of programming -- the articles of programming faith. Faith, as Bertrand Russell pointed out, is the belief in something for which there is no evidence; and myths, as Ambrose Bierce once defined them, are the sacred beliefs of other people. Perhaps we shall simply carry away our old beliefs unchanged, but if just one unfounded programming myth should die as a result, this book will have been worth the effort.

SUMMARY

Common pitfalls:

1. Using introspection without validation.
2. Use of observation on an overly narrow base.
3. Observing the wrong variables, or failing to observe the right ones.
4. Interfering with the observed phenomenon.
5. Generating too much data and not enough information.
6. Overly constraining experiments.
7. Depending excessively on trainees as subjects.
8. Failing to study group effects and group behaviour.
9. Measuring what is simple to measure.
10. Using unjustified precision.

1. 
   

Several of these items have had some attention paid to them over the last decade. Extreme Programming was one of the first movements focused on groups of developers to get enough traction to garner a following. There are several similar movements, SCRUM, Agile, etc. Instead of assuming the problem was in the process that humans were following, they finally addressed the human factor as a first-order success factor (thanks to Alistair Cockburn)

The question is, when will we learn that we are the problem?


This ends Part 1 - Programming as Human Performance. Next up is Part 2 Chapter 4 - Programming as a Social Activity

Does Anyone Know What Testing Is?

(With apologies to Chicago for the title) I'm a big fan of good design which should be no surprise to those who know me. It can irritate my wife when I analyze a building and then start describing all the different ways in which you can tell it was poorly designed. I do rant when I see great design but those are much more rare in these "I don't care if it's a half-baked piece of crap, we need it ready now!" times. I apologize for any management flashbacks that caused.

In any event, I'm also a big fan of testing. I see testing scenarios around me during the day. This story just happens to be one that is easy to tell. The mens room where I work has three sinks, each with a soap dispenser. There was one sink that more heavily used than the others based on the fact that there was never any soap in the dispenser. You'd push on the plunger a couple of times and when nothing came out you'd shrug and move to another sink. I always figured that it was running out quickly since I would see the buildings cleaning crew in the bathroom a couple times a week. Surely they were refilling the dispensers right? After a few weeks of the "soapless sink shuffle" I mentioned the problem to the cleaning guy. I got his attention and showed him how no soap came out. He looked confused and said something to the effect of "it should work because it has plenty of soap". As I looked under the counter where he was examining the half-full bottle of soap it was clear that lack of soap wasn't the problem. I left him to his work, figuring that maybe the tube from the plunger was disconnected; plus, he didn't need me looking over his shoulder.

Upon reflection, I realized that his 'test' for being out of soap was looking under the counter to see if any of the containers were empty. Our 'test' for being out of soap was trying to get soap from the dispenser. So even though his test passed, it still was failing the end user because he wasn't verifying the expected result; the assumption being that the only reason you wouldn't get soap was if the container was empty.

The bottom line is to always be aware of what your tests are testing. Just because you're tests all pass does not guarantee everything is working as long as you aren't testing the way the system/device is used in real life. So, when you look at your test plan ask yourself, am I checking that we are out of soap, or am I checking whether I can get soap out of the dispenser? It might seem like a small difference but it can be difference between a cleanly running system and one that leaves you all wet.

The Management Delusion

A good friend of mine sent me this:

Subject: New Stroustrup quote

"The companies are complaining because they are hurting. They can't
produce quality products as cheaply, as reliably, and as quickly as they
would like. They correctly see a shortage of good developers as a part
of the problem. What they generally don't see is that inserting a good
developer into a culture designed to constrain semi-skilled programmers
from doing harm is pointless because the rules/culture will constrain
the new developer from doing anything significantly new and better."

Those companies are in a bed of their own making. They want software written on a schedule which means hiring warm bodies who have the minimum training, enough to run a compiler, and can crank out code on a consistent basis; consistently low quality and in a consistently long time. When the pain of low quality software finally registers through their management-induced fog, they look for answers. What keeps these "Leaders" from admitting their own contribution to the problem?

Leadership sometimes means making hard choices, almost guaranteed to make someone unhappy. Leadership sometimes means suspending self-doubt to enable making those hard choices without the burden of guilt. Consider car company executives contemplating closing a factory - let all the employees down through bankruptcy or let a smaller set of employees down through a layoff? The best example of this would be President Truman's decision to use the A-bomb on Japan. Good luck trying get them to second-guess themselves - to do so would mean letting self-doubt out of the tiny box in which they hide it. Now, for the leader of the free world, we can understand why self-doubt is a luxury they can't afford.

What about the corporate world? Well, the upper-level executives may catch a break when they have to make truly gut-wrenching decisions like the car company example above. Middle and line-level managers do not have those reasons to hide behind so what's their story? Even without earth-shattering, bet-the-company decisions to make, a manager faces the same dilemma, how to isolate their own sense of self-worth from being damaged by potentially bad decisions. One way of doing this is by never looking back, never re-examining prior decisions, not entertaining the idea that they made a bad choice which is, by the way, popular with leaders at any level.

This may keep them from being paralyzed with self-doubt or wracked with guilt but is also makes them oblivious to their own short-comings. It takes a strong leader to learn from their mistakes, to emerge from self-examination stronger because they own up to their mistakes and learn from them.

Here then is the key. Allow me to extend the quote to the next logical step. Companies that are complaining about the lack of good developers are in a state of denial. What they are really complaining about is how few good developers want to work for them. There can be many reasons from an environment that accepts mediocrity to the unwillingness to pay the good ones what they're worth. In the first case it could be the red-tape just to get their development workstation setup, "What do you mean I have to get each Eclipse plugin on the approved software list!?!?" In the second case it could be failing to attract good talent; after all its only fair for a programmer that is 10x better than average to get paid 10x the average, right? Describing your workplace as "We have reasonable development policies and reasonably good salaries" you should not be surprised that you have reasonably talented programmers. To deny this is effectively admitting to self-delusion.

So, when your boss complains about the lack of good developers, they are really trying to deny their own reality and shift the blame away from themselves.

This reminds me of a story about 10 hiring managers who all insist they hire only the top 10% but I'll save that for next time.

Process Paranoia

Is your manager part of the problem or the solution and how can you tell?

Allow me to tell a story.

You are a developer on a large project that involves a large portion of the IT department not to mention multiple external stakeholders and has lots of moving parts and many upstream project dependencies. There are a large cadre of contractors working on a bug-list that keeps growing. The test environment is so complex that features can't be tested outside of certain windows due to the difficulties in getting all the moving parts built and installed correctly (no disrespect here, I mean it's that complex of a beast). The powers-that-be freeze check-ins to the development environment to reduce the number of moving parts during a weekly (yes, not daily) build/package/deploy to test. We won't get into the easy ways to handle this like tagging or snapshots, the management, which includes the technical leads, of the project have been working extra hours for weeks and don't have mental bandwidth to discuss theories. The large influx of developers who are supposed to help fix bugs only further tax the original developers with requests to help setup dev environments, understand the database, or request additional access to various resources.

This is not new, Brooks wrote about it decades ago so why am I writing about it now? With a project like the one that I've described, change management becomes a key tool in maintaining sanity and enabling success. By predefining a process and a set of criteria by which change requests will be evaluated, management has the power to be in control of the project schedule. One such example would be "Once the project has begun User Acceptance Testing, no more change requests will be accepted without approval by the CIO." The level of approval needed would of course vary by the priority of the project. There can be many such rules so that the threshold for permitting a change request rises as the project gets further into the development cycle.

If 'Analysis Paralysis' is the tendancy to continue to analyze past the point of diminishing returns, 'Process Paranoia' is the tendancy to reject efforts to define processes from a misguided attempt to forstall Analysis Paralysis. How is this connected to my tale of development woe? One of the upstream projects wants to provide a function for their customers which otherwise would require said customer to log into a second system to perform a query and then use the results in the upstream system. Normally this type of integration is commendable and encouraged. Why not now? When the managers allow change requests to be considered on an ad-hoc basis, it becomes highly probable that some request will trigger a fire drill of effort in order to evaluate the feasibility or ramifications when that decision should have been simply a matter of saying "According to our change management process, no change requests are accepted even for evaluation once we enter the testing phase without CIO approval." End of story. To do otherwise is almost guaranteeing that a project that was chugging down the tracks will eventually become a large trainwreck waiting to happen.

So the question is, does your management believe/understand/support proper change management processes or just pay them lip service? The answer to this last question goes a long way to answering the initial question of this post.

The Tale of Two Managers

Is the company you work for serious about software development? How can you tell whether your manager is susceptible to the "Death March" management style you ask? Let's discuss a negative case and go from there.

I have a new definition of 'Chaos Theory'. Those who don't understand how to develop software will never free themselves from the chaos caused by operating in constant crisis mode.

Have you ever worked for a boss who liked to give direction and expected their group to start running around doing anything because action == progress regardless of direction? Did we do stuff we didn't need to? So what, at least we're doing _something_. is their mantra. Imagine what would happen if we let modern skyscrapers be built this way. The financial backers would revolt because they'd have to write the check for all the re-work; the engineering team would go AWOL because their carefully evaluated design wasn't being followed; the workers would go on strike because of the unsafe work environment caused by the activity-for-activities-sake. If your manager never wants to discuss process (current or future) they might be trying to manage the chaos by dictating constant activity. My theory is those managers feel like they are having to flail like the dickens just to keep their heads above water because they don't want their team to know just how out of control they feel.
Let's call this manager "Suzy Spur" for her penchant for 'spurring' her team to action; her idea of effective management is making sure her cattle-prod has freshly charged batteries.

Now, let's switch gears to a large development project that has it's head on straight. While Eclipse is also a tool that Java developers use to create applications, it also has sprouted a mature project management template for coordinating large-scale (in number of apps involved) software releases.

The Eclipse organization has created a process that is rational, consistent, and repeatable. By thinking through the process beforehand, they do not have to make things up as they go. They release on-time and with high-quality even if that means leaving features behind. Here is a quote from the site

Ganymede is about improving the productivity of the developers working on top of Eclipse frameworks by providing a more transparent and predictable development cycle; Ganymede is about developers helping developers serve the whole Eclipse community

When the executives are clamoring for results, what they really are asking for is predictability. They want to know when they can plan on the next version of their application will be ready for release so they can plan their trip to Jackson Hole (for those without spouses) or Orlando (for those with families). What they don't want is a make-it-up-as-you-go process, of which Suzy Spur is so fond, that will send them to Las Vegas in August with no AC.

In comes "Craig Calm". He acts deliberately, instead of by reflex. He surveys the road ahead and lays out a route which will get him to his destination with a minimum of fuss instead of bouncing over each hill unable to see over the next rise. He prepares the project foundation so the flurry of change means asking different interior designers for their ideas on the finishing touches instead of tearing out walls because they were put up before the wiring and pumbing were installed. He is respected because his team can plan time off because his projects are always on-time or any delays are expiditiously relayed to the proper governance group; instead of reviled due to the ever-cracking whip and constantly worrying about being fired right before a family vacation because the project is always behind the eight ball -- the deadline never moving regardless of the increased workload.

When a deadline doesn't move even though the work increases, that is a classic sign of inadequate risk management. If you (project) manager is not insane, a sliding schedules would be a simple result of project math: Workload divided by resources = timeline. Of course I'm over simplifying but let me use an analogy here. You are in charge of building a dam and one of the project assumptions is the area will get no more rain than the largest amount in the last 100 years. If halfway through the site gets deluged with twice the 100-year-record amount, you do not go to your team, at the waterlogged site, and say "Guys, just work harder" or my favorite "Work Smarter". What the sane project manager does is go to the sponser and say, "We didn't plan on this, we're going to have to start over." It is not the fault of the team or of the project plan when the sponser approved the assumptions and then came up short. The book "Waltzing With Bears" is a fantastic resource on the subject of proper risk management and how it can restore sanity to your project.

So, for whom would you rather work? The insane activity-for-its-own-sake pile-driver or the methodical, consisent, and goes-home-by-five software development veteran?