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.

Advertisements

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

Reboot! 4,000 Readers

Since publishing my online book  Reboot! Rethinking and Restarting Software Development in early February 2009 there has been 35,000 pages read by 4,000 different readers in 101 different countries.

The USA and India had the most readers with about 1,000  each followed by United Kingdom (250) and Canada (153).  What I find interesting are not the number of readers from countries known for software development, but the readers from countries such as Nepal, Moldova, or Zambia.   There were even a few readers from the Cayman Islands.  They need to step away from the laptop and get back to the beach!

Read more at www.RebootRethink.Com

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

The first management consultant – More Ancient Wisdom

Jethro the First Management Consultant – More Ancient Wisdom For Software Developers

Exodus the first book in the Old Testament was written around 1,450 BC or nearly 3,500 years ago. This is the first known reference to management and specifically to management consulting. This ancient wisdom is useful for managing software development.

According to Exodus, Moses was handling all the complaints and concerns of the Jewish people. As it is described in Exodus Moses spent all day sitting and listening to all the issues and concerns of the Jewish people. The Jewish people had to wait in line for hours to speak to Moses. Moses tried to resolve all the complaints and issues between the Jewish people himself. He was micromanaging.

Moses’ Father In Law Jethro saw this and offered Moses some advice. Jethro basically told Moses you are doing this all wrong. Jethro explained to Moses, “you will surely wear yourself out and not just yourself but the people. The task is too heavy for you; you cannot do it along.”

There are many reasons why we do not like to delegate. Ken Siegel, PhD, a psychologist who consults to managers says, “It’s probably one of the most significant management hurdles. To delegate you have to admit that someone is going to accomplish this at least as well as you, if not better, and most of us don’t like to acknowledge that.”

Delegating frees you up to do more important things like planning for the future.

Jethro was telling Moses to delegate some of his responsibility to others. Delegation would help Moses and the people. Jethro told Moses, “look among all the people for able and God-fearing men, trustworthy men who hate dishonest gain and set them as officers over groups of thousands, of hundreds, of fifties, and of tens.” The span of management control is only about 10 people and that has not changed much in the past three thousands of years.

Project management is not a new idea it seems to be a new idea for software development

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

Ancient Wisdom for Software Estimating

There is a lot of ancient wisdom that is useful for software development. Some of the wisdom comes from the West and some from the East. One of the most interesting parables can be found in the Christian New Testament. Jesus was addressing a crowd of onlookers and told this story. The story can be found in Luke and it reads, “Which of you wishing to construct a tower does not first sit down and calculate the cost to see if there is enough for its completion? Otherwise, after laying the foundation and finding himself unable to finish the work the onlookers should laugh at him and say, ‘This one began to build but did not have the resources to finish’. Luke 14:25-33

Too many software projects start without a clear understanding of the functionality of the project  or total project costs. The project sponsor marches his or her team straight down the path of project disaster. They ignore all the warning signs. The problem is that they did not know the amount of resources needed to finish the project in the first place. They did not fully understand the total cost or total effort.

Too many software developers do not know how tall the tower is going to be  or how much functionality is required.  In the end failing to understand total project cost and effort is not a new idea. It is just an accepted practice in the field of software development and especially in software estimating.

How do you write great user manual, you don’t.

A user manual is created to provide step-by-step instructions on how to use a product. The product can be a lawn mower, iphone or a software application. Software applications that are designed well do not require any user manual. Instead the software application is designed to be intuitive.

To design something that is intuitive requires a great understanding of how the product fits into the natural flow of things. This means the person or group of people that will use the software application have to be studied.  Too many software applications require the user to adapt instead of developing a software application to the user’s natural environment.

It does not matter if we are talking about people or gorillas. It is best to study people in their natural habitat instead of dragging them into a conference room and asking, “What do you want?” It is always best to go to the jungle and study your customer.  Ethnological analysis, going to the jungle, is alien in software development.  Most software developers have little or no contact with an actual user.

If you don’t understand how a person does his or her daily tasks or the natural workflow, then you can’t design software applications that are intuitive. Let me guess – you don’t have time to go to the jungle because you are busy writing user manuals and other documentation.

42!

My mobile phone rings, so I give a typical, “hello, this is David Longstreet.” There is no “good morning, my name is…, how are you”, but the voice gets right to the point. The voice on the other end asks, “What is the average cost to develop software?” Without hesitation I respond,”42!”

There is a long pause and the voice asks, “42 what?”

I say, “42 whatever you want, you fill in the units.”

The voice, “What do you mean?”

I respond, “42 hours, 42, 000 dollars, 4,200 euros, 42 million whatever works best for you.”

The voice, “Wow, I like this. I think I will go with 42,000 hours.”

I say, “Sounds good to me.” There is a long pause, so I assume the voice is thinking.

The voice asks, “how many people?”

Quickly I respond, “42”

The voice, “How many months?”

In a rapid fire fashion I say, “42”

The voices says, “42,000 hours, 42 people, 42 months.”

I say, “I think you got it!”

The voice says, “I really want to thank you for helping me out on this.”

I gleefully respond, “No problem.”

The voice just hangs up. There is no typical good bye, just silence on the other end of the phone. I think to myself, “42, it is really the answer to all the questions of the universe.”

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