Developer Insights – Stories & Analogies

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.