Got Business Domain Knowledge? Here are five tips.

Here is some very specific techniques for studying and learning about the business domain.

1. Subscribe to the core business trade journals.  Every industry has trade journals.  For example,  the health care industry has Health Management Technology, Radiology Today, Digital Healthcare & Productivity, and Government Health IT.    All of these are free publications.

2.  Go to trade conferences that support the core business instead of just technical conferences and join subject matter expert groups.

3.  Read your companies annual report.  There is a lot of industry information it!

4.  Read your competitors annual reports.  Again, a ton of industry information!

5.  Visit the office of executive management (business side).  Ask the secretaries what the  executives are reading.  Explain to the secretary that you are trying to improve your business acumen. Trust me, this is a great idea.   Try to read what the business is reading.

Read more at Reboot! (http://www.RebootRethink.Com)

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

Mistakes in gathering requirements.

The worst possible way for the software requirements process is to have customers write up requirements and toss them over some imaginary wall.  The software development team works on the project for months and then shows up with a semi-completed project during acceptance testing.  Of course, the software is missing functions and does not work as desired by the client.  The problem is not that the business problem and solution changed during this time;  the problem is the business problem and solution were never defined.

Another common practice is sitting in a conference room with a customer and asking, “What do you want?”  Sitting in a conference room asking questions may not be a useful way to gather requirements, and it certainly should not be the only way.  This has nothing to do with how smart  or how good you are at asking questions.   Some developers will code what they thought the customer said and then show it to the customer.  This is commonly known as a code/test iteration.  A logical question is, “Why does it take so many code/test iterations to determine what a customer wants?” What were the reasons the developer and customer did not get it right in one or two tries (iterations)?  While this method is known as code/test, it is really a trial and error method to gather requirements.  The problem with trial and error is there are a lot of errors made along the way.

None of the solutions I mention actually address the root cause of the problem.   Many software professionals have thrown up their hands and accept that growth and changing functionality is just the nature of software development.  They incorrectly conclude the best strategy is to learn to adapt as the customer changes his or her mind.   In this scenario the solution to the problem is adaptation.   The teams need to be formed in such a manner so as to react as quickly as possible to the growing and changing environment.

The best way to gather requirements is to learn how to elicit requirements and study the core business.  The business analyst needs to be skilled at ethnology and a master of the metaphor.

You can read more in the free online book, Reboot!  Rethinking and Restarting Software Development, free at http://www.RebootRethink.Com

Published in: on June 26, 2009 at 01:01  Comments (1)  
Tags: ,

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
http://www.SoftwareMetrics.Com

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.

cloud-computing

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)  
Tags:

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: ,

How to Study Thy Customer

What always surprises me is how little software developers know about their own company and its industry.  The reason they know so little is because they have not taken any time to study.

One of the best ways to study customers is by using ethnological techniques.   Ethnological studies consist of looking  at what people do (behaviors), what they say (language), what they really do, what they make, and what they use (artifacts).   Too often what people say they do is not what they really do, and what they say they need to do their jobs is not what they really use.  It is important for the software developer to determine the real problem and the solution for the customers. Those software development organizations that are successful go to their customer jungle.  They follow their customers around trying to figure out how they actually work and what type of information is needed to complete the work.    They actually watch how their customers use the current applications.  They do not just rely on feedback they receive from user satisfaction surveys.

I practice what I preach.  Whenever I get a new client, I start to learn as much about their business domain as possible.  Since every industry has its own set of magazines, journals, organizations, and conferences, I start to subscribe to all these things in hopes of learning something about the business of my new client.  This is a common practice for an industrial designer.

Not long ago, I started consulting with a company specializing in the health care industry.  I subscribed to a series of free magazines such as Health Care Information Technology, Radiology Today, and Health Management Technology.   I also requested conference brochures. I am sure my mailman hates me because I get magazines and conference brochures from just about every industry now.  I read over these magazines and conference brochures to begin to learn about health care industry trends.  Back in the early 1980’s John Naisbitt wrote a bestseller book called Megatrends.  In his book he outlines in great detail how to study trends  and I use many of his ideas.

I learn the names of my client’s competitors.  I review annual reports, read articles and press releases. I make a list of my client’s competitors, a list of the top 5 trends, and a list of people I know in that industry.  Before I arrive at a client’s worksite I have a working knowledge of that industry. My background research is only a starting point for me.  Next I spend time at a client’s site studying them.

Read more at Reboot! Rethinking and Restarting Software Development.

Published in: on June 18, 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.

Organization makes a system of many appear fewer

Mark Twain once said, “A person that does not read books is no better off than a person who does not know how to read.”  An organization that creates chaotic documentation is no better off than an organization that does not create any documentation.  The argument could be easily made the organization is actually better off by not wasting time creating chaotic useless documentation.

On any single software project or application, there can be 100’s perhaps 1,000’s of artifacts.  The artifacts can be requirements specifications, design documents, flow charts, code, test plans, test cases, so on and so forth.  Most of these documents will reside on personal computers or stored on some shared drive.   I have worked with organizations where all “important” documents are stored on a shared drive.  The share drive was created with no standards and no subdirectories.  In other words, there is just a big pile of documents.  Within those documents there are no naming conventions, no standard glossary and no standard format. It can be nearly impossible to find information, so developers just ignore any previous written documentation and start from scratch.

I ask software development organizations to compare how they catalog and organize their documentation to how a library organizes knowledge.  I ask, “What would the local library look like if they followed a similar process for organizing documentation?”  Some people tell me the library would be empty, others tell me books would just be staked up all over the place, still others tell me some of the books would be half written and some of the books would be tucked away in librarians desks.  For too many software development organizations their documentation is not organized at all and it is chaotic at best.

The idea of classifying information and knowledge is not a new idea and has existed for several millenniums.  Classifying was one of those skills in which Aristotle excelled.  Aristotle understood information is easiest understood when it is classified and organized.    The idea of organizing and classifying is nothing new and it should not be a novel idea to software development. The bottom line humans like things organized, we have been organizing information for millenniums, and it is time software development get on board.

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.