Just Google it! Huh?

There is a misconception it is okay to have documentation scattered about individual computers and a “shared drive.”  The myth is documentation can be found via searches and it does not need to be organized.  Some organizations want to implement a Google style search mechanism.  The beauty of the Google search engine is it seems so simple.  Google relies on creators of websites linking information together and some relatively complex algorithms.  The founders of Google wrote a paper entitled, The Anatomy of a Large Scale Hypertextual Web Search Engine outlining how the Google search engine would work.   It is not as simple as it looks.  Most organizations with disorganized documentation cannot get their developers to use consistent terminology nor can they get them to embed hyperlinks in a document.

If a specific document is referenced by many other documents, then the document is significant.  If the document is not be referenced via some linking mechanism, then there is no way to determine its significance. The problem, of course, is getting individuals to link documents together.   Believe it or not I have had developers argue this point.   Even though they have never read the short paper or long paper written by Brin and Page the founders of Google they just somehow know all the inter-workings of Google.  They think it would be easier to design a complex search engine with artificial intelligence not yet invented by mankind instead of standardizing terminology and using some sort of naming convention for their documents.

Read more at Reboot! Rethinking and Restarting Software Development.


Measure what is not measurable

It does not matter what is trying to be done, if it can’t be measured, it  can’t be understood , controlled, or predicted.  If it can’t measured it  can’t moved forward.  If the software development process can’t be measured it can’t be understand it.  Measurement has been the basis of all science since the time of Galileo.   The idea of measurement is nothing new; it is only new to the field of software.  If the software development process is not measured it cannot be studied, it cannot be understood, and it is difficult for the organization to move forward. Measurement is one of the most ordinary actions.  We speak its language whenever we exchange goods or information.

Better A Surgeon’s Notes on Performance is a recent book written by Atul Gawande.   The book is an investigation into how medical professionals can progress from good to great.    Many of the lessons outlined in the book apply to everyone including software developers.  Gawande recommends, “Count something. Regardless of what one ultimately does in medicine or outside of medicine – one should be a scientist in this world.”    This applies to software developers too.  To be considered a scientist, something needs to be counted and measured.   It is common for software developers to refer to themselves as a computer scientists or software engineers.  Both of these titles imply utilization of the scientific method, systematic study, and measurement.

Knowing something
The most common and accepted way to know something is through systematic study and utilizing the scientific method.  Another way to know something is through personal experiences.  Through all experiences, each individual constructs a “reality” of the world.  The danger arises when this method is the only method since biases develop or information can be distorted. Often, the events experienced represent a biased sample that in turn can lead to inaccurate conclusions.   Most biased individuals do not see themselves as biased, and often they defend their opinions with a lot of passion. Basically, the scientific method is a set of assumptions and rules about collecting and evaluating data.  The idea is to reduce bias as much as possible, and the proof of the science is the data. “Stripped of fall its glamour, scientific inquiry is nothing more than a way of limiting false conclusions.”

The real conflict in software  is between systematic study and personal opinion.  There are a number of software professionals who rely on personal experience and hold the misconception that systematic study and measurement of the software development process is not possible or not necessary.  Some believe that measuring the software development process is just too complex.

One reason why software professionals do not measure is because they do not have the necessary basic quantitative and qualitative skills.  They do not know how to study a software environment.  Many of them studied computer science where there was an emphasis on learning programming languages instead of learning about the software development process. The emphasis has been on writing code and not on the idea of developing software to solve customer problems.   Since the emphasis has been on programming, it is hard for a programmer to explain how he or she knows what they know.  There is also limited knowledge and experience of what goes on before  code is written and what happens after it has been written.  The reason for this is because there is little interaction with the actual customer or the person who uses the products.  Many developers do not have the desire to know the customers either.

Read more at Reboot! Rethinking and Restarting Software Development

Bah, Humbug! A look at IT Past, IT Present and IT Future

Everyone knows the story of the Christmas Carol.  Charles Dickens examines Christmas past, Christmas future, and Christmas present. As perhaps the worlds only Software Economist, I examine IT past, IT present and IT future in this short article.  Like Dickens, I have endeavored in this Ghostly little article, to raise the Ghost of an idea.

  1. IT past.
  2. IT present.
  3. IT future.

All industries have cyclical ups and downs.  There is no reason to believe that the software development industry (IT) will not follow the same up and down cycles like other industries and the overall economy.  When the economy rebounds will so IT.

The more I study, learn and experience software development, the more I am convinced that software development is just like every other industry.   What a Ghostly idea!

The Current State of IT
What has happened in the field of software has happened before and has happened in a lot of other industries too.  The recession in IT is worldwide problem and not isolated to the United States or Western Europe.  An Australian friend who does IT consulting in Southeast Asia wrote, “The few consulting jobs I had planned in 2009 in Malaysia, Singapore, and Vietnam are gone or on hold for the time being.”  Another friend living in Europe wrote, “these are tough economic times and it is a bad time to be looking for a job.”   More than half of IT employees and contractors in the UK express dissatisfaction with their career path.

It seems like there are comments on all the Linkedin groups about the economic woes of IT.

According to a recent CIO survey CIO’s are continuing to put discretionary IT projects on hold, renegotiating IT vendor contracts, and freezing IT hiring.   Nearly 64% of the CIO’s reported they were freezing IT hiring and nearly 43% planned on reducing head count.

Before we get depressed here are some basic economic principles:

1. All industries have cyclical ups and downs. There is no reason to believe that software will not follow the same up and down cycles like other industries.  For those of us with a bit of gray hair we remember the slump in oil industry in the 1970’s and look at the profits of the oil industry today.

2. Recessions are like forest fires because they clear out a lot of the dead and unnecessary wood. Investment in IT needs to be re-examined and carefully scrutinized.   Too much investment was based upon “latest” and “greatest” technology and not on sound cost/benefit analysis.

3. When the economy rebounds so will IT. IT is following the same cyclical pattern as the overall economy.

The unemployment rate for the software development industry rose over the last year.  Overall the unemployment rate for software development rose from 2 percent to 4 percent or it just about doubled.  According to the Bureau of Labor Statistics (bls.gov) during the past year the

– Software Engineers unemployment rate rose 1.9 percent to 4.1 percent

– System Analysts unemployment rate rose 3 percent to 5.7 percent

– Computer and Information Systems Managers unemployment rate rose 2.7 percent to 4 percent

This is just about the same level of unemployment for college educated individuals.  While the overall unemployment rate is just around 9.5 percent,  the unemployment rate for those with a bachelor degree is around 4.8 percent.   The rise in unemployment in the software industry is following the same trend as overall employment too.  The unemployment rate for individuals with a bachelors degree or higher went from 2.4 to  4.8 percent during the same period of time.

IT Past
Not too long ago, there were companies testifying in front of congress saying there was as shortage of IT workers and they need more H1B visas.  During the early 1990’s many proclaimed that the IT industry was recession proof.   Some experts proclaimed there would be a shortage of IT workers by the year 2010.   IT turns out these experts were wrong.   It seems that IT is following the same economic trend as the overall economy.  I feel like I am repeating myself.

Many in the IT industry were fat and happy and did not continue to improve skill sets or learn about the business.  It seems like few in IT actually study the core business.

IT Future
The software industry will return and be healthy again.   Will the software industry be exactly the same as before?  No, this much we know for sure.  It will emerge and become healthy again, but the shape and especially the location is not known for sure.

Those individuals that take the time during a recession to sharpen skills and increase their skill sets will prosper.   There will be many individuals that will leave the software development industry for good and look for career options elsewhere.  This same thing happened in the late 1970’s with the oil industry.

This is the time to polish skills and sharpen your tools.  The internet provides an avenue for individuals to self study without outlaying any cash.  The library offers a lot of online resources and current technology books too.

Specific Trends

Continuation of Offshore Development
Clearly a lot of IT jobs are being exported and this trend will continue. Other industries like textiles moved completely offshore and the design and marketing jobs remained in the USA.    It appears the same is going to be true of software development.

The number of graduates in computer science continues to plummet.  The number of those choosing to major in computer science has fallen about 50% since 1999. BUT the number of PhD’s getting computer science degrees continues to grow.  The percentage of non residents (international students) getting PhD’s in Computer Science rose from 20% in 1985 to nearly 80% in 2008.  Most of these doctoral students are from Asia.   These PhD’s return to their home countries and teach computer science.  This means the instructors for off shore developers are being trained at schools in the US.

The next round of off shore developers will be better trained than the first round of developers.  It will be increasingly difficult for US and western European developers to compete on skills and on price.

As industries mature they specialize.  Software development is still an immature industry.   There are a variety of industries that have been around for a few centuries like  engineering, medicine, law, architecture and textiles and they all have specialists along an industry line.

In the early nineteenth century a skilled seamstress performed all the roles necessary to make a dress. All dress making was customized. The industry matured until several specialists performed all the roles once performed by the seamstress. Designing, planning, and marketing became a specialization too.  There are some designers who specialize in men’s clothing and others that specialize in just designing wedding dresses. This trend is already starting to happen in software development.

Less Technical Skills and More Business Skills
The long term trend is away from technical skills and towards business and design skills.  When the only tool was a needle and thread it took a lot of skill to sew something.  With the invention of the sewing machine, less skill was required of the seamstress. Clothes were first worn for very functional purposes and new we use them for both a functional and design purpose. The same was true with software development and especially with developing websites.    The first software programs were for functional purposes only and now design does matter.  Not long ago it took a strong understanding of html to develop a website but as tools improved the necessary technical skills diminished.  (a nice graph here).

While the number of computer science degrees have plummeted the number of degrees in human factors design continues to grow.  This is going to be a driving force toward understanding the business and understanding the user.

I have a heard a couple of themes from software developers for a number of years.  The first is software development is somehow different from all other industries.  No one can really give me a reason beyond “just because it is different.”  As things shape up it appears that software development is just like every other industry.

The second thing and more to the point here is I have heard from many software developers they are better than their counterparts in India, China or eastern Europe.  When I push and keep asking the question, “What are you better at?” They answer, “I am better at requirements, design and knowing the business.”  This is true!   Americans and western Europeans need to focus on what they are better at and move away from technical skills because there is no long term future in it.

The number of developers in Asia and eastern Europe continues to grow.  They are becoming better educated too.  It is going to be harder and harder for an American or western European to compete on skill and especially on price.

Published in: on July 8, 2009 at 09:33  Comments (2)  
Tags: ,

A pint between friends!

Measure what is measurable, and make measurable what is not so.– Galileo Galilei (1564 – 1642)

I hope my British friends do not take offense to this, but the current measurement system in England is confusing.   Milk brought to the house by the infamous milkman is in pints, but the milk sold in stores is in liters.  “Petrol” stations sell gas in liters and advertise the price in gallons.  The distance between cities is in miles, but other road signs are in meters.   Of course, beer is sold in pints!  Everyone just knows when you walk into British pub you ask for a pint.

It is not uncommon to have local rules that dictate measurement.  Most people do not know that the volume of a UK pint is not the same volume of a USA pint.  One UK pint is equal to 1.20 USA pints.    A pint in the US is about twenty percent smaller by volume than a pint in the UK.  If a “pint” of beer is ordered in London, it is going to be about twenty percent larger than a pint of beer in the USA.  When my British friends order a pint of beer in the USA, they typically spend some time examining the size of the glass.  They often comment, “This doesn’t look right.”  They know something is wrong, but they just can’t identify it; they just can’t put their finger on it.

I have had CEOs tell me the same thing about their software organizations.  They tell me, “Things just don’t look right.”  Malcom Galdwell points out in his book Blink that intuition is often right, especially for those with a lot of experience.   The problem is that it is difficult to persuade someone based just upon intuition.   In the end, everyone should be able to explain and answer the question, “How do you know what you know?”   Without measurement, many people get attached to their beliefs and embrace all the emotions that go with their opinions.  In the absence of measurement and data, the person with the highest pay grade wins the argument that is based upon opinion.

I tell my British friends the reason a pint is smaller in the States is due to King George.  I tell them that King George taxed the colonist in America and shorted them on beer.  History tells us about taxation without representation, but fails to tell the story about the beer.

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


David Longstreet
Software Economist.

Hot Jobs in Software Development, Try Specialization.

speak and write a lot about specialization in Information Technology and the idea of specialization relates to the original question by Sharon.  It turns out that software is like many other industries such as textiles, metal working, medicine and architecture.

During the past centuries the evolution of modern societies has moved vigorously in the direction of increasing specialization of labor, knowledge, and expertise. It would be quite astonishing if software development did not follow this same path.  The idea of specialization is nothing new, and it is not limited to a specific industry or a field of study.

Specialization in software development seems to be following a specialization along a specific phase.  There seems to be a clear divergence between technical skills (.net, COBOL, and other languages) and business acumen.

We saw technical jobs  either disappear like blacksmithing or be exported to Asia like textiles.  What remained in the USA were business, requirements and design jobs.

As the software development industries matures there will be more and more individuals that specialize in a specific business.   A problem is that many software developers have no desire to learn about core business.   For the most part software developers do not study their customers, the core business or their companies competition.  If software development does not understand the core business, how is it possible to understand what functionality needs to be included or not included in any project, upgrade, or release.

I could go on and on this subject.  I devote an entire chapter to this in my online book Reboot! Rethinking and Restarting Software Development.  The book is free and online at http://www.RebootRethink.Com.

David Longstreet
Software Economist

Published in: on June 25, 2009 at 08:44  Comments (2)  
Tags: ,

Cloud Computing rhymes with Mainframe

It does not matter if we are talking about fashion, movies or even IT, things repeat.  Tie-dye, peace signs and 3D movies are making a comeback. Besides 3D movies there are a lot of  sequels and prequels movies too.  It seems like information technology (IT)  is repeating itself too.   Maybe not repeating but at least rhyming.   The latest trend in IT seems to be Cloud Computing.

In a land far far away and a long long time ago there were these things called mainframes.  A mainframe was  centralizedmainframe processing.  These mammoth computers were housed in large rooms with big air-conditioners and ran by men with black horn rimmed glasses.  Then there was a movement towards distributed processing and everyone would keep a copy of everything on their individual workstations.  There were proclamations that the mainframe was dead.

Don’t get me wrong here folks because there have been a lot of improvements from mainframes to Cloud Computing. All the talk about Cloud Computing sounds familiar.  Cloud computing succeeds where the mainframe failed.

With Cloud Computing I get to keep a copy of my files on my workstation.  This allows me to work when I am not even connected to the internet.  With mainframes everyone had a dumb terminal.  It was called dumb because it did not really do anything unless the terminal was physically attached to the mainframe.

Everything is automatically backed up!  Woo hoo!  I don’t have to worry about backing up critical files because they are in the “cloud.”

Since my files are synchronized across more than one workstation,  I can access my files from my laptop, my desktop and even someone else’s computer.


Since I am a self professed Apple head, I use a product called MobileMe.  MobileMe is classic Cloud Computing.  My wife never understood why the calendars on all our computers could not be synchronized, but now with MobileMe my wife can check or update calendars and contacts on any computer or device.  My iphone, my wife’s iphone, my laptop, all my iMacs and even my PC’s all stay perfectly synchronized just like a bunch of synchronized swimmers.

In the end the rumors of the mainframes death were greatly exaggerated .  They seem to be making a come back with a new name (cloud computing).   Cloud computing does offer much more than a mainframe and it succeeds in ways the mainframe failed.

Wait a second!  Tie-dye, Peace Signs, and Mainframes are all from the late 60’s and early 70’s.  What’s next miniskirts, flower power, and an energy crisis?

Read more at Reboot! Rethinking and Restarting Software Development

Published in: on June 24, 2009 at 10:24  Leave a Comment  
Tags: ,

Hello, Good Bye, Howdy, John Wayne!

Some years ago I was traveling in China.  My client had written out directions for me in English, so I could find my way to the worksite.  My plan was to take the train from Beijing to a small town where my client was located.  At first, all was going well, but the signs started to change from Chinese/English to just Chinese.   I asked some other travelers on the train for assistance but, since my instructions were in English and I did not speak Chinese, they could not help me.   I decided the best strategy was to get off the train at the next stop, which I did.  I found myself standing in a small village in China with chickens running around on a dirt road.   I was standing there in a suit and tie holding my computer bag.   I had one of those profound, obvious thoughts – I am lost.

At the end of the road, I noticed one sign that was in English.  The letters read, B A R.  So I ventured to the BAR in hopes of finding someone who spoke English.  As I entered an elderly Chinese man looked at me with some excitement and said, “Hello! Good Bye! Howdy! John Wayne!”  That was the extent of his English, but that did not deter me from trying to communicate with him.  I tried to explain, in English that I was lost.  He  smiled and nodded, then he poured me a large glass of beer and handed me a sandwich.   Keep in mind it was about 10 am., I was in China, I was lost, and I was drinking beer.

Suddenly, the elderly Chinese man left the bar.  I drank the beer and finished the sandwich, and I was not sure what to do next.  Since I had no idea as to where I was,  I just sat there. After about twenty minutes, he returned with a young boy who turned out to be his grandson.  His grandson told me, in English, “My grandfather came to my school and told everyone there was an American in his bar. No one believed him, but he insisted; so, I came along to translate.”

The young boy read over my instructions and, luckily for me, he understood my predicament.  He translated all the train stops from English to Chinese.  He told me he would escort me to the train station and helped me purchase a ticket to where I needed to go.  I started to feel a sense of relief.   As I departed the bar, I asked how much I owed for the beer and sandwich.   The young boy translated for me and then said, “My grandfather says you are his American friend, and there is no need to pay.”  I thanked the elderly man. He bowed toward me and, instinctively, I bowed back.

Software development is also lost. It is as if we cannot communicate with anyone other than ourselves; and too often, we can’t even communicate with each other.  When customers and clients ask us the simplest questions, we tend to answer with jargon.  Over the past decades development fads have come and gone.  In the late 1990’s the development fad was RAD (rapid application development); we moved onto iterative and today, the fad “de jour” is Agile.    Some of the fads are actually good ideas and have positively impacted software development while other fads have caused great damage.  What all the past and current fads have in common is that they were developed because software development is lost.

Just as there was a lack of understanding between the elderly Chinese man and myself, there is a real lack of understanding of those interfacing with software development.  It seems software development lacks the necessary vocabulary to communicate and understand their customers.  There is a lack of understanding between industries and disciplines that have gone before us, yet there is a lot to be learned from them.

Read more at Reboot! Rethinking and Restarting Software Development
Published in: on June 23, 2009 at 07:22  Comments (1)  

Danger, Will Robinson! Lost in Space?

I need someone to explain something to me.  Too often I hear the following statement.  “Our software is too complex to document, so we just code.”   Danger, Will Robinson!  Think about his from a logical perspective.

When software applications become very large or complex, it is hard to keep track of all the functionality contained within the application.   To really understand any complex system you need to use a technique called functional decomposition. So how do you perform a functional decomposition of a software application?   The basic idea is to divide a system into small logical parts. These logical parts are called elementary processes.  This technique works when solving complex mathematical equations, engineering systems, software applications and even your home entertainment system.

Before you begin to classify and organize your documentation, you will need a functional decomposition of your software applications.

  • What are all those small parts (or elementary processes)?
  • How are all these parts interconnected?

Danger, Will Robinson!  If you can’t perform a functional decomposition of your software application because it is too complex, then you software application is too complex.  You need to simplify it and you are probably lost in space.  It is not a matter of complexity, but a matter of not knowing how to properly document the software application.

Published in: on June 19, 2009 at 01:01  Leave a Comment  
Tags: ,

What we’ve got here is a failure to communicate!

If men are from Mars and women from Venus, then software development is from Andromeda and the user community is from the Milky Way.   Men and women have difficulty with communication because they are from different planets and software development and its user community can’t communicate because they are from different galaxies.

The communication gap seems to be growing larger.  Software developers tend to communicate in techno speak.   Most developers lack basic communication skills and this is one of the root causes of poor requirements.  Developers are not very skilled at asking open ended questions or how to politely probe.   They tend to ask biased questions.    Too many developers prefer computers over people.  All of this leads to poor communication.

So what should software developers do?  Funny that you ask such a question.  Developers need to learn how to

  1. Avoid using confusing jargon and acronyms
  2. Ask open ended questions
  3. Learn to politey probe
  4. Master the metaphor
  5. Avoid biased questions
  6. Focus on the benefits and solutions not the features.

Read more at Reboot! Rethinking and Restarting Software Development.

Curious v. Too Damn Smart

I have witnessed a lot of requirements gathering sessions over the years.  Too often the software developer takes the opportunity to demonstrate to the “user community” just how damn smart he or she happens to be.    The developer tends to ask complex questions and then rolls his or her eyes because the user just does not know what they want.

I am often shocked how little homework the developer has done before the requirements meeting.  It is pretty common for the developer to show up and not have any prepared questions.  Instead they ask the question, “tell me what you want?”  The developer needs to spend time studying the business.  They also need to distinguish between features of a software application and the benefits of a software application.   Developers tend to gravitate to features and ignore the benefits.

The user should be doing most of the talking not the developer during the requirements process.  A good rule of thumb is the 80/20 rule.  The developer should be talking about 20 percent of the time and the user should be talking about 80 percent of the time.  The developer needs to keep the user talking by asking open ended questions.

A developer should be skilled at creating functional decompositions of features that map directly to the benefits.   The developer needs to keep asking the question, “why does my user care about this feature?”  The purpose of a software application is to benefit the user and to help them do his or her job.