MANAGEMENT VISIONS

Tuesday, May 01, 2007

May 7, 2007

"HIRING THE RIGHT PROGRAMMER"

Finding a good programmer can be a difficult task. Often times you will come across a candidate who interviews well and appears to have impressive credentials, yet you discover too late that he is simply not as proficient as you thought he was. Now you have someone you will either have to eventually eliminate or invest considerable money in to bring him up to speed (or both). What to do? True, you should probably improve your interviewing skills and learn to read between the lines of a resume, but there are a few other things you can do.

Basically, there are three things you, as a manager, want to know about a new employee; his background (job history), his knowledge, and how well he will adapt to your corporate culture. His background should be revealed by the interview, his resume, and any references he might have, but determining his knowledge and adaptability to the corporate culture is a little trickier.

CORPORATE CULTURE

I have discussed the importance of corporate culture many times in the past; in particular, see: No. 28 - "Understanding Corporate Culture" - June 13, 2005

Basically, in order for any employee to properly function and succeed, it is imperative that he is able to adapt to the corporate culture. If not, the culture will reject him and the employee will become an outcast. Before we can evaluate the employee's adaptability though, we should understand our own culture first. For example:

What are the corporate ethics? Do you value honesty and integrity or are you a politically charged environment with considerable backbiting, finger pointing, piracy, and other questionable office tactics?
Do you commonly seek "quick and dirty" solutions or do you operate more as skilled craftsmen?
How rigid are your operating policies, e.g., dress codes, hours of operations, conduct, etc.?
What are interpersonal relations/communications like in your office; e.g., speech, form of address, decorum, cooperation, etc.?
What form of management do you practice; dictatorial with considerable supervision or do you empower your employees to make decisions?

Ascertaining a candidate's adaptability will be primarily based on your observations of the candidate during the interview.

SKILLS & PROFICIENCIES

A candidate's resume will say one thing, but you may be looking for something else. As part of the interview, you may want to ask the candidate to complete a Skills Assessment which lists the skills pertaining to your area and his level of competency (proficiency). After the candidate has completed the Skills Assessment, it should be compared against his resume in order to look for discrepancies.

In terms of pertinent skills, the programmer should be able to list the languages he knows, including computer control languages and tag languages, operating systems, DBMS architectures, and the various development tools he is familiar with.

KNOWLEDGE

Now, more pointedly, you need to know if the candidate truly knows how to program or not. College degrees, certificates, and participation in trade groups are important, but you need to convince yourself the person has substance as opposed to facade. Samples of work are useful, but then again, are you sure the person actually produced it? We have always found it useful to provide a simple programming test for the person to verify he knows what he is talking about. He can either substantiate his knowledge through a test or he cannot. The test should be designed in such a way as to reveal the person's general knowledge as well as to demonstrate he has the skills he claims.

CONCLUSION

Testing is an invaluable means for determining if candidate qualifications as stated in resumes are legitimate. Basically, it helps differentiate between facade and substance. Some Human Resource departments frown on such testing, others welcome it. For programmers, I consider it vital. Frankly, you have better things to do than waste time on someone who is not truly qualified for the position. Remember, "An ounce of prevention is worth a pound of cure."

OUR BRYCE'S LAW OF THE WEEK therefore is... "A resume is either an accurate description of a person's capabilities or demonstrates how well someone can write fiction."

MY "PET PEEVE OF THE WEEK" IS "SPRING CLEANING"

Whenever someone brings up the idea of "Spring Cleaning" it conjures up an image of people stuck in cabins during the winter and need to clean out their shack after hibernating inside for several months. But basically, Spring Cleaning is used to force us to get organized. There are a lot of us who are just plain slobs who tend to act like pack-rats and collect a lot of debris, be it at home or in the office. Spring Cleaning, therefore, is intended to clean up the flotsam and jetsam around us. And I think this is important, particularly in offices.

There are those who believe a sloppy desk is indicative of a brilliant mind. Baloney. A sloppy desk is indicative of a pigpen and the person is disorganized and undisciplined. Too often people use a cluttered desk to give the illusion they are being overworked and use it as an excuse for being late on a project. For managers who have been around the block a couple of times, a cluttered desk doesn't fool anybody anymore. In our office, we would tell our programmers to subscribe to the military concept whereby you either work on something, file it, or throw it away. If we need more file cabinets, we'll get them, but let's not let our desks become pigpens. To enforce this rule, we would periodically go through the office at night and throw all of the debris on the desks into the garbage. You do this a couple of times and people finally take you seriously. Keeping a clean and orderly workplace can have a dramatic and positive effect on the demeanor of your office workers and they will start to behave more professionally.

People still practice Spring Cleaning at home as well. You see signs of it by the many garage sales in the Spring where people circulate their junk to other people who recycle it around the neighborhood. I tend to believe there is a certain amount of junk we simply rotate from one household to another, so why bother with the garage sales? Let's just play musical chairs with it. Better yet, why don't we just dispose of it once and for all?

I remember my Scottish grandmother in Buffalo, New York was a big believer in Spring Cleaning. Every year she would lead the family in cleaning the house like Atilla the Hun. Beds would be turned, rugs taken out and beaten, windows washed inside and out, silverware polished, kitchen and bathroom floors and fixtures scrubbed, etc. You get the picture; she was very thorough. But she wouldn't stop with inanimate objects, to her way of thinking "Spring Cleaning" also meant cleaning up the family. To this end, once a year she would brew a pot of tea made from Senna Leaves, a very powerful herbal stimulant laxative. I guess she figured it was needed to clean out the toxins in our system, and as anyone in our family can testify, it works, perhaps too well. Not long after drinking a cup of this tea, your system would be flushed of impurities right down the toilet, perhaps hours at a time. It was rather brutal. This stuff was so strong, it would even clean the dirt from behind your fingernails and the wax from your ears. Small wonder Spring Cleaning conjures us a bad image in my mind.

As a result, I tend to keep things orderly and tidy all the time as opposed to waiting for a Spring Cleaning. Maybe that is what my grandmother was trying to teach us all along. Nonetheless, I haven't had a cup of tea in years.

Such is my Pet Peeve of the Week.

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

AND FINALLY...

I received an e-mail from a Q.B. in Minnesota regarding my recent "Pet Peeve" on "Weathermen."

Q.B. writes -

"Yes, being a weatherman is an odd career choice. How often can one find a career where you can be downright wrong MOST of the time and still keep your job?"

Thanks Q.B. for your comments.

Again, thanks for your e-mail. 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. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

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.

This is Tim Bryce reporting.

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

END

Labels: Broadcast, Bryce, Designer, Engineer, Hiring, IRM, Management, MBA, Podcast, Programmer, Programmers, Right, Software, Tim, Visions

Wednesday, March 14, 2007

March 19, 2007

"THE RATIO OF ANALYSTS TO PROGRAMMERS"

In terms of systems development, during the 1960's and early 1970's you were either a Systems Analyst or a Programmer. Period. At the time, there were substantially more analysts than programmers (at least a 2:1 ratio). This was due, in part, to the fact that computing was just coming into its own in the corporate world and there were still people around who could look at systems in its entirety. However, there was a screaming need for people to program computers and, as such, this became the boom years of programming. If you knew COBOL, Fortran, or PL/1 you could just about right your own ticket. Salaries were good, and you could intimidate your employer simply by what you knew (you had to commit something like murder to get fired). The emphasis on programming became so great that authors rushed out voluminous books to increase programmer productivity, hence the birth of the Structured Programming movement of the late 1970's, which was followed shortly thereafter by the CASE movement (Computer Aided Software Engineering).

While programming was growing in stature, Systems Analysis was in sharp decline. Trade groups such as the Association for Systems Management (ASM) saw their membership dwindle to nothing and were forced to close their doors. The last of the old Systems Analysts either retired or were put out to pasture by corporations in the 1980's. New job titles emerged, such as Software Engineer and Analyst/Programmer. This latter title is a bit of a misnomer as the emphasis was on programming and not systems analysis.

Although programming excelled, a noticeable void began to appear in terms of people who could see systems in its totality. Writing a good program is one thing, getting it to interface with other programs to form a whole system is something entirely different. By the turn of the century, the industry started to talk about such things as "Enterprise Architecture," "Business Processes," "Business Rules," "Business Analysis," etc. Further, new conferences, trade groups, and job titles began to emerge. Today, programmers are considered a dime a dozen and the stock of a true analyst is on the rise.

All of this is indicative of the industry trying to reinvent systems theory. In reality there is nothing new here as systems analysis is systems analysis. But as companies implement these concepts and job titles again, they are a bit uncertain as to where they fit in and their relationship to other Information Technology functions.

CHARACTERISTICS

A Systems Analyst goes by many names these days; e.g., Business Analyst, Enterprise Architect, Systems Engineer (my personal preference), etc. Nonetheless, we are talking about a person whose mission is to study the information requirements of a business and design a total system solution to satisfy them. Further, the analyst is responsible for specifying the software requirements and, as such, is considered the intermediary with the programming staff. The personal characteristics of the analyst are considerably different than the programmer. Whereas the programmer tends to be more introverted and focused on technology, the analyst tends to be more business oriented and extroverted. Analysts possess good communications skills (verbal and written) to effectively work with both the end-users and the programming staff. They know how to conduct an interview and make a presentation (salesmanship). In addition, they tend to look at the bigger picture as opposed to just a portion of it, and possess an entrepreneurial spirit.

The analyst understands the business problems of the end-user and is intimate with the operation of the user's department. In other words, the analyst can comfortably walk in the shoes of the end-user. If they are doing their job properly, analysts make excellent candidates to assume responsibility in the management hierarchy. But because analysts were in decline for so many years, this hasn't happened for quite some time. The last time I heard of a systems analyst graduating to a major management position was Dan Boone who was made President and COO of Armco Steel in the late 1970's.

If systems analysis is performed correctly, programmer productivity should improve as analysts should be providing good specifications for application assignments. In the absence of systems analysts, considerable time is lost by the programmer who has to second-guess what the end-user wants. Inevitably, this leads to rewriting software over and over again. Good data and processing specs, as provided by a systems analyst, will improve programmer productivity far better than any programming tool or technique. This means programmers are the beneficiaries of good systems analysis.

This brings up an interesting point, what should be the ratio of Systems Analysts to Programmers in a development organization? Frankly, I believe there should be twice as many analysts than programmers. By concentrating on the upfront work, programming is simplified.

Let me illustrate the point by using the following triangles representing the total amount of effort in a project (as an aside, I picked this up from my customers in Japan who share my opinion):

The triangle on the left represents the traditional approach whereby there is twice the number of programmers to systems analysts. Under this approach, considerably more time is spent producing software to satisfy poorly defined requirements. The Japanese point out the bottom of the triangle is actually bottomless as it means more time is needed to complete a project. Compare it to the triangle on the right where there are twice as many analysts to programmers. Under this scenario, more time is spent analyzing the problem, designing the system, and producing better programming specs. Consequently, the programmers do not have to second-guess what has to be performed and can go about their work more productively.

The problem though is that Systems Analysis is considered to be somewhat of a nebulous concept to management. Programming, on the other hand, is more tangible and easier for people to grasp; you are either writing code and producing a program or you are not. Therefore, the mindset in management is that you are not being productive unless you are coding, hence the inclination to shortcut systems analysis. This is a key reason why Systems Analysis collapsed in the 1980's. And this is why it is necessary to provide training so management appreciates the need for systems analysis. Frankly, I have found management can be very supportive if it is presented to them properly.

CONCLUSION

Whether you call them Systems Analysts, Business Analysts, Systems Engineers, or Enterprise Architects, it is very encouraging to see this vital function being reintroduced to companies. As far as I am concerned, it was inevitable. I guess companies finally figured out you cannot satisfy your systems problems simply by using better programming tools and techniques.

We are also beginning to see the resurgence of related trade groups to replace such groups as the Association for Systems Management (ASM), for example:

The International Institute of Business Analysis

The IIBA appears to be picking up where ASM left off, including certification. Whereas ASM developed and offered the Certified Systems Professional (CSP) certification years ago, IIBA wants to create something similar.

All of this is indicative of how the industry is trying to reinvent systems theory. Whereas such systems work was well known up until the 1980's it was forgotten over the last twenty years due to the emphasis on programming. Fortunately, companies have finally realized the importance of systems work and are trying to get their houses in order. I guess what goes around, comes around.

OUR BRYCE'S LAW OF THE WEEK therefore is... "Good specifications will improve programmer productivity far better than any programming tool or technique."

"PRIDE" METHODOLOGIES FOR IRM

MY "PET PEEVE OF THE WEEK" IS "SOFTWARE DOCUMENTATION"

I've been researching Internet shopping carts and gateways to merchant accounts lately and, believe me, there are a lot of them out there these days. Not long ago you heard me complain about the lack of standards in web page design, but now I want to address the horrible state of software documentation. Back in the 1960's and 1970's, when you purchased a software package, you were lucky to get any documentation with it, mostly just source code. But frankly, I don't think we're any better off today than we were 30 - 40 years ago.

The shopping cart I've been working with is one of the most popular products out there (I won't mention the name), and it has a lot of functionality from a programming point of view, but it is a pain in the ass in terms of being able to tailor it to our needs. Oh, the facilities exist to tailor it, but the documentation is severely lacking. Consequently, you have to spend a lot of time searching for answers and experimenting to get what you want. The vendor claims the screens of the product are very intuitive and easy to use. Well, for basic shopping, maybe they're right, but if you need to adapt it to suit your specific needs, it is one of the most cumbersome products I've ever seen.

First, understand this, just because you deliver a product with a PDF file doesn't mean you have fulfilled your obligations as a vendor. The documentation we received is unstructured and difficult to wade through, regardless if you know how to search through a PDF file. Search will only help you if there is something useful for you to find. For example, there is nothing in the software's screens or documentation to explain the various field entries in terms of what should be entered, default and valid entries, its physical limitations, and how the fields are used. No, you are left to figure this out for yourself. And, to me, this is the Number One cause for slow startups in the use of shopping carts.

I believe the people who write the documentation are the same people who programmed the product, which is not a good thing, since most programmers know nothing about how to effectively communicate with human beings, only with computers. Consequently, I believe merchants are only using a fraction of the shopping cart's capabilities.

You would think by now software vendors would have their act together in terms of producing decent documentation. Think again.

Such is my Pet Peeve of the Week.

eBOOK: THE BRYCE IS RIGHT!

Folks, be sure to check out our eBook entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

http://www.phmainstreet.com/mba/bryce1.htm

We have also produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

http://www.phmainstreet.com/mba/bryce1.htm

While there, look for our MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from Jeff Fabor in Cincinnati who wrote me regarding last week's essay, "Parkinson's Law in I.T."

Jeff writes:

"Your comments on Parkinson't Law makes a lot of sense, but is there anything we can do as a consumer?"

Thanks Jeff for your note,

Good question. We've seen technology grow in leaps and bounds just in this century alone. But perhaps it is changing too fast. Too often I have seen products delivered prematurely with a lot of bugs in it. Vendors would rather have the consumer shake out their product for them as opposed to thoroughly testing it themselves. This disturbs me greatly, which is why I no longer beta-test software anymore; nor am I in a mad rush to upgrade software. Vendors such as MS don't exactly have a good track record in terms of delivering quality products on their initial release. Consequently, I now take a "wait and see" attitude. Most people like to rush out and get the latest updates in fear of "falling behind" or so they can proclaim they are "state of the art." As for me, I would rather look carefully before I leap. State of the art is whatever I want it to be, not what someone else wants it to be.