Welcome to Club Chaos!

The secret of all victory lies in the organization of the non-obvious.
– Marcus Aurelius (Roman Emperor AD 121-180)

Things Just Seem Complex

Software applications and documentation seem more complex when they are not organized. It does not matter if it is software applications, books, collections, or lives anything that is not organized seems more complex than it really is.   As John Maeda writes in The Laws of Simplicity, “Organization makes a system of many appear fewer.”   If applications and associated artifacts are not organized, then there is only a sense the application is complex.  By organizing application artifacts complexity of applications is reduced.

I have been to a lot of grocery stores around the world, including Rome, and it seems like they are all organized in a similar manner.  In any grocery store there is the fruits & vegetable section, meat & cheese, bread, canned goods, frozen foods, snack foods, liquor, so on and so forth.

Organized documentation and functionality is important for everyone especially the novice.  A grocery store is a complex system. Since the grocery store is organized, it is easy for the novice clerk to re-shelf the contents of the grocery store and the novice customer to find what they are looking for.   A novice is a person who is trying to understand something for the first time.  Think about all the different manufacturers of products or the number of countries where products originated to stock the grocery store shelves.   The goods only represent one layer of complexity.  Another layer is the scheduling of employees to clean the store, to shelve, and to run the cash register.  The beauty is all the complexity has been hidden from the customer.   The grocery store is an organized complex operation; yet, our interactions seem simple.

When software applications evolve without a comprehensive design, functions get scattered around and it becomes hard to navigate all the confusion.  Since there is no clear functional decomposition of the application, the user of the application and developer have a hard time finding a specific piece of functionality.   The application is difficult to navigate and users become frustrated.

Developers have a hard time finding functionality or understanding the functionality that already exists.   This causes redundant functionality to be created.  This extra functionality is not needed and it becomes additional expense to create and to maintain.

The perceived complexity is worse when multiple applications share information and communicate via undocumented interfaces.  If documentation is not organized which describes all the complex interrelationships it is going to be next to impossible to grasp what is actually happening.

Advertisements

Software development is not random. IT has pattens.

Software development organizations, like people, have patterns.  In other words organizational behavior is not random.  Organizational behavior, like the behavior of a person, has a pattern and therefore can be predicted.   If you study your software development organization I guarantee you will start to see repeating patterns be able to predict patterns and make systematic improvements. The only way to learn about a software development organization is by systematic study.  When studying a software development organization it is important to gather data from samples, make conclusions and then forecast the future.

The entire premise of software metrics is the best way to can improve a software development organization is by systematic study.    Peter Senge points out in his book, The Fifth Discipline organizations must learn if they are going to survive in a global economy.  Software development is a global industry that changes and moves rapidly.

The movie Groundhog Day exemplifies many software development organizations.  The basic premise of the movie is the main character, Bill Murray, never learns.   Too many software development organizations never learn.  They just keep making the same mistakes over and over again.

The best learning comes from systematic study of past projects.  Some organizations, like people, need to learn from their mistakes and their successes.  Unfortunately many software development organizations, again like people, never learn from their mistakes.   These organizations keep making the same mistakes over and over again.

Ethnography

The fancy or academic word for what you are about to do is, “Ethnography.” In ethnography a researcher examines the group’s observable and learned patterns of behavior, customs, rituals, and ways of life.

The lengthy study of Gorilla’s by Dian Fossey is an example of an ethnographical study.   If Fossey can successfully study and learn about gorilla’s in the wild,  then I am pretty sure anyone can  study and learn about their software development organization in an office environment.

Read more at Reboot! Rethinking and Restarting Software Development.

Are software developers like the janitorial staff?

I think everyone remembers being a kid at the big Thanksgiving or some other family get together.   It is pretty common for the adults to sit at one table and the kids to sit at another table.   I always wanted to sit at the table with the adults, but my grandmother told me I could sit at the adult table only if I acted like one.

The following video was put together by a young film maker named Jordan Kerfeld.

Today the business is at the big table and software development is at the kids table.  When software developers have no desire to learn about the business and especially when your team has no desire to learn about the business, then why would the business ever invite you to be part of the business.

Software development is the only industry we have where workers move from industry to industry. It is time software developers learn and study the core business.

Read More at Reboot! Rethinking and Restarting Software Development.

WIFM is everyone’s favorite radio station.

Everyone’s favorite radio station is WIFM, or, “what’s in it for me.”  I was consulting with a company that develops software for the property casualty insurance industry.  During one of my consulting engagements, I encouraged a group of developers to learn about the insurance industry.   Yeah, that is right.  I encouraged them to learn about the core business.  What a crazy idea!  A couple these developers discovered there are numerous journals, magazines, organizations, and conferences dedicated to just the property causality insurance industry.  By the way, I have learned over the years every industry has its own magazines, conferences, and trade shows.

These same developers asked to go to a property causality industry trade show instead of the standard software conference.   One of the developers told me, “it was like a million light bulbs went off in my head.  I walked up to one of our competitor’s booth and watched a demo of their software products.  I thought their product was really cool, then I took a big gulp and realized our product can’t do that.”  At the conference, like many conferences, there were small group meetings.  One of the meetings was on how information technology impacts the insurance industry.  To the surprise and delight of the software developers out of the fifty or so attending the small group session, they were the only software developers.  The rest of the group was comprised of those internal clients that interface with software development.   The small group welcomed these two developers with open arms and they became the focus of small group discussion.  In the end, the software developers collected a fist full of business cards from companies offering them jobs.

Unfortunately most software developers do not subscribe to trade industry magazine, conference or trade shows that represent the core business.  Instead, they stay huddled up in their cubes blaming their users for poor requirements.  They have not figured out that their lack of knowledge regarding the core business is part of the problem of poor requirements.

Read More at Reboot! Rethinking and Restarting Software.

Got industry experience?

Often I find myself just sitting around thinking.  The other day I started searching several online job posting websites.  I was wondering if other disciplines require  knowledge  of the core business.  In my quest to figure this out I reviewed over 500 job postings for a variety of different technical disciplines including mechanical engineer, electrical engineer, chemist, and biologist.  In each case, over 90 percent of the job postings required industry domain expertise.   For example, a job posting for a mechanical engineer required 11-14 years of experience in production packaging of electronic equipment.   The same was true for chemist and nearly all chemist jobs required domain experience or knowledge of the core business.

Let me stop and review.   If you are a chemist then your future employer wants you to know about chemistry and the industry (core business).  The same is true if you are a mechanical engineer or electrical engineer.

This is in sharp contrast to software development.  When I examined job posting after job posting, almost none required any knowledge about the core business.   Out of 100 job postings for software developers that I  reviewed only 4 required industry domain knowledge.   Think about this for a second.   Poor  requirements plague the software industry.  Do ya think it has anything to do with the fact most software developers have no knowledge of the core business?  Come on folks!

One could argue that it is better to be a generalist instead of a specialist, but no other industry suffers as many project failures has software development.  No other industry frustrates end users like the software industry.  No other industry has such a problem with requirements as the software industry.

Read more at Reboot! Rethinking and Restarting Software Development

Software Developers Cause Their Own Problems.

Over the years I have been convinced that software developers cause their own problems.  I have been in too many meetings where software developers are fabricating answers.  The following video was put together by a young film maker named Jordan Kerfeld.

The spread of a fever and infections was a real issue for hospitals during the mid 1800’s. There was a doctor, Ignaz Semmelweis of Vienna Austria, who believed statistical methods, could be applied to medicine.    Doctors of the day did not think statistical methods could work because medicine was too unpredictable – sound familiar.   There are many software developers who honestly believe statistical methods cannot be applied to software development because software development is too unpredictable.  What they fail to grasp is that they are causing the unpredictability.

The analogy of  Semmelweis works for software because software developers are creating their own chaos and their own problems.  Since software developers are not capable of estimating,  they are not capable of planning either.  It does not seem to matter if it is the insurance, aerospace, healthcare, banking, finance, hospitality industry this is a repeating pattern

Read more at

www.RebootRethink.Com

Pair Programming versus Cheech & Chong

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 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 smackdown 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.  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.

Read More at 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 job check out the auto Professional Name generator at  wrestles – http://www.wrestlingname.com/

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

The Software Guru Speaks Again

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.

More from the guru….

https://davidlongstreet.wordpress.com/2009/09/30/the-great-exalted-software-guru-measures-time-in-bytes/

Miracle Worker

One of my favorite movies scenes is in Star Trek III: In Search for Spock. Of course the Enterprise has some mechanical problems. Kirk asks Engineer Scott, “ Scotty, how long will it take to make the repairs.” Scotty replies, “8 weeks Captain, but you don’t have 8 weeks, so I will do it in 2 weeks.” Kirk asks, “Have you always multiplied you repair estimates by a factor of 4.” Scotty eagerly admits, “Of course. How do you think I keep my reputation as a miracle worker?” Scotty overestimates the amount of time it will take to fix the Enterprise and then delivers the project underestimate.

I often thought it would be lucrative to teach people how to become miracle workers.  I could teach people how to inflate their estimates and then deliver early and under budget.  When someone asks, “How did you come up with your estimate?”  Your answer could be something like, “I have 20 years of experience.”  That does not really answer the question, but it  works.  If your client still challenges your estimate then you could respond with something like, “You don’t understand the technology (shake your head and roll your eyes).”  Make sure to  add a few coding words to impress, confuse and intimidate your client.  This should get them to back down.

Read more at www.RebootRethink.Com

A software application should have no unnecessary functions!

Many years ago I learned a very important idea and this idea has stuck with me and benefited me.  The idea is E.B. White’s seventeenth rule in The Elements of Style:

Omit needless words.
Vigorous writing is concise.  A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.

A software application should have no unnecessary functions. Just like writing can be bloated a software application can be bloated too.   The reason software applications have unnecessary functionality is due to the fact the person designing the application did not have a clear understanding of what the person using the software application wanted to do.  Too often it seems like requirements just rain down on the software development team.

The question, “What do you want the software application to do? “ is an incomplete question.   To design a software application well requires the software designer to study how the user does his or her activities.  A software application needs to be designed so it fits naturally into the flow of work or activity.

If the software designer has not studied how a person works and designs the software around the natural work flow, then there is a high probability the software application will be bloated and a lot of unnecessary functionality created.   It would be nice if the rule was expanded and would read as follows.

Omit needless functions
Vigorous writing is concise.  A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines, a machine no unnecessary parts and a software application no unnecessary functions.

For more read the free online book www.RebootRethink.Com