The New IT Professional

My past two positions have revealed a couple of things to me.

1. The role of developers have changed

2. Programmer/Analysts are an increasingly rare breed

When I made the transition to Analysis from Programming, I worked with programmers of the Microsoft era. Let me explain that. Since the advent of Microsoft technology and programming interfaces, the role of the programmer has changed. Now a programmers function revolves primarily around coding. The Systems Design and Analysis skills that were the cornerstone of my education in college are overlooked for the most part. Young programmers would be hard pressed to spell SDLC let alone recite the meaning of the acronym. I'm not knocking young programmers, I'm just saying that with the "right-now" mentality that seems to be permeating our industry, some fundamental strengths that should be second nature to a programmer are now sorely lacking.

My first position as a Business Analyst required that I perform these tasks:

* Requirements gathering

* Development of both a Business and Technical Use Case

* Development of a Prototype (This was not required, but once programmer...)

* Screen flow and layout

* Database Design

* Development of SQL to build tables

* Development of SQL to modify tables

* Development of System Test Scripts

* Execution of System Test Scripts

* Assisting programmers in the development of Unit Test Scripts

* Execution of Unit Test Scripts

I was surprised at the fact that most of the functions on this list were functions that I performed as a Programmer/Analyst most of my career. I scratched my head wondering what the "Programmer/Analysts" that would be coding the system could possibly need beyond that. I was more than a little jealous of the fact that they got all of this information without having to figure it out themselves like I did most of my PA career. I quickly got over my jealousy when I realized it created a job for me. It also compelled me to take a look at what goes into the development of the Programmer/Analysts of today.

Many new developers entered the IT field by taking a class (or classes) in the hottest programming languages of the day and becoming "certified". Schools, recognizing the demand, developed programs that would make people programmers quickly at the sacrifice of good, solid analysis and design skills. They tend to touch on Rapid Application Design techniques but not on what was the true basis of RAD. In my humble opinion, one cannot have a firm grasp of RAD without a thorough understanding of the Systems Development Life Cycle (SDLC). As much as some folks would like to do away with it completely, you cannot because it is so useful for developing solid systems. I think we can see the decline in good analysis in many of the software products produced today. Ask yourself, "How many people outside of IT knew what a patch was 10 years ago?". Not many. I worked on IBM systems at the start of my career and patches were few and far between and most users never knew what a patch was or that a patch had been made when they logged into their systems the next day. That was IT stuff.

I read an article about a Truck driver taking a 6-week course in programming who left his job as a truck driver and became a developer earning (at the time) a pretty hefty salary. This was in the throws of the IT boom, but it still speaks volumes. We are now seeing the fallout from the get-trained-quick days. Developers with little more than coding ability.

Even with all of the information I provided to the programmers in my first BA position, they still required quite a bit of hand-holding. I went to my Project Manager to see if there was something I was doing wrong and she said these words "They just don't make developers like they used to". She was so right.

But like I said earlier, this creates an opportunity for us older IT pros who DID have to learn the Systems Development Life Cycle, DFD's, Flowcharting and all the "boring" stuff that programmers are not taught. These positions go by different names but all revolve around Planning, Analysis, Design, Testing and Functional Integration (low and behold...the much of the SDLC): Business Analyst, Systems Analyst, QA Analyst, Project Coordinator, Project Manager, Application Manager, Integration Specialist and the list goes on. Roles in IT have had to change because of the boom in demand a few years back. The demand was filled by folks who may have had coding talent, but not necessarily the skills to build a complete and solid system. What used to be accomplished using a Project Manager, Systems Analyst and Programmer/Analyst is now being broken down to Project Manager, Systems Analyst, Business Analyst and Developer. The added "Business Analyst" is the Analyst part of what used to be the Programmer/Analyst. So does the Programmer/Analyst still exist? Seemingly only in title, and that is rarely used anymore in favor of Developer. Many roles that the Programmer/Analyst used to be required to do now fall to the Business Analyst. Tasks like Database design, SQL development, Screen layout and Testing are now on the plate of the BA. So now some older Programmer/Analysts (when I say older I'm talking about Pre-VB programmers, like say from 1992 and earlier---I graduated in 1990 and I feel like a sage when I talk to younger programmers who have never heard of SDLC...they think it's a language) have to make a choice, concentrate solely on programming or concentrate solely on analysis because that is what the market wants. We are blessed to be able to have that choice.