Marginal Cost

Marginal cost is different from Average Cost.  Average cost is total costs divided by total functionality created.  Marginal cost is the cost of adding one more unit of functionality to a software product.

Why is this concept important for software development?

The marginal cost curve looks something like the Nike Swoosh.   Marginal costs rise as software projects get large.  The reason for this is many software organizations do not have the discipline and necessary infrastructure to support large scale software development.   The fewer infrastructures the faster marginal costs will raise. 

In other words if you try to build something that is large and you do not have the skill set to build it the unit costs are going to go up rapidly.  People are going to be standing around looking for stuff to-do.  

Organizations need to find its sweet spot where productivity or unit cost is the lowest.

Average Total Cost of Software Development

As an economist l like terms like Average Total Cost or unit cost. Average total cost is just total costs divided by output (quantity of the software produced). These terms are somewhat alien in the field of software development.

The problem is what a unit in software is and what represents total cost. Total Costs Total cost should include all costs to create and maintain the software product. It would include all requirements gathering, design, and analysis, coding, testing, maintaining and enhancing the software product. Many software organizations only include coding (or development) costs which greatly understate the actual cost of software development.

Labor costs are the most significant ingredient in software costs. Other costs can be training, software, equipment, travel, and entertainment.

Units
The amount of functionality delivered (see www.SoftwareMetrics.Com)

Average Total Costs
The equation is Total Cost divided by Units Produced. In terms of software it is total cost divided by function points (or functionality delivered). The lower the average cost the higher the rate of productivity.

Average Total Cost equals Average Variable Cost plus Average Fixed Costs

Industry Averages Software Productivity

I got an interesting email from a person asking about the variations in software productivity industry averages. I believe the person already knew the answer and was just looking for clarification.

There is no such thing as an industry average cost for software development and there is no such thing as an average industry wide cost for construction either. Since the cost per unit of developing software is so varied, knowing the average cost to develop software is about as useful as knowing the average cost to make something.

1. Productivity varies based upon the size of the project. The larger the project the lower the productivity (higher the unit cost). A project that is 5,000 function points is going to cost more per function point than a 500 function point project. This is true in construction projects too. A sky scrapper is going to cost per square foot (or square meter) to build than a single family dwelling (holding everything else constant). Software development has diseconomies of scale or increasing marginal costs.

2. Software productivity rates vary by type of industry. The software productivity rate for software developed for the health care industry is different than software developed for the banking industry. A medical office is not going to cost the same per square foot (or square meter) as a bank.

3. The way data is gathered will impact software productivity rates. Since I work a lot on mergers and acquisitions, I include everything and everybody not just the IT staff or programming effort. I prefer to use payroll reports and expense payment reports and not just data from time reporting systems. The typical gap between payroll and time reporting systems can be up to 50%. In other words, most software organizations under report its true cost by about 50 percent.

Read more at Reboot! Rethinking and Restarting Software Development

www.RebootRethink.Com

Railroads Industry = Software Industry

I study a lot of things and it turns out the railroad industry is a lot like the software industry.  The software industry is a lot like many other industries.   As an example, the rate of growth for software development is just like the rate of growth for telegraph, telephones, textiles, auto industry and the railroads.  There are some obvious comparisons to the software industry.

• Large growth (in the USA – 34 miles of track in 1830 to 200,000 miles of track in 1900).
• Largest employer during its “hay day.”  Nearly 9 percent of the total workforce in 1900.
• Eventually outsourced work to Asian workers.
• Cheap labor and automation reduced the demand for rail workers.

Once upon a time, the railroad industry was the world’s largest employer; and, like software jobs in the 1990s’, some of the best jobs were with the railroads.  The railroad industry had similar growth to the software industry.   In the 19th century Europe, the UK and the USA had rapid growth in railroads.   In the USA, there were only 34 miles of railroad track in 1830; and 50 years later, in 1880, there were nearly 100,000 miles of railroad track.  Over the next 20 years, from 1880 to 1900, the number of miles of railroad tracked doubled, reaching 200,000 miles.   In only 70 years the railroad industry went from a dead stop to 200,000 miles of railroad track.

Employment was not limited to just laying track; there was large employment in manufacturing the locomotives, passenger cars, and freight cars.   In the UK, workers built 23,000 locomotives, 73,000 passenger cars, and an amazing 1.4 million freight cars in less than 50 years.   This is an amazing feat when considering the tools and technologies that were available.

The building of the railroads and the railcars that ran on the railroad spawned rapid employment growth in the USA and UK.  The railroad industry employed about nine percent of the total workforce of Chicago.  The rapid growth did not last forever.   Railroad employment peaked in the 1920s, declined during the Great Depression, and rose again during World War II.   Starting in the late 1940s the railroads had to compete against other forms of transportation: cars, buses, trucks and airplanes.   Much of the manual labor was replaced by automation. The railroad companies improved their technology, and they started using diesel locomotives, track-laying machines, and other innovations that reduced demand for labor.

Like the software industry, the railroads suffered from a lack of standardization.  There was no standardized track gauge, the distance between the rails, until the 1880s.  The distance between the tracks depended on who operated the rails. This lack of standardization caused a lot of problems for those individuals that wanted to ship freight or move people from one point to the next.  Parts between freight cars were not standardized either.   This is a similar problem faced by the software industry.   There is little industry standardization for software development.  In the software industry, it is common that software applications developed by the same companies do not communicate and share data.

From 1920 to 1995, those employed by railroads had dropped by nearly 90 percent. In the end, it was a combination of foreigner labor, competition and automation that did the railroad workers in.  In the USA, the railroads were built by cheap foreign labor especially by those coming from Asia.  Software developers are facing stiff competition from India and China (Asian labor).

My Lord

This post has nothing to do with software because it is about traveling.  I was traveling in Europe last week and I caught a British Airways (BA) flight at London Heathrow Airport. BA allows you to choose a title when making reservations. In America we can choose a titles, and we can choose Mr; Mrs; Ms; and Dr. BA has a few more including Sir and Lord. I have to admit when I made my reservation I struggled between Lord and Sir. In the end I went with Lord.

I had a hectic day and I had forgotten about my new self proclaimed title. I checked in and provided my confirmation number and the BA ticket agent addressed me as “Lord Longstreet.” A smile came to my face and I thought, “Now that is what I am talking about.”  The ticket agent did not address me as My Grace or My Lord and I was a bit dissapointed.  While I like my self proclaimed  title of Lord, I think I need to upgrade to Duke or Earl. I like the sound of Duke David.

Quality 911

I was channel surfing and came across the show Nanny 911.  The premise of the show is that there are families who cannot control their children, so they call Nanny 911.  The nanny focuses on the behaviors of the parents rather than the behavior of the children.  A nanny trying to control the behavior of children is analogous to putting your hand in a bucket of water in hopes of displacing water.  Your hand displaces the water, but as soon as your hand is removed, the water goes back to its original position.  The same analogy holds true for the quality department.  It is impossible to enforce quality standards within an organization without holding management accountable.

The nanny teaches parents that children need to have boundaries, and children need to understand there are consequences to their behaviors. Generally, the consequence for the children is timeout.  Since there is no adult time out, a manager can’t put an employee in time out; so, other types of consequences must be adopted.

Too often, quality consultants are focused to helping employees implement a process or fine tune existing processes.    They need to be working and consulting with senior management so management understands they have a role in implementing quality programs.

The bottom line, folks can work, talk, train, cajole, sell, and communicate process until blue in the face; but if management does not enforce the desired process, then the process is not going to happen.  By enforce, I mean there have to be consequences to following the process and for not following the process.  A consequence does include loss of job.  Many successful managers I have worked with do fire people for not following the process, and they also reward those who do follow the process.

When the only tool you have is coding…

Abraham Maslow  once quipped,  ”If you only have a hammer, you tend to see every problem as a nail.”  If the only tool you have is coding then you tend to see every problem as a programming problem.

Great Software Design Ideas from 1844

The following quote is very applicable  to software development in 2010 even though it was written nearly two centuries ago.

“Great design gives no more than its purpose requires; its artistic resources are the very simplest; its arrangement and relationships are the most natural and comprehensible; it is far removed from all ambition, all splendor, and all overburdening.  It is not rich and does not deceive; but it is certain, virtuously true, and intimate.  It proceeds in a strong, straight line to its goal; and a certain childlike sincerity is evident throughout. “   – German Encyclopedia 1844.

http://www.idsa.org/

http://www.bitrebels.com/design/wow-genius-way-to-describe-great-design/

http://joelongstreet.com/

Reboot! Rethinking and Restarting Software Development

Why do most diets not work? What does this have to do with software development?

Why do most diets not work and what does this have to do with software development? It turns out that diets don’t fail, but people fail to stick with the diet. The secret to losing weight is a pretty simple concept and hard to do. The secret, of course, is to eat less food, drink less booze, and exercise. The bottom line is if you burn more calories than you take in you will lose weight.

Most software process improvements don’t actually fail. People fail to stick with the process improvement just like most people fail to stick with a diet. When you think about it a diet is a process improvement plan too.

To stick with any process improvement takes a tremendous amount of discipline. It takes discipline to lose weight and it takes discipline to develop good software too. This little snack here or there adds up to a few extra pounds just like this little short cut here and there adds up crappie software.

Telephones and Telegraph

Telegraph

In the 1950s Western Union, the first ecommerce company, was at the top of its game.  It dominated telecommunications but failed to adapt and enter into the voice telephone systems.   Employment in the telegraph industry soared in the late 1800s, but by the early 1960s, the telegraph was on its way out. It is hard to believe but the telegraph lasted until about 1991. In the end, the telegraph died of a slow death. Perhaps it died at the same rate as those who grew up with the telegraph and refused to change.

There are always those who refuse to adapt. Just like those who continue to use DOS or FORTRAN, or COBOL, there are those who continued to use the telegraph-even when better options were available.

Telephones

The first commercial telephones started appearing in the early 1880s and by 1902, there were 2 million telephones landlines with 54,000 employed in the telephone industry. Like software development, there was a rapid growth period that was unheard of before. Twenty years later, in 1922, there were 13 million telephones and 210,000  salaried employees.   Over seventy percent of those employed by telephone companies were operators.    It was better tools, techniques, and automation that replaced the telephone operator.

Employment in the telephone industry grew until it peaked in 1979 with slightly more than 1 million employees.  Since 1979, the number of people employed by landline telephone companies had fallen to about 300,000 in 2006.  Today, everyone understands cell phones will replace landlines, and I am sure there are some who will hold onto their landlines until they die.

The common thread in all these industries is a belief that the growth is going to last forever.  I am not sure where we are on the growth curve for software development, but I do know the industry will peak and then rapidly decline.   The software industry will continue to change rapidly and automate impacting those employed in the industry .