Scaling Music and Software

I am working on a lecture for my economics class about production theory.  Production theory works nicely for software development, music and    information workers too.

Output is the result of labor and capital.  The amount of music produced is the result of musicians (labor) and instruments (capital).    As more and more musicians are added to the process of making music the process of making music becomes more formal and there are overhead costs.

If we start with one musician playing a piano, then there is not much overhead required.  Add  three musicians and you get a quartet and there is some communication that needs to take place.  Add about 96 more musicians and you get an orchestra.

The cost per output (the average product) begins to rise because you have overhead costs.  If you have about 100 or so musicians you need a conductor.   Sheet music is required too (formal documentation not necessarily required for a small group).  We see the marginal cost, the cost to produce additional music, begins to rise.  The reason are additional labor is required that does not produce music directly.

This same model works for software development too.  Output for software is the amount of functionality produced.  As the project scales upward formal processes are just required.   There project resources (labor) required such as a project manager.  Formal methods and documentation is required to help in communication.

So there you have it…. Production theory works for information workers.

The End of Vaporware?

Software companies are being held accountable for problems in its software projects, misrepresenting what a software product does and being deceitful project timelines. A British judge also said the Red Sky software development company should have better understood the requirements of its customer. An earlier court ruling found that EDS misrepresented project timelines and was what its software product actually did. It sounds like the end of vaporware.

Red Sky sold hotel management software to London’s Kingsway Hall Hotel but the Hotel found problems with the software immediately. Kingsway Hall complained and called customer service and got customer no service instead. The software company knew of problems with its software and failed to disclose those problems because it wanted Kingsway to buy its software. It is simple as that. The question remains should a software company disclose known issues to its customers. It turns out British courts are saying yes. Red Sky should have told its customer of problems with the product when demonstrating it and chosen more demonstrations for it that more closely matched the customer’s own business requirements, the Court ruled.

Does any other industry believe or think they should not be held accountable for product flaws that may cause its customers harm or injury. Red Sky tried to rely on a clause in its standard terms and conditions which said that the only remedy available to customers if the software did not perform as advertised was to make use of its maintenance and support functions (a.k.a. call customer service).

Clause meant that Kingsway could not sue it for a refund on the software or for the additional costs it incurred as a result of its failings. The High Court disagreed and said that Red Sky’s clause was unfair under the Unfair Contract Terms Act. It said that this Act applied and protected Kingsway because negotiations between the companies had been one-sided on the issue of liability. His Honor Judge Toulmin also said that the software was not up to the tasks that Kingsway needed to use it for, and which Red Sky should have known were part of Kingsway’s needs when buying the product.

This decision is on the heels of an earlier decision. The High Court ruled that EDS had lied about its software when selling it to BSkyB and awarded interim damages of £270m (about $400 millions) against the software supplier – ouch! The court also agreed that EDS had been deceitful in pursuing the contract, finding that the information technology company had deliberately misrepresented how long it would take to complete the job. BSkyB Wins Legal Victory Against EDS – Court rules software liability clause not ‘reasonable’

Ideas on Productivity

I stumbled upon a very good blog related to productivity and I thought I would share it.

Published in: on October 30, 2009 at 09:11  Leave a Comment  
Tags: ,

Drinking from the Fire Hose of Information!

Drinking from the Fire Hose of Information or five things to do to improve status reporting.

When providing status of a problem it is important to provide the right level of detail, so the situation can be easily digested. A lot of technical team members provide status and it is like trying to get a drink of water from a fire hose. They tend to provide so much technical information the person on the receiving end is totally drenched in information, but thirsty for status.

 The objective is not that everyone understands the technical nuts and bolts of the problem; rather, the objective is to gain confidence the problem is being handled appropriately. Status should include items like:

1. Who are the customers impacted?
2. Have the customers been notified?
3. Have the customers been shown evidence the problem has been resolved?
4. What caused the problem?
5. What steps have been taken to make sure the problem does not reoccur?

Read more at Reboot! Rethinking and Restarting Software Development

Gorillas and I.T. – Go to the jungle

Tom Kelly is an Industrial Designer for one of the most successful industrial design firms, IDEO. He writes in his book The Art of Innovation, “Your customers may lack the vocabulary to explain what’s wrong and especially what is missing.” Bingo! One has to start to ask the question, “If your customer does not know what he or she wants or cannot articulate what is wanted, then how exactly should the requirements process work?” Kelley writes, “It is common for well-meaning clients to duly inform us what a new product needs to do. They already ‘know’ how people use their products.” His firm does not rely on customers telling them about their problems. His book is full of stories recounting where customers were wrong about problems and possible solutions. His firm has learned to study customers and not rely on what they say. Kelley’s views are not unique, and his views are shared by many other industrial designers. Now if Kelley is right, and customers cannot articulate what they want, and especially what is missing, then how should the requirements process work?

Too often software development teams ask customers what do you want.  The problem is customers cannot articulate what they want.   Customers are unable to describe their own requirements.   The whole idea of gathering requirements is just wrong.

Gorillas and I.T.
Jane Goodall studied and learned about gorillas by studying them. She learned a lot from just observing and sometimes being among the gorillas. She utilized a technique known as ethnological study.  The best insights come from observation, interviews and informal conversations.

If you want to learn about your customer, then you need to go to the jungle.

The bottom line is software developers can learn a lot from industrial designers and other researchers.

Read more at Reboot! Rethinking and Restarting Software Development.

Jane Goodall Institute

The first management consultant – More Ancient Wisdom

Jethro the First Management Consultant – More Ancient Wisdom For Software Developers

Exodus the first book in the Old Testament was written around 1,450 BC or nearly 3,500 years ago. This is the first known reference to management and specifically to management consulting. This ancient wisdom is useful for managing software development.

According to Exodus, Moses was handling all the complaints and concerns of the Jewish people. As it is described in Exodus Moses spent all day sitting and listening to all the issues and concerns of the Jewish people. The Jewish people had to wait in line for hours to speak to Moses. Moses tried to resolve all the complaints and issues between the Jewish people himself. He was micromanaging.

Moses’ Father In Law Jethro saw this and offered Moses some advice. Jethro basically told Moses you are doing this all wrong. Jethro explained to Moses, “you will surely wear yourself out and not just yourself but the people. The task is too heavy for you; you cannot do it along.”

There are many reasons why we do not like to delegate. Ken Siegel, PhD, a psychologist who consults to managers says, “It’s probably one of the most significant management hurdles. To delegate you have to admit that someone is going to accomplish this at least as well as you, if not better, and most of us don’t like to acknowledge that.”

Delegating frees you up to do more important things like planning for the future.

Jethro was telling Moses to delegate some of his responsibility to others. Delegation would help Moses and the people. Jethro told Moses, “look among all the people for able and God-fearing men, trustworthy men who hate dishonest gain and set them as officers over groups of thousands, of hundreds, of fifties, and of tens.” The span of management control is only about 10 people and that has not changed much in the past three thousands of years.

Project management is not a new idea it seems to be a new idea for software development

Read more at the free online book Reboot!  Rethinking and Restarting Software Development.  (www.RebootRethink.Com)

Typical Software Estimation

Me, “What is the biggest software project that you have ever worked on?”

Typical response, “20,000 hours!”

Me, “Wait.  I did not ask how long it took, I asked how big.

Typical response, “$2 million dollars.”

Me, “Is my question vague did you not understand me.  I asked how big.”

Typical response, “What?”

Me, “How big?”

Typical response, “What?”

Me, “Okay, we are not getting anywhere.  Let me try another approach.  How big is your house?”

Typical response, “2,000 square feet.”

Me, “Good. You understand the question.  You just gave me a unit of measure of size.  So what is the biggest software project that you have worked on?”

Typical response, “20,000 hours.”

Me, “We seem to be back at square one.  Let me try another approach, how much was your house and how long did it take to build?”

Typical response, “$250,000 dollars and about 6 months.”

Me, “$250,000 dollars is a cost measure and 6 months is a time measure.  Get it.”

Typical response, “I think so?”

Let’s try again, “What is the biggest software project that you have worked on?”

Typical response, “About 42 people worked on the project?”

Me, “I feel like I am getting nowhere because I did not ask how many people worked on the project. I am not asking how many people, how many hours or how much it cost, I am asking how big.”

Typical response, “I don’t know.”

Me, “The past is the best indicator of the future.  Your estimates needs to be based upon past performance.”

Typical Response, “Wow, that is deep.  How do I proceed.”

Me, “It is not that hard.  Determine the average size  and average cost of a few past software projects in function points.  This gives you historical dollars per function points.  If you determine the number of function points for a new project, then you can easily determine the cost.”  The cost is number of function points for your new project x historical cost per function point equals total cost.

Typical response, “I don’t have time to do all that because I need to start coding.”

Me, “Typical.”

What Software Component Gets Built First?

Abbott: Well Costello, the CIO has given me a promotion, project manager of our new software application.

Costello: If you’re the project manager, you must know the order of how the software application will be built?

Abbott: I certainly do. Well, let’s see, the order we plan on building software components is, What’s is first…

Costello: That’s what I want to find out.

Abbott: I said, What gets built first, Who gets built second, I Don’t Know’s gets built last.

Costello: Are you the project manager?

Abbott: Yes.

Costello: And you don’t know the order of how things are going to get built.

Abbott: I do.

Costello: Well then what gets built first?

Abbott: Yes.

Costello: I mean the components name.

Abbott: What.

Costello: The component that gets built first.


Abbott: What.

Costello: The first component.

Abbott: What.

Costello: The first component.

Abbott: What is built first!!

Costello: I’m asking what is built first.

Abbott: What

Costello: What’s the component’s name?

Abbott: Yes.

Costello: Well go ahead and tell me what get’s built first.

Abbott: That’s it.

Costello: That’s what?

Abbott: Yes.


Costello: Look, you gotta build something first, then second, then third?

Abbott: Certainly.

Costello: What’s built first?

Abbott: That’s right.

Costello: When you record your time, what component gets charged?

Abbott: Yes

Costello: All I’m trying to find out is the component built first.

Abbott: What


Costello: Let me try something different, you have three components, what component get’s built last?

Abbott: No, what gets built first.

Costello: Ok, finish this sentence the last component built is…?

Abbott: I don’t know.

Costello: I don’t know.

Abbott: Yes?

Costello: What?

Abbott: No what get’s built first.


Costello: You know I just don’t give a darn.

Abbott: That is the name of our methodology.

Costello: What’s the name of your methodology?

Abbott: No, what’s built first?

Costello: Your methodology is….

Abbott: I don’t give a darn.

Costello: Neither do I.

Published in: on March 1, 2009 at 14:22  Comments (2)  
Tags: , ,

Flying by the seat of your pants?

When a person states that  big software projects (over 5,000 function points) are risky or not possible, I think about Charles Lindbergh’s historic solo flight across the Atlantic Ocean.

In the early days of aviation pilots had few navigation aids.  Pilots relied upon their judgment more than anything else.   Often pilots would fly with a map between his legs and this become known as flying by the seat of your pants.    Long flights over the Atlantic or Pacific oceans were difficult and some thought impossible.   While some aviators like Charles Lindberg were successful, other aviators like Amelia Earhart were lost at sea. In 1927 when Lindberg crossed the Atlantic solo he only had a compass to guide him.  The next year there would be thirty attempts to match Lindbergh’s historic achievement and twenty pilots lost their lives.  The failure rate of pilots crossing the Atlantic was around seventy percent.   Ironically, 70% is the crash rate of large software projects too.  The point I want to make is the success of Lindbergh was due to his heroic abilities. Too many software projects rely on heroic abilities instead of clear navigational guides.

The reasons pilots could not fly long distances was not because it was impossible.  It was due to the fact that there were not adequate measurements and navigational aids in place.  The field of aviation has evolved and now there is a world of measurements.  Pilots have the aid of radar, satellites and air traffic controllers to assist them.    Pilots flying solo across the Atlantic is relatively common today.   As a testament to this Marion R. Hart made seven solo flights across the Atlantic, the last when she was 83 years old. 

If a software organization is getting ready to embark on a large project they need to bring in project managers that have experience implementing large software projects!  They need managers with knowledge of how to implement projects with navigational devices.   Theses managers need to know how to implement the necessary navigational aids to make sure the project stays on plan; otherwise, the project is destined to crash!


Charles Lindberg (
Marion Hart (
Function Points (http://www.SoftwareMetrics.Com)

Published in: on February 23, 2009 at 12:57  Leave a Comment  
Tags: ,