The new economy is just like the old economy

“Those who do not learn from history are doomed to repeat it.” – George Santayana, Philosopher

Not long ago everyone was talking about the new economy and the news media had several stories about the “new economy.”   It turns out the new economy is just like the old economy, and the ole economic laws still apply.

The software industry is experiencing a lot of growing pains experienced by other industries.   Since the first computer language appeared in the 1950s there has been a churn, of both hardware and software.  Hardware companies like Wang, Control Data, and Digital have come and gone and were replaced by Microsoft, Dell and Apple.   Software languages have come and gone, too.   Assembler, Fortran[1], and COBOL have been replaced with Java,  Java Script, and C++.  Long before there was Word, there was WordStar and WordPerfect; and, before Excel there was VisiCalc and Lotus. Whatever happened to Lotus 1-2-3?

History Just Repeats Itself

Mark Twain once quipped, “History may not repeat itself, but it does rhyme a lot.”  These days, software development rhymes a lot with other industries.   I hear from software developers that the software industry is unique, and no other industry has experienced the same type of growth that software development has experienced.   If we look back in history, then we understand that several other industries have experienced rapid growth rates similar to the software industry.  The growth curves for the railroads, telegraph, telephones, textiles, and the auto industry all have the same shape.  There is rapid growth, the industry peaks, and employment falls off.  Some industries, like the telegraph, just disappeared.

I am not suggesting that the software industry is exactly like every other industry because there are similarities and differences.  What I am suggesting is that by looking at other industries, we can get an understanding of the future of the software industry.   What I am suggesting is that the software industry does rhyme a lot with other industries.

 

---

[1] While I started out in Assembler, I was always fond of Fortran.  Fortran first appears as a useful programming language in 1966 and received major upgrades by 1977.  Believe it or not there was a new release of Fortran in 2003 and another release planned for 2008.

 

Ideas on Productivity

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

http://www.productivity501.com

What is the average cost to develop software — It depends

I get asked the question, “What is the average cost of develop software?” all the time.  The answer it depends.

1.  When people ask the average what they are asking is what is the average unit cost of software.  This is a similar question to what is the average cost per square foot of construction.  I use function points, so the question becomes what is the average cost per function point to develop software.    The average dollars per function point is one way to determine the average dollars per unit of software developed.

2. The average cost per unit of software developed depends on several factors.

2a.  The type of business the software supports.  The unit cost of software is going to be different for insurance industry and the aerospace industry.  The same is true with construction.  The average cost per square foot  to build a mission control building for NASA is not going to be the same as the cost per square foot to build an insurance office building.

2b.  Location, Location, Location.  Like real estate the cost per unit of software is going to depend on where it is built.  If the software is built with cheap labor (the main input), then the cost will be less.  Of course it depends if the cheap labor is of equal productivity.  If the cheap labor is half the cost and half as good, then you really do not gain anything from using cheap labor.

2c. Duration.  The duration impacts cost too.  Not only development costs but maintenance costs.  If the the software has to be developed as soon as possible it is going to be expensive per unit.

Actually there are about 50 other factors that impact cost, but these are three big ones.

Read more at Reboot! Rethinking and Restarting Software Development.

What we have here is a failure to communicate

Why do bureaucracies emerge in organizations and often overwhelm it?

The real question in my mind is, “What is the root cause for an organizations to have too much bureaucracy?”  It is not like organizations or more correctly individuals within organizations wake up proclaiming we need more bureaucracy.   People do not say, “We need to burden teams with status reporting, forms, procedures until we reach a point in time where everything comes to a screeching halt.”

The idea of small autonomous teams that are unhampered by bureaucracy is not new.   During the 1990’s there was a software methodology called Rapid Application Development (RAD) and today the buzz is Agile. This idea of limiting bureaucracy is not limited to software development.  Going all the way back to the 1940’s there were teams called “Skunkworks” at Lockheed Martin.   The point being idea of self directed teams is not unique to software development and not a new idea.

Some of the clues for burdensome processes come from the word bureaucracy itself.  The term bureaucracy came into use shortly before the French Revolution of 1789, and from there rapidly spread to other countries. The Greek suffix – kratia or kratos – means “power” or “rule”. Does it turn out that bureaucracies are the result of power and rule?

My experience tells me it is not that simple. The root cause for bureaucracies is the result of poor communication.  The cause of bureaucratic burdensome processes is the result of a failure to communicate.   An organization can eliminate burdensome processes, but it does not resolve the problem of communication.  If root causes are not addressed, then problems will never be resolved.

The bottom line is  bureaucracies emerge because of poor communication.  Go though the two links below and look at the recoomendations.  We will begin to notic the opposite is done in software development.  As an example, it is recommended to avoid jargon.  How often is that done in software development.

99 Ways to Improve Communication http://www.getinfrontblogging.com/communication/99-ways-to-improve-your-communication/

Improving Communication Skills http://achievesuccessforlife.com/41/improving-communication-skills/

Sources

http://en.wikipedia.org/wiki/Skunk_Works

http://en.wikipedia.org/wiki/Rapid_application_development

http://en.wikipedia.org/wiki/Bureaucracy

Cooking and Communication

This past weekend I tried a new recipe that turned out brilliant. I can’t take too much credit because I followed a recipe provided by America’s Test Kitchen. There are a lot of analogies between cooking and developing software. Not all recipes are created equal and some are better written than others. The same is true of documentation. The point of cookbooks and cooking shows is to communicate a process to another person. This is also the reason behind documentation. In other words, documentation is an attempt to communicate a process to another person.

I like America’s Test Kitchen because it provides videos with detail explanations of the science of cooking and written recipes. Not only do they provide a detail explanation of how to prepare the dish in both written and video formats, they also explain the science of cooking. On the other extreme is learning to cook by trial and error. Learning to develop software by trial and error seems to be the norm rather than the exception in software development.

Many of us learned to cook from our grandmothers by verbal instruction. My grandma left off steps or failed to emphasis a specific point (she would tell you that I was not paying attention). If grandma was in a hurry she was terse in her explanations. This is the same problem when verbally explaining how a software process should work. Experts often leave off important steps or fail to emphasis a specific point. They often blame the user for failing to understand too.  Another excuse is not having time to communicate and this can be overcome too.

Complex system requires better communication

The whold idea of communication is a process.  The more complex a dish becomes the more complex the explanations need to be. The same is true with software because the more complex the product the more detail and clear the communication needs to be.

Application communication can take on many forms including written documentation (recipes), verbal communication, and even video explanations. Cooking is a repeatable process It turns out that cooking is just a repeatable process and there are a lot of ingredients that go into making a great dish or dessert. The better the communication of the process the easy it is to follow, understand and repeat. The better the understanding a person has of the cooking process (and especially of the cooking science) the easier it is to create a something new. The same is true with software development. The better the communication the easier it is for others to understand. The more one understands about the science of software the easier it is to create something new and different.

America’s Test Kitchen http://www.americastestkitchen.com/corp/about-americastestkitchen.asp

13 Ways to Improve Communication with your clients
http://designm.ag/freelance/communication-with-clients/

14 Quick and Effective Communication Tips for the Time-Challenged

http://www.sitepoint.com/blogs/2009/10/12/quick-communication-tips/

Methodologies and Fad de Jour

According to a recent study Agile is growing in popularity and not long ago the Capability Maturity Model (CMM) was the fad de jour. CMM was based upon sound scientific methods with plenty of data to support its case and Agile is based upon anecdotal evidence. It is not like there are small tweaks of ideas because the difference between CMM and Agile are tremendous.

What is it with software development that causes it to flirt with methodologies as often as weight loss methods? It is like the industry is floundering. It seems that some of the major consulting firms and experts in the field were proponents of CMM not long ago singing the praises of Agile. There seems to be an effort to support and to promote what is popular instead of what is right.

I believe the clue lies in why so many individuals experiment with weightless methods. Consumer Reports declared Weightwatchers the best success weight loss program, but its success rate is low. It is estimated that 95% of those using Weightwatchers eventually return to their old weight. It turns out people (especially Americans) do not have disciplined eating and exercise habits. It is so easy for us Americans to be overweight, to sit in front of the TV, or to spend countless hours surfing the internet. Our portions at restaurants are supersized and there is often an endless supply of snacks at work.
We could excuse the ebb and flow of methodologies on fact the field of software development is in its infancy stages, but I am not sure that is a good idea. In reality, those software companies that are the most disciplined have the highest rates of productivity and quality. This is true of world class athletes and musicians as well. It is especially true of world class golfers. A logical question is what does discipline look like in software development?

What makes software unique from other industries and disciplines is it is so easy to be undisciplined in our methods. It is easy to change a line of code compared to changing a physical structure or a building. The rhetorical question becomes if physical structures of a building could be changed as easily as software can be changed, then would architectural firms adopt the methods of software development?
I have studied hundreds of organizations around the globe as part of a merger or acquisition. It turns out those that are the most disciplined with repeatable processes are the most successful. It is critical to note that being disciplined does not guarantee success. It seems the missing ingredient is customer knowledge. The formula becomes those organizations with discipline and those that study the customer are the ones with world class performance levels.

Yet the unanswered question remains.  What are the reason so many software development organizations flirt with so many methodologies?

http://www.googobits.com/articles/625-the-skinny-on-fad-diets-what-really-works-what-definitively-doesnt.html

http://www.RebootRethink.Com

http://www.internetnews.com/dev-news/article.php/3841571

http://blog.nayima.be/category/agile/

http://www.sei.cmu.edu/cmmi/

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

Stone Cold Coder meets Diva Developer!

Cheech and Chong, a 1970’s comic act, portrayed themselves in one of their skits as Siamese twins that were not identical.  They were paternal twins physically connected at the hip.  Of course this was impossible, absurd and a very laughable idea.  Whenever I hear about pair programming I can’t help but think about Cheech and Chong and the absurdity of the idea.    It is like asking two teenagers to share a mobile phone.   It ain’t going to work folks.  It is absurd and laughable.

The idea is that one programmer writes code and the other programmer stands over his or her shoulder and watches for mistakes. When the first programmer gets tired they switch positions.  I think they are suppose to touch hands like professional wrestlers do in a a tag team wrestling match.  How cool would it be to called something like Stone Cold Coder or Diva Developer.  You could go to work dressed in costume.  Instead of programming sessions you could have smack down coding sessions.

You don’t have to implement Agile to try out  the idea of pair programming.  I would suggest  trying pair writing.  Have one person start to type and have another person stand over them and correct them as they go.    This is an awesome idea! I am curious to see how long this process would last.  How about pair cooking?  You have one person cook and another person correct them as they go – nice.  How about pair driving?  You could have one person sit in the backseat and correct the driver.  I think that is called back seat driving.  Sorry pair programming is a joke of an idea and absurd.

——————————————————————————-

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

Reboot! Rethinking and Restarting Software Development.

Agile Methods and Other Fair Tales

If you are having a hard time coming up with a pseudo name for your pair programming team check out the auto Professional Name generator at  wrestles – http://www.wrestlingname.com/

Professional Wrestling –http://www.wwe.com/

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html