Developer Insights – Stories & Analogies

Gaining Insight into Software Development by looking around

Weakest Dancer

I was recently chatting with a choreographer friend. He shared that, for a recent production, he was forced to dumb down the choreography to match the capability of some of the cast. I joked that a chorus line was only as strong as the weakest dancer. He agreed.

So how does this relate to software development?

  • Are your development teams restricted in the language and language constructs that they can use so that every team member is able to modify all the code?
  • Do you allow only certain people to modify certain “crown jewels” code?
  • Do you have code written in languages that only some members of the team understand?
  • When you interview potential members of the team, how do you assess their ability to contribute at the required level?
  • If you are writing a library that will be broadly used throughout your company, how do make sure that the broad base of users will be able to use it effectively? What checks do you put into place?
  • Do you use any form of “certification” to increase the odds of appropriate use?
  • Do you require every development team to have a resident expert on the technology? For example, do you require every development team have a member trained in writing secure code?

Written by amckale

June 2, 2010 at 1:12 am

Posted in Uncategorized

Scenery, Costumes, and Props – Build, Reuse, Borrow, Rent, or Buy

leave a comment »

Every theater production has scenery, costumes and props. Some are simple and easy to obtain, some are unusual but not tied to a specific show, and some are unique. Scenery and props are selected (or created) by a scenic designer or a prop designer; costumes by a costume designer.

In the end for each piece, a decision must be made….are you going to build, reuse, borrow, rent, or buy?

In an ideal world there would be complete freedom with all the talent, money, and time you need and you could build everything custom to create a totally one of a kind experience. Unfortunately, you, like the rest of us, live in the real world and are limited to choosing some fraction of the props and costumes that you will be able to build uniquely for a production. In general, that will be those things you can’t get otherwise, those that you want to be simply fabulous such as the costumes for the leads, and those things that people feel passionate about and have talent for. If you have someone who loves to make fancy hats, your production of Hello Dolly will have wonderful hats when the actors put on their Sunday clothes. If you have someone who is a wizard with mechanical devices, you will have fancy elevators and memorable special effects. If you have someone who likes to play with fire, keep a fire extinguisher handy. Note that when you are building yourself, you may want to design with reuse and lending in mind.

Most theater companies who have been in business for a couple of years have a warehouse full of props and costumes from previous productions. Sometimes there is a catalog of what exists. Sometimes there is not. Sometimes there is institutional memory of what might exist or where a certain prop that was previously used came from. If you can find it and it meets your current needs, you can re-use it.

If you are not in a one-playhouse town, there are other theaters that may have put on the show, or a similar one, from which you can borrow, rent, or buy. If you are a borrower, it is generally good form to also be a lender. Informal sharing can lead to interesting experiences and late night panic calls. “Help, we are putting on a production of Arcadia and someone ran over oursleepy tortoise. Do you have one we can borrow?” If you are in a larger metropolitan area, there may be mailing lists that can tapped. For example, in the Bay Area the list of choice is bayareatheatrebums. Just recently there was a posting there for Schoolhouse Rock Live! sets. For a mere $125 you could have your own Conjunction Junction Set or Capital Building Set, and $500 would get you the main School House Rock Set.

And then there are theatrical rental and sales outfits that can provide you with one stop shopping for all your needs for a particular show. These can be very helpful when a unique prop is required.

Examples of unique props tied to a particular show are the Magical Rose in Beauty and the Beast, the Ford Model T in Ragtime, and the plant puppet in Little Shop of Horrors.

In making the decisions concerning whether to re-use, build, borrow, rent, or buy there are generally a few strong considerations:

  • Do you have the technical talent to build what you need?
  • Do you have the time to build what you need?
  • Do you have the budget to build what you need?

Secondary considerations can include:

  • If you borrow, can you modify sufficiently to meet your needs? One local theater nearly did not do a production of Little Shop of Horrors because the plant that was locally available was too tall to fit in the theater.
  • If you reuse, is the audience going to be tired of seeing the same old costumes once again?
  • If you buy, will there be hard feelings and resentment of those who would want to build?
  • Who actually gets to make the decision and how are they going to do so? What are the criteria?
  • How will you build your internal talent and expertise if you always go outside?


So how does this relate to software development?

  • Joel Spolsky wrote a column back in 2001, In Defense of Not-Invented-Here Syndrome. In the column he uses the example of Microsoft’s Excel team and their “Find the dependencies — and eliminate them.” philosophy.
    Do you agree with his arguments?
  • Have you ever been involved in a project where you made a decision to reuse, buy, borrow or build?
    • In hindsight, was the decision the right one?
    • What criteria were used to make the decision?
    • In hindsight, were the criteria the right ones?
    • Were the promised criteria delivered?
    • Were risks and contingency plans taken into account?
    • Were there risks that were not identified that happened?
    • Did you do a pilot project?
    • In making the decision did you involve possible vendors to see what they could deliver, promise, and change?
    • Was the decision a purely technical one or were business considerations involved?
  • Have you ever tried to find code to reuse, borrow, or buy?
    • Were you able to find something that met your needs?
    • Where did you look?
  • The biggest sources of reuse are in operating systems services and language frameworks/libraries.
    • What OSs and frameworks have you used?
    • How does one learn about the capabilities of a particular OS or framework/libraries?
    • How does the use of frameworks speed or impede innovation?
    • What development model is used to develop frameworks and libraries? Is it via a standards process, an open source process, or a vendor specific?
    • How is backwards and forward compatibility managed?
    • Do you trust OSs and frameworks more than code obtained from a friend?
    • Have you ever discovered a defect in an OS or a framework? Did you report it?
  • If you are writing code or a library that you know will be used by others, what do you do differently? Why?
  • If you are writing code that you know will be used and seen, what do you do differently? Why?
  • Do you agree with these statements by Donald Knuth in “Coders at Work“?

    The problem is that coding isn’t fun if all you can do is call things out of a library, if you can’t write the library yourself. If the job of coding is just to be finding the right combination of parameters that does fairly obvious things, then who’d want to go into that as a career.

    There’s this overemphasis on reusable software where you never get to open up the box and see what’s inside the box. It’s nice to have these black boxes but, almost always, if you can look inside the box you can improve it and make it work better once you know what’s inside the box. Instead people make these closed wrapper around everything and present the closure to the programmers of the work, and the programmers of the world aren’t allowed to diddle with that. All they’re able to do is assemble the parts. And so you remember that when you call this subroutine you put x0, y0, x1, y1 but when you call this subroutine it’s x0, x1, y0, y1. You get that right and that’s your job.

  • Do you agree with these statements by Joe Armstrong (creator of the computer language Erlang) also in “Coders At Work“?

    The thing that really hasn’t worked is software reuse. It’s appallingly bad.

    I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Written by amckale

May 3, 2010 at 7:20 pm

Posted in Uncategorized

Physical Constraints – Intermissions – Batteries and Bladders

leave a comment »

One of the most obvious physical constraints in the theater is the amount of time that the audience can endure without a break. A recent production of “The Weir” at the San Jose Rep, ran 2 hours without an intermission, likewise Sondheim’s Assassins. Of course, both are significantly shorter than the 2 hours, 45 minutes running time of the opera “Das Rheingold” which is also performed without intermission. In each case, a special effort was made to inform the audience in advance so that they can plan accordingly.

Intermissions serve multiple purposes:

  • the performers and the audience get a break
    • to use the restrooms
    • to eat
    • to drink
    • to wake up from a nice nap
    • to check in with the babysitter
    • to check in with the office
    • to check on the sports event that they would rather be attending
    • to smoke
    • to see and be seen
    • to mingle and network
  • the set can be significantly changed. Two good examples of this are the sets for The Producers and for Noises Off.
  • more significant costume changes can be done
  • the audience can chat and digest what they have seen so far
  • special donors may recieve special attention in a special intermission reception
  • latecomers who could not be seated in their assigned seats may now be properly seated
  • audience members who have gotten lost or confused can get caught up
  • the audience can shop and buy their souvenirs whether it as simple as a poster or T-shirt or as exotic as a Plush Bag with Chihuahua from Legally Blonde – The Musical
  • the theater can ply their show merchandising
  • the theater can promote their upcoming shows
  • the theater can promote their subscriptions

But intermissions have downsides:

  • they may be prohibited by the copyright owner
  • the time for “the actual performance” may be reduced. Union agreements require that no performance shall last longer than a certain number of hours inclusive of the Actor’s designated call and intermissions.
  • the momentum and “mood” of the performance is stalled and needs to be rebuilt
  • the audience may leave
  • the audience will forget things
  • herding the audience back into the theater can be time consuming, a ten minute intermission can turn into 20 minutes
  • some patrons will sneak into better seats that were not occupied [cf. Fair or Foul, 2000 Randy Cohen, ethicist, NYT]
  • some patrons will attempt to climb on to the stage or move parts of the set


So how does this relate to software development?

  • One of the most important constraint in the mobile space whether laptops or phones is battery life. A short battery life can turn into an unexpected intermission in the middle of a task.
    • What is the user experience of your application if your user runs out of battery?
    • How accurate are the estimations of time remaining?
    • For your user scenarios, do you have an expected amount of time required for each task?
    • Do you warn people that you estimate that they will not be able to complete a task given existing battery life remaining?
    • Do you use prior experience of user to refine these messages?
    • As the market for your product changes, do you revisit these assumptions?
  • Some applications lock certain resources while the user is executing a transaction. For example, a ticketing application will lock your seat selection while you go through the checkout process.
    • If you don’t complete the transaction within the given window, the transaction is canceled and you have to start over.
    • How do you decide how much time to allow the user?
    • How do you indicate the amount of time left to the user?
    • Do you lie to customer and actually give them more time than you say?
    • Do you let the customer pause the transaction if no one else is making a transaction?
  • If the task the user is performing may be quite long, do you provide intermissions, natural stopping points, so that they can stop and return at a known good spot? Consider the example of using tax software.

Written by amckale

April 11, 2010 at 3:51 am

Posted in Uncategorized

Sondheim’s Birthday – Composers, Constraints and Creation

with one comment

Yesterday was Stephen Sondheim‘s 80th birthday. Last fall I was able to catch him in Stephen Sondheim: A Life in the Theater in Santa Rosa. He’s got a large collection of anecdotes, polished through repetition, but still interesting. For some of the audience, most of the stories were new. But even the Sondheim faithful learned new things. One item that struck me was his comment about writing for a specific performer and that performer’s strengths and weaknesses. I came home and found the story in an online interview.

Stephen Sondheim Interview — Academy of Achievement

Stephen Sondheim: What happens is, when you’re out of town or… yeah, out of town is what it amounts to — although that one was written during rehearsals — you know your cast well and you know their strengths and weaknesses, and you can start writing for them. Just the way Shakespeare wrote for his actors. And I’ve said it with heavy humor, that I really don’t want to write a score until the whole show is cast and staged, because… that’s why so many good songs get written out of town, and written fast, because you know exactly what’s missing, you know exactly what has to work or happen, you know exactly who you’re writing for, you know exactly what the audience is starting to feel. And so the more restrictions you have, the easier anything is to write, and when you’re out of town and you’re restricted by all those factors, it’s much easier to write them than when you just have a tabula rasa and say, “Gee, we’ve got to have a love song here.” You know, it’s not the same thing.

Q: You said “Send In The Clowns” was written during rehearsal, can you tell us how that came about?

Stephen Sondheim: We hired Glynis Johns to play the lead, though she had a nice little silvery voice. But I’d put all the vocal weight of the show on the other characters because we needed somebody who was glamorous, charming and could play light comedy, and pretty, and to find that in combination with a good voice is very unlikely, but she had all the right qualities and a nice little voice. So I didn’t write much for her and I didn’t write anything in the second act. And the big scene between her and her ex-lover, I had started on a song for him because it’s his scene, and Hal Prince, who directed it, said he thought that the second act needed a song for her. And this was the scene to do it in. And so he directed the scene in such a way that even though the dramatic thrust comes from the man’s monologue, and she just sits there and reacts, he directed it so you could feel the weight going to her reaction rather than his action. And I went down and saw it and it seemed very clear what was needed, and so that made it very easy to write. And then I wrote it for her voice, because she couldn’t sustain notes. Wasn’t that kind of singing voice. So I knew I had to write things in short phrases, and that led to questions, and so again, I wouldn’t have written a song so quickly if I hadn’t known the actress.


So how does this relate to software development?

  • Does “the more restrictions you have, the easier anything is to write.” apply to writing software?
  • Compare the constraints and capabilities provided by a software platform, hardware, OS, tools, SDKs, with the constraints and capabilities of a theatre and a cast.
  • Compare writing a show for high school students to writing a show for Broadway. Compare writing software for your family to use to writing software that will be deployed globally across a variety of platforms, current and future?
  • Is it easier to make incremental improvements and adjustments to an existing product or to start from scratch?
  • Sondheim talks about the situation where the writer is bringing a huge amount of knowledge and talent to the situation. What about the situation where you don’t have that knowledge, where you are brought in to be a firefighter?

Written by amckale

March 24, 2010 at 12:37 am

Posted in Uncategorized

Story Poles – Paper Prototypes

leave a comment »

Over the years, I have occasionally seen a mesh of orange. I didn’t know what they were or who put them up. They reminded me of the art of Christo and Jeanne-Claude. Eventually I learned that they were used to indicate the elevations and silhouettes of a proposed building or an addition to an existing building. In Cupertino they are required when someone wants to add a second story to a house. As part of the Design Review process, the story poles must be constructed on the site. The actual poles are wood, metal or plastic frames with orange mesh. Story poles serve as a noticing tool and as a visualization tool. They generally cost between $1,500 and $3,000. Story poles are sometimes known as Ridge poles.


So how does this relate to software development?

  1. How do story poles compare to the standard UI design tools and methods?
  2. In designing a prototype of a system it is relatively quick and easy to try a number of different scenarios, whereas with story poles, the cost of trying a different can be prohibitive. What are the implications of that difference? Would software design be different if it was very expensive to test? Would construction be easier if the hassle of story poles was reduced?
  3. The webbing is specified to be orange.  Why?
  4. At HP, we had a very strong release to release compatibility guarantee. Obsoleting something was very hard. What processes and policies does your group use to change your product in such a way that customers are not surprised.
  5. Does the available architecture software support story poles?

Written by amckale

February 21, 2010 at 6:22 am

Posted in Uncategorized

Would you eat here again?

with one comment

Last week, a group of friends were going to get together for lunch.  The restaurant, chosen before I was invited, happens to be one where I saw some insect life on my last visit.  So I declined to join them.  I didn’t bother to provide my reasons nor did I suggest another place.

Now this last visit was about 10 years ago.  You might suggest that there should be a statute of limitations for these sort of things and that I am being totally unreasonable.  I would agree with you.

But then what is the formula for calculating the time?  Does it matter if it was a single critter or multiple?  Are mammals different than insects?  Does the ownership of the restaurant matter?  Does the cuisine matter?  How about the restaurant next door?  How about other establishments in the same chain? Does it matter if it occurred during your first visit to the establishment or if you had been a long time patron?  Does it make a difference if it occurred before you had ordered the food or as you were paying the bill? Would it matter if you were there alone or if you were there on a date?  How about if it occurred on a special and memorable occasion, say Mom’s 50th birthday?  And where were the health inspectors?  Did you report the sighting to the waiter? To the health department?

Given the alternatives, I am willing and able to go elsewhere.


So how does this relate to software development?

  1. How would you feel about discovering a bug in the development tools that you use?  Would it be more worrisome if it was the compiler or if it was the debugger?  How about in the third party libraries that you are using?
  2. Are bugs encountered during installation more worrisome than bugs encountered during an uninstallation process?
  3. Does a defect in one piece of software influence your opinion of the likelihood of a defect in another piece of software with similar functionality, say a defect in one compiler is likely to appear in another compiler?  a piece of software from the same company?
  4. Do you know what software uses the same underlying code?
  5. Do you know what code was written by the same people?
  6. Do you know what code  was written with the same processes?
  7. Do your customers have different reactions to defects?
  8. Do you expect software to have certain “defect density”?  If testing uncovers an abnormally large number of defects, do you congratulate the testing organization?
  9. Do you report defects to other engineers? to other teams? to other organizations? to other companies?
  10. Do you believe customers report all the defects that they encounter in using your software?

Written by amckale

January 24, 2010 at 5:27 am

Posted in Uncategorized

Doctors and Tech Support

leave a comment »

Back on Nov. 13, 2007 I read “How Doctors Think” by Jerome Groopman. In it, Groopman explains the thinking that can result in medical mistakes. I was struck by the similarities between his doctors and anyone who has to deal with defects in software.

Among the issues he presents are confirmation bias, availability bias, the uncertainty of the expert, the affability or obnoxiousness of the patient, the importance of gatekeepers, prototypes of conditions  or disorders, anchoring, and diagnosis momentum.

Groopman concludes the book with an epilogue that lays out a number of questions that patients can use to help their doctors avoid mistakes.  Rather than reproducing them here, I have recast them in software terms.

  • Ask “What else could it be?”, combating satisfaction of search bias and leading the engineer to consider a broader range of possibilities.
  • Ask “Is there anything that doesn’t fit?”, combating confirmation bias and again leading the engineer to think broadly.
  • Ask “Is it possible there is more than one defect?”, because multiple simultaneous defects do exist and frequently cause confusing symptoms.
  • Tell what you are most worried about, opening discussion and leading either to reassurance (if the worry is unlikely) or careful analysis (if the worry is plausible).
  • Retell the story from the beginning. Details that were omitted in the initial telling may be recalled, or different wording or the different context may make clues more salient. (This is most appropriate when the defect has not been located or there is another reason to believe that a misdiagnosis is possible.)

So how does this relate to software development?

1)  If you have a series of defects that appear to be duplicates do you make sure your fix will actually fix all the defects that were reported?

2) Do you have customers that you hate to hear from?  Do you ever discredit a defect report because of who submitted it?

3) When a defect comes in from the support organization, do you try to start fresh in R&D and not accept support’s diagnosis?


References:
NPR Interview

How Doctors Think

BusinessWeek Review

Jerome Groopman’s Web site

Written by amckale

January 4, 2010 at 3:47 am

Posted in Uncategorized

Follow

Get every new post delivered to your Inbox.