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.

To Buy or Not to Buy Technical Books, That is the Question

So the rookie coder is working at his new job, fresh out of college, when the team malcontent is overheard a couple of cubes over, "This place is so cheap! They should reimburse me for this technical book. It's a heckuva lot cheaper then a training class."  However true that is, it hides a simple choice: keep the book and be out the money, or give up the book and pocket the cash - assuming the boss will foot the bill.

Recently a question on Stackoverflow reminded me of that rookie coder. Being fresh out of college gives you an amazing combination of overconfidence and cluelessness.  Without any basis, it's easy to take the office attitude and run with it.  You shouldn't have to buy your tools, your company should.

I disagree.

Why? Because they are tools. It's not even a cost thing. A professional should be responsible for knowing which tools they need to be most productive. Tour an airline maintenance facility and check out the workshop.  A large area, maybe 1000 sq. ft., with nothing but large toolboxes;  each with a name and a lock. The mechanics have to buy all their own tools, think wrench sets and so forth - not large things like engine dollies.

At first it seems a bit silly and redundant but when you start to think about it, it's easy to see that not everyone is going to want to spend the extra money on the high-end tools, or they might want extras of the same set for whatever reason. Also, consider the hassles with sharing, e.g. "Where are the 1/2 inch box-end wrenches?" By not making the tools shared, the 'Tragedy of the commons' is avoided.

Another example is chefs and their knives. You don't touch another chef's knives. The restaurant provides the big things like ovens and stoves, the chefs bring their own knives.

Back in the world of computers, I've brought in extra memory before. I told my manager so he'd know that some of my personal property was in the PC in case it needed to be worked on by the internal techs. I also put a note on the box itself. I would have had a bigger issue if they discouraged bringing your own hardware. Most shops like to provide the box itself because it minimizes their support issues but they shouldn't have any problems with you bringing accessories like monitors, keyboards, mice, etc.

To summarize, change how you think about tools and strive to use whatever makes you better at your job, even if you have to pay for them out of your own pocket. It's the 'Professional" thing to do.

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.

Software as Literature

Alternative title: Sonnets to CPUs

Have you ever noticed that code follows some basic patterns? JUnit uses Setup(), Test(), Teardown().

I’ve playfully mixed writing and coding below.

---

//[Play about A Monarch's Destiny, in three acts]
Public KingdomFuture tellTheTaleOfMyRule(Kingdom landMyFatherLeftMe)
{
   //[1st Act:  Build Drama]
   Vassal mySubjects = SoliloquyAboutMyKingdom.getMyPeasants();
   Boolean mySubjectsLoyalty = testOfLoyalty(mySubject);

   Vassal theCaptainOfTheGuard = SoliloquyAboutMyKingdom.getMyTrustedRightHandMan();
   Boolean myTrustedServantsLoyalty = testOfLoyalty(theCaptainOfTheGuard);

   KingdomFuture historysTaleOfMyRule = KingdomFuture.UNDECIDED;

   //[2nd Act: Drama plays out]
   if ( mySubjectsLoyalty == TRUE 
        && myTrustedServantsLoyalty == TRUE)
   {
       HeapPraiseUpon(theCaptainOfTheGuard);
       historysTaleOfMyRule = ExpandKingdomByForce(mySubjects);
   }
   if ( mySubjectsLoyalty == FALSE 
        && myTrustedServantsLoyalty == FALSE)
   {
       ArrestTraitor(theCaptainOfTheGuard);
       historysTaleOfMyRule = ImposeDispicableLaws(mySubjects);
   }

   //[3rd Act: resolve drama]
   if ( deceptionHiddenSuccessfully(theCaptainOfTheGuard) )
   {
       return oldRulerOverthrown;
   }
   else
   { 
      return historysTaleOfMyRule;
   }
}

What Did You Say?

This says it all. Most of the time research focuses on if new stuff is possible. The real 'Silver Bullet' would be to find a way to solve the communication problem. Click on the image to embiggen.

To Function or Not to Function, That is the Question

Question:
What is the difference between a functional and non-functional requirement?

Answer:
If a requirement uses a verb to describe the feature then it is functional; What will the system *do*? If a requirement uses an adverb or adjective to describe the feature, 'how' will it do whatever, then it is non-functional.

I've almost always been interested in the importance of language in discussing requirements. There are two ways to listen to your customer, literally and figuratively. That the customer has difficulty describing their requirements has been a problem in the software field for so long that it's now a cliche. What some analysts have done in to start reading between the lines to capture what the customer is "really" saying. There can be some benefit to this figurative approach but I would always to to listen to them literally. In many cases this meant inconsistent or confusing descriptions, the key was to realize that those questionable points were just that, points to question. In getting clarification about those requirements, we can get a more detailed understanding of the problem domain. If their choice of words or phrases contradict, ask them about it.

Sometimes we need to listen figuratively or "between the lines" to get the overall picture but listening literally can be indispensable for uncovering the things you need to dig into for more details.