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!

Links

PMI (http://www.pmi.org)
Charles Lindberg (http://en.wikipedia.org/wiki/Charles_Lindbergh)
Marion Hart (http://query.nytimes.com/gst/fullpage.html?res=9C0CE5DA1030F937A35754C0A966958260)
Function Points (http://www.SoftwareMetrics.Com)

Software Does Not Have to Be Ugly

Clean design is harder than it looks
Not long ago I was able to visit the Biedermeier exhibit in Milwaukee Wisconsin, USA and later in Vienna, Austria.  As the curators of the joint exhibit in Milwaukee, Berlin, Paris and Vienna point out  the Biedermeier movement invented simplicity.  In essence it was  a move towards simplicity of design and clean lines.   Biedermeier refers to the work in the fields of music, art, literature and the visual arts that took place between 1815 and 1848. 

Software development needs a Biedermeier movement.  It needs to move from complex design to simplicity.  It is important not to confuse simplicity with simple.   The features and functions that are exposed to a person using a software application need to be clean and concise.  Nothing should be exposed that is not necessary until it is needed.  

Exposing Bad Design
The internet  and the proliferation of websites and especially customer self service websites did not create bad design because it only exposed it.  When software applications were deployed within the bowls of a a large organization few saw it.  The internet has allowed everyone to see an overwhelming lack of design skills. 

Internal Beauty
The inter-workings or the internal design of a software application needs simplicity too.  If what gets exposed is a design mess, then it is probably a safe bet what gets built under the hood, internally,  is a design mess too.  Poor internal design makes it hard to maintain and enhance a software application.  Poor design makes it difficult to understand “what is going on.”

Towards Great Design
“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.

Things to Read
When I travel and work with software developers I often glance at their bookshelf’s.  And  I ask myself, “What are they reading?”  When book shelfs are full of books about coding and nothing about design, then it is a safe bet the developers know little about design.  In the end you are what you read.  

The following are two great books about design.

Universal Principles of Design – William Lidwell

The Laws of Simplicity – John Maeda

Software Paleontologist: New Job Titles for the Software Industry

Software Psychologist – help software organizations over come its fears and phobias

Software Psychiatrist – same as a software psychologist but they prescribe drugs.

Software Archeologist –dig around looking for project artifacts.

Software Paleontologist – dig around for looking for evidence the project actually existed.  They also theorize what killed projects.

Software Theologist – pray for project success.

Software Plumber – unclog software projects.  This is not a glamorous job and it requires cleaning the project toilet.

Software Janitor –pick up after everyone else.

Software CSI – study the forensic evidence to determine if a project was murdered or committed suicide.  By the way most projects commit suicide.

Software Entomologist – collect all types of bugs found during the project.

Software Zoologist – studies all kinds of animals that work on software projects

Software Tap Dancer – dances around difficult project issues

When you are good at coding everything becomes a programming problem

Everyone has heard the adage if the only tool you have is a hammer every problem becomes a nail.  The actual quote is from Abraham Maslow and he said, “He that is good with a hammer tends to think everything is a nail.”

This is especially true with software developers.  There is a tendency to start programming because developers are good at programming.   To often the only tools that developers use to express his or her idea is the actual code or something he or she created in a Word document.  

Those developers that have tools in their creative box like Photoshop, Illustrator, or Indesign or some other design tool create creative and informative design documents.   They do not use code to develop designs.

Most software developers have never had a course in design, graphic arts, drawing, illustration or composition. I am writing about design courses offered by the industrial design department or the art department not courses offered by the computer science department.

The bottom line is that developers need to increase the number of tools in their toolbox; otherwise, every solution becomes writing code.  They need to seek out books on design, videos and even courses offered by the industrial design and art departments.  Otherwise they never see the world beyond code.  Every problem becomes a programming problem because he that is good at coding tends to think everything can be solved by programming.

What do I call myself this morning?

I can’t think of any of other discipline that is as discombobulated as the software industry.   We have an identity crisis because we can’t even figure out what to call ourselves.

So what do we call solving customers problems using  computers? Is it software development, computer science, information technology (IT), information management (IM) or is software engineering.  These terms are used interchangeably. 

When it doubt we should look it up, so let’s turn to wikipedia and look up these terms.

“Software development is the set of activities that results in software products. Software development may include research, new development, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.”

I really like this first definition of software development because it is vague enough not to be tied down or held accountable.  No one can really figure out what you are suppose to be doing.  I really dig any job title that includes the word “research”  because “research” officially means screwing off at work.

But wait… how about this definition of software engineering.   

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches.

It is really cool to say, “I am a software engineer” at some cocktail party.  It is like saying, I studied engineering in college and I am really smart.  By the way, most software engineers never studied engineering.   The problem with this definition is there could be some accountability with the words, “quantifiable” and “disciplined.”  You may want to avoid this definition at work, but use it to impress your friends and relatives. 

Maybe this definition of IT is better.  It is pretty vague and it is best to have a vague job description, so you can never be held accountable.

Information technology (IT), as defined by the Information Technology Association of America (ITAA), is “the study, design, development, implementation, support or management of computer-based information systems, particularly software applications and computer hardware.”

Wow! not sure what any of that really means.

I really dig the definition of information management below because it is the vaguest of them all.  It would be perfect if we could get rid of that last sentence because, well,  it sounds like some accountability to me. 

Information management (IM) is the collection and management of information from one or more sources and the distribution of that information to one or more audiences. This sometimes involves those who have a stake in, or a right to that information. Management means the organization of and control over the structure, processing and delivery of information.

In the end, I think it is best to just keep changing titles and especially organizational names.  If you were the department of Information Management this month, then you need to be the Software Development next month, then the IT department.  I would avoid using the term Software Engineer unless it is to impress someone that you don’t actually work with and does not really understand this thing we do with computers.

That reminds of the time my daughter was in kindergarten and introduced me and said, “my dad works with computers.”   Now that my friends is vague and I like it!

The Great Exalted Software Guru Speaks

Whenever I get worried about the future of software development, I go up to the top of the mountain to see the Great Exalted Software Guru.

 A few days ago I found him sitting crossed legged in front of his cave in a robe reading a book about Zen and meditation.   I placed a new 3.0 gig USB drive at his feet and bowed gracefully.

 “Oh Master” I said,” please tell me the future of software development.”

 The Great One Said, “the past is the best indicator of the future.  Those who do not learn from the past are doomed to repeat their mistakes”

 “Wow that is really profound, did you make that up.”

 “There is no new knowledge only old knowledge packaged differently. “

 “Oh Master” I said, “but the in the past software developers and their leaders have made many mistakes.”

 The Great One nodded in agreement and replied, “yes, they will make more mistakes, and it gets worse before it gets better.”

 I said, “that sounds bad.”

 The exalted one said, “It could be good.  It is better to get worse before getting better than getting better before getting worse.”

 Thinking out loud I said, “Wow, I never thought of that.”

 The exalted one said, “That is why I am the exalted one.”

 The exalted one exalted, “Do you remember Y2K?  The software developers were wrong about that problem.  Do you remember dot com, they were wrong about that one too.  Do you remember when software started to outsource in the 90’s, wrong again.”

 I nodded yes in agreement.

 Then the great guru of software said, “software developers need to meditate on their customers problems not on the code.” 

 I was taking notes as quick as I could.   I said, “but the code” he interrupted me and exalted again, “do not focus on the code. The code will only lead you down the dark side.  The path of happiness is found in deep meditation about your customers problems.”

 I thought about these great words and I asked, “Will this actually happen in the world of software.  Will software developers try to understand their customers before they code?”

 The exalted one replied, “no, because software developers are slow learners and this why they make so many mistakes over and over again.  This can be the only explanation.”

 I was trying to digest this wisdom when the exalted one said, “I must go and watch Dr. Phil.”  Just like that he stood up picked up the USB drive and quietly walked into his cave.