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.

XSLT - The Modern Day Snake Oil

Technology seems to attract all kinds, no surprise these days when everybody and their dog are high-tech consumers. But those of us who earn their living in that fast-paced world every day can't help but get a bit jaded seeing the same mistakes repeated time and time again.  From the desperate or possibly Machiavellian managers who want to ignore common sense and decades of history and continually chase the proverbial silver bullet, to the greedy vendors selling the latest 'enterprisey' tool with promises which sound more like a late-nite comedy skit, "Not only is it a floor wax, it's a tasty dessert topping!".  In software it is, "Without writing a single line of code". Why do people fall for these pitches? You can blame ignorance, malice, or greed; in any event, it is up to each of us to keep our wits about us when evaluting claims for the latest-and-greatest doohickey the next salesdroid offers.

There is one phrase that I've seen many times over the last twenty years and whenever I hear it, I immediately think of snake oil.  Whenever you hear a consultant say anything to the effect of, "easy to use by non-programmers!", smile and quickly look for the exit.  How trite is it? Well, early in my college days I remember hearing stories from the early mainframe days when assemblers were first coming out, "It works so well you won't need programmers anymore!"  At my first job at a large company, the 4GL vendors would use the same line on the managers, distracting their mark from the large price tag with promises of savings from lower staffing.  The reality was nobody but programmers could figure out how to actually use the immense packages, assuming they could get them installed correctly in time to use on a project. Even modern tools like Requisite Pro fall, which I really liked, prey to this. They are supposed to improve productivity but the learning curve is so large that the only way to properly use it on a large project is to have someone who already knows it configure it for you.

Recently I ran accross the claim in an old book, "Professional Java XML Programming with Servlets and JSP" by Alexander Nakhimovsky and Tom Myers published in 1999 (page 526 to be exact) which attempts to summarize the ream of paper constituting the previous chapters.  In a section appropriately but belatedly (considering where it appears) titled "What's XSLT for?" the authors explain,

We are rapidly approaching the summary and conclusions to this final chapter of the book In the meantime, the main conclusion about XSLT that we hope you will draw from this chapter is this: XSLT is best described as a general-purpose mini-language, intended to make many common operations on XML documents easy to express and accessible to non-programmers.

Is the book old and out-dated? Of course. The age of the book only matters though if the authors would express a different attitude given a chance to update their book. Granted, right after the offending paragraph they attach some conditions,

Allows non-programmers to do some transformations:
- without tools, only simple things
- with tools, more complex things

When I read the above, I couldn't help thinking, "Have you guys _looked_ at what you've written lately? If it takes a book 500 pages long to explain it, you're never going to get non-programmers to use it"  Why is programming hard, I don't know and do not want to venture a guess.  What I do know is when competent programmers who are at least trained - if not adept - at imperative object-oriented languages face a significant learning curve when working with a declarative language like SQL much less a functional one like Erlang.  XSLT is like a combination of web templates with an embeded declarative language which also include functional aspects, although the authers probably disagree saying, "As of today [1999], JSP is a tool for a prgrammer while XSLT is a tool for a Competent User who is NOT a programmer."

Am I trying to call out XSLT or XML? No, they are useful tools (like automatically formatting your log4j config file) and at this point we couldn't get rid of them if we tried. The issue is quite old and better men than myself have already weighed in.  What I do want is for people who should know better, like said authors, to refrain from propagating the myth that if only we had better tools or languages, non-programmers would rush in to join the computerized fun.
...