February 25, 2008

UNDERSTANDING THE SPECIFICATIONS PUZZLE

"You like potato and I like potahto
You like tomato and I like tomahto
Potato, potahto, Tomato, tomahto."
Let's call the whole thing off."
- Lyrics by Ira Gershwin; Music by George Gershwin

Defining specifications for the design and development of systems and software is a lot like this classic Gershwin song and what I personally regard as the biggest cause of confusion in the Information Technology field for as long as I can remember, which is over 30 years in the industry. Some people say specifications should be based on the inherent properties of information, others believe it is based on a screen/report or file layout, yet others adamantly believe it should be based on process and data specifications. Interestingly, all are absolutely correct. The difference lies in the perspective of the person and the work to be performed. For example, how we define specifications for the design of an automobile is certainly different than how we specify a skyscraper. The same is true in the I.T. field where we have different things to be produced by different people; for example:

1. THE PROGRAMMER (aka, Software Engineer) requires precise specifications in order to develop program code (source and object). This normally takes the form of processing requirements (e.g., hardware configuration, types of transactions to be processed, volume, timing, messages, etc.) and physical data requirements (input/output/file layouts).

2. DBA (Data Base Administrator) requires precise specifications in order to select a suitable file management technique (e.g., DBMS) and produce the necessary Data Definition Language (DDL) for it. This normally takes the form of a logical data base model representing relationships between data entities.

3. THE ANALYST (aka, Systems Analyst, Systems Engineer, Systems Architect, Business Analyst) - requires specifications about the end-User's information requirements in order to design a system solution. This is normally based on a definition of the user's business actions and/or decisions to be supported. Following the system design, the Analyst produces the specifications required by the Programmer and DBA to fulfill their part of the puzzle. From this perspective, the Analyst is the translator between the end-User and the Programmers and DBAs.

Each party has his own unique perspective of the puzzle and, as such, requires different "specifications." To compound the problem though, the role of the Analyst sharply diminished over the years, leaving it to the Programmers to try and determine what the end-User needs, a skill they are typically not trained or suited for. To illustrate, I am reminded of the story of the IT Director at a shoe manufacturing company who received a call from the corporate Sales Manager asking for some help on a pressing problem. The IT Director sent over one of his programmers to meet with the Sales Manager and discuss the problem. Basically, the manager wanted a printout of all shoe sales sorted by model, volume, type, color, etc. The programmer immediately knew how to access the necessary data and sorted it accordingly thereby producing a voluminous printout (three feet high) which he dutifully delivered to the user.

The IT Director stopped by the Sales Manager's office a few days later to inquire if the programmer had adequately serviced the user. The sales manager afforded the programmer accolades on his performance and proudly pointed at the impressively thick printout sitting on his desk. The IT Director then asked how the manager used the printout. He explained he took it home over the weekend, slowly sifted through the data, and built a report from it showing sales trends.

"Did you explain to the programmer you were going to do this?" asked the IT Director.

"No," replied the Sales Manager.

"Aren't you aware we could have produced your report for you and saved you a lot of time and effort?"

"No."

This is a classic example of the blind leading the blind. The user did not know how to adequately describe the business problem, and the programmer asked the wrong questions. Remarkably, both the Sales Manager and programmer were delighted with the results. The IT Director simply shook his head in disbelief.

There are substantial differences between specifying information requirements and specifying software. Both have their place, but both serve different purposes. Whereas a true Analyst investigates the underlying business rationale of the information, the Programmer lives in the physical world and is only concerned with how the software will work.

It is not uncommon to hear programmers lament, "Users do not know what they want." They may not know how it should physically look or how it should best be delivered, but Users most definitely know what they want from an information point of view. Most programmers simply are not asking the right questions. Then again, they were not trained for this and are trying to compensate for the lack of true Analysts.

Remarkably, the Analyst function is experiencing a resurgence in the industry as companies are realizing that a higher level person is needed to understand the business and have a more global perspective of a company's systems and software. To illustrate, the process should fundamentally work like this:

1. Working with the User, the Analyst studies the business and helps the User specify information requirements.

2. From the requirements, the Analyst produces a system design which includes either a new system and/or modification of an existing system. As part of the design, the Analyst defines:

• The logical processing of data in terms of how it is to be collected, stored, and retrieved.
• The business processes affected, including the parts implemented by the computer.
• The design of the inputs and outputs.
• The design of the logical data base model.

In considering the computer processing, the Analyst determines which portions can be implemented by a commercial package or requires programming.

3. The design specifications are conveyed to the Programmer and the DBA for implementation.

4. From the logical data base model, the DBA designs a physical solution and produces the necessary Data Definition Language. The DBA passes on the physical file layouts to the Programmer for implementation.

5. The Programmer studies the software specifications and determines a suitable method of implementation, e.g., languages to be used, along with suitable tools and techniques for design.

The real beneficiary of such an approach is the programmer as the "guess work" has been eliminated for him. This may be an oversimplification of the overall process, but it is intended to show the vital role the Analyst plays and how it contrasts with the other participants. In the absence of such a person, the Programmer inevitably defaults to the role of Analyst and here is where specification problems begin to emerge.

This also hints at the limitations of "agile" methods. To their credit, the proponents of such methodologies recognize they are limited to software and, in particular, a single program. In doing so, they are trying to expedite the overall process of specification gathering in order to get to the job of programming.

In addition to defining the relationships between the various development functions, there is also the problem of developing a standard and consistent approach for recording specifications. This can be performed orally, but more likely it is recorded using a documentation technique to communicate the work to be performed and as a means to check the finished product to see if it does indeed satisfy the specifications. In the fields of engineering and construction, standards have been developed over the years to record specifications, such as blueprinting. But in the I.T. field, a myriad of techniques have been introduced with little or no standardization. For example, there are several different types of graphical and textural techniques, as well as repositories and data dictionaries to record and track specifications. Regardless, very few companies have adopted standards for recording specifications.

CONCLUSION

The problem with specifications in the design and development of systems and software is primarily due to a lack of standardization in the industry. There are a lack of standards in the areas of:

• Different types of deliverables resulting from the development process and how to format them (including specifications).

• Different development functions participating in the process, along with their interrelationships, and duties and responsibilities.

• Different perspectives of development in terms of the inherent properties of systems and software.

• Different methods, tools and techniques for performing design and development.

As long as there remains a lack of standardization in the I.T. industry, there will always remain a different interpretation of what specifications are and how to best document them. In other words, we'll go on saying "You like tomato and I like tomahto." So when do we call the whole thing off?

If you would like to discuss this with me in more depth, please do not hesitate to send me an e-mail.

REFERENCES:

Defining Information Requirements
"PRIDE" Special Subject Bulletin No. 4 - Dec 24, 2007
http://www.phmainstreet.com/mba/ss041227.pdf

Understanding Information
"PRIDE" Special Subject Bulletin No. 78 - June 5, 2006
http://www.phmainstreet.com/mba/ss060605.pdf

What is a good program spec?
"PRIDE" Special Subject Bulletin No. 14 - Mar 07, 2005
http://www.phmainstreet.com/mba/ss050307.pdf

The Ratio of Analysts to Programmers
"PRIDE" Special Subject Bulletin No. 85 - July 24, 2006
http://www.phmainstreet.com/mba/ss060724.pdf

Logical vs. Physical Design: Do You Know the Difference?
"PRIDE" Special Subject Bulletin No. 73 - May 1, 2006
http://www.phmainstreet.com/mba/ss060501.pdf

Is Software Hard?
"PRIDE" Special Subject Bulletin No. 8 - Jan 24, 2005
http://www.phmainstreet.com/mba/ss050124.pdf

OUR BRYCE'S LAW OF THE WEEK therefore is...

"Good specifications will always improve programmer productivity far better than any programming tool or technique."

"MORPHING INTO THE REAL WORLD"

Friends, we have just published a new book entitled, "MORPHING INTO THE REAL WORLD - A Handbook for Entering the Work Force" which is a survival guide for young people as they transition into adult life.

Bonnie Wooding, the President-elect of the Toronto Chapter of the International Association of Administrative Professionals (IAAP) said, "Many of our members are just starting their careers and I will be recommending that they read this book, especially Chapter 3, Professional Development - a primer for business skills and filled with basic common sense advice that is simple, easy to follow and extraordinarily practical; and Chapter 5, Do’s and Don’ts of the Workplace, an excellent resource for those questions you are too embarrassed to ask for fear of looking foolish."

The Miami Hurricane recently reviewed it (10/22/2007) and said,

"the abundance of information the book provides is a good start for anyone about to take the first step into the real world. Though the concept of adulthood may seem intimidating, it's comforting to know that someone has at least written a guidebook for it."

Reviewer Bill Petrey praised it by saying, "Every young person entering the workplace for the first time should be given a copy of this book."

The book includes chapters to describe how a young person should organize themselves, how to adapt to the corporate culture, develop their career, and improve themselves professionally and socially. Basically, its 208 pages of good sound advice to jump start the young person into the work force. Corporate Human Resource departments will also find this book useful for setting new hires on the right track in their career. It not only reinforces the many formal rules as contained in corporate policy manuals, but also includes the subtle unwritten rules we must all observe while working with others. The book lists for $25 and can be ordered online through MBA or your local book store. Complementing the book is a one day seminar of the same name which can be purchased separately for $4,000.00 (U.S.) plus instructor travel expenses. For more information on both the book and the seminar, visit our corporate web site at: http://www.phmainstreet.com/mba/morph.htm
ISBN: 978-0-9786182-5-4

MY "PET PEEVE OF THE WEEK" IS "NAYSAYERS"

It is one think to offer wise counsel, it's quite another to try and screw things up for others simply by being negative. I remember when I was a kid, there would be classmates who advised me that I shouldn't take a particular class, that it was too difficult and I would fail. Interestingly, I didn't. I also had friends tell me not to play football; that it would affect my grades and I would injure myself. Again, it didn't; and I found it to be a very rewarding experience.

As I got into the workforce, I found even more naysayers who would tell me, "It cannot be done," or "We've never done it that way before." I've also seen this same phenomenon in several nonprofit organizations I have participated in. If I were to follow the advice of these naysayers, I would probably be still living at home with my parents sleeping in my crib.

Although I listen to the advice of the naysayers, it gets rather old after a while and a bit disconcerting. These are people who honestly believe the glass is half empty all of the time, and get visibly upset when you point out that the glass is actually half full. But their negativity can wear on a person over time. If you tell someone they cannot do something enough times, people start to believe it and act accordingly. Basically, naysayers want us to conform to their way of thinking, but by doing so, they are discouraging original thought and innovation which is a tragedy.

In a way, it reminds me of a chapter from Ayn Rand's acclaimed novel, "The Fountainhead," about a brilliant architect who dares to stand alone against the hostility of unimaginative conformists. In the book, Howard Roark, the protagonist, is brought up on charges of destroying a building he designed. In the courtroom, he offers an eloquent defense which ultimately leads to his vindication. Although space prohibits me from including his complete courtroom testimony here, the following passage sums up the problem with naysayers. In the courtroom, Roark explains to the jury...

"Throughout the centuries there were men who took first steps down new roads armed with nothing but their own vision. Their goals differed, but they all had this in common: that the step was first, the road new, the vision unborrowed, and the response they received--hatred. The great creators--the thinkers, the artists, the scientists, the inventors--stood alone against the men of their time. Every great new thought was opposed. Every great new invention was denounced. The first motor was considered foolish. The airplane was considered impossible. The power loom was considered vicious. Anesthesia was considered sinful. But the men of unborrowed vision went ahead. They fought, they suffered and they paid. But they won."

In a strange way, naysayers are doing us all an important service; for every "problem" they identify, I see an "opportunity." As I learned a long time ago, if I can think a problem through, I can do it.

I have advised my children that throughout life they will undoubtedly meet with naysayers who will take pleasure in chiding them as to what cannot be done. I thereby admonish them to prove them wrong and return the favor.

Such is my Pet Peeve of the Week.

Note: All trademarks both marked and unmarked belong to their respective companies.

"BRYCE'S PET PEEVE OF THE WEEK"

Folks, a couple of years ago I started to include my "Pet Peeve of the Week" in these "Management Visions" podcasts. They have become so popular that I now syndicate them through the Internet and they are available for republication in other media. To this end, I have created a separate web page for my writings which you can find at phmainstreet.com Look for the section, "The Bryce is Right!" Hope you enjoy them.

AND FINALLY...

I received the following e-mails from my "Pet Peeve" entitled, "Generation Gap":

An M.S. in Royal Oak, Michigan wrote...

"Good article. Thanks. Yes, mentoring is making a comeback and it is a great job hunting technique. Find someone who has the job you want and learn from him or her. It is a myth that the older generation is computer illiterate. Actually we are the ones who can afford the latest toys. Thanks again for another thoughtful article."

An E.A. in Midland, Michigan wrote...

"I spent 33 years with Dow Chemical Company. In the late 80's, early 90's the company got on the kick of "team building" which involved many meetings. Bottom line was that for me it was very frustrating since most of the "team" things were stuff I was already doing or was a proponent of and I didn't think I needed more "training". Of course my management didn't think I was "buying into" the line since I resisted what I considered a waste of my time. I later found out that this "team building", which was being pursued throughout industry, was primarily in response to the idea that the younger generation had not learned how to cooperate with others and needed to learn how to work together. If management had left it to some of us experienced people, we would have "taught" them how to cooperate with no meetings in a big hurry (usually only takes one project). Probably would have had some hurt feelings but those fix themselves with success."

I received the following e-mails regarding my "Pet Peeve" on "Chatty Cathies":

An M.B. in Clearwater, Florida wrote:

"I dropped an otherwise nice friend because of this, and would love to e-mail her this column, since she is currently driving a mutual friend crazy, and the mutual friend does not want to drop her. Being quite low on energy already due to my illness, I simply did not have the energy to put up with her constant blather, and felt completely drained after each encounter. I don't think this woman realizes that is why she can't keep friends. My husband's father was also like that, but he was not nice, like most of the Chatty folks in your life, he had Narcissistic Personality Disorder. I suspect many Chatty types do, since complete insensitivity to others is one of the symptoms. They are not interested in what you have to say, since it could not possibly be on the level of their grand and perfect ideas, and besides, you do not really exist as an independent entity; you are just an extension of them. Narcissists are awful people, and very toxic to those around them."

A J.S. in Münster, Germany wrote...

"Somehow this fits perfectly to most of my professors."

Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2008 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END