Should Your Software Architect, Engineer, and Analyst Know How To Code

         The question of “Should Your Software Architect, Engineer, and or Analyst Know How to Code” has become a hot button item these days. The division of labor occurred in part, because many companies saw the need to have actual Software Architects and Engineers instead of the generic Programmer of years gone by as is seen in the industry today. I know, because I am one such programmer. The problem is that in the late 1990’s and in the early 2000’s the computer industry took programming and divided it up into component parts which are as follows:

1) Software Architect

2) Software Engineer

3) Software Analyst

4) Software Developer

5) Software Coder

Each of these positions formerly where done by what was called a Programmer. A programmer would perform the following functions

1) Map out the program with input from the people who will use the program (High level flow charting based on requirements) (Architect)

2) Create a functional flowchart of the program develop logic and prototype the program in scripted notation (Engineer)

3) Test the logic of the program and develop an analytical model of the program (Operational flow chart and Pseudocode) (Analyst)

4) Takes the Operational flow chart and Pseudocode and develops beginnings of executable source code for program execution based on language needed (writes sample program and determines best language to continue to write) (Developer)

5) Writes the code in the chosen language (fills in the blanks of the developer) (Coder).

These five tasks have been divided up between the Architect, Engineer, Analyst, Developer, and Coder. The problem arises from the expectations of large\medium companies’ vs small companies. In small companies it is very common to see these roles collapsed into one another. However, as companies grow these functions become separated. Only in small companies would you expect to see the programmer perform all 5 tasks. The fact of the matter is that large companies require very involved and complex programs and system to perform their tasks. One size fits all just does not work in the large company environment, as any person who has went from Coder to Architect will tell you. 

Most Software Architects, Engineers, and Analyst know how to code, because they began as coders. However, what I have seen in the past few years is a situation where Software Architects, Engineers, and Analyst , know very little about writing or creating programs (Coding), what they know is how to gather requirements and turn those requirements, into a flowchart (Analytical, Functional, and Operational). This is exactly what their job is. As I began to look at architecture, engineering, and Analysis from a different light I began to see what the problem was, and that is scope. As the scope of a needed program becomes greater, sometimes it works to your benefit that the Architect, Engineer, and Analyst never wrote a program before. This is because the language and technique the Architect, Engineer, or Analyst might choose is based on their personal bias, not the customer’s needs. I have seen small web site programmers ignore totally viable programming languages to soothe their own egos and stick with a platform that does not give the customer what they want. This eventually is a bad thing to do.

I am not a fan of this division of labor, but I am in favor of getting the best results out of people for the customer. This is where my spin on this begins. In fact, I do believe the Architect, Engineer, and Analyst should know how to write code, even though in their actual jobs, the lack of coding skills is not a deal breaker, it is one for the desired section, but not the required section.

Ah yes, Desired and Required, these are the most misunderstood words on both sides of the table in an interview. Let me explain, whenever I answer a job request I look at the requirements as cake, and the desired attributes as icing on the cake not inclusive of the cake, but not extremely exclusive of the cake, but also not required. If I may, allow me to delve into a bit of hyperbole to make a point:

My Desires: I want hot chocolate, served to me in my 24oz mug, every morning, by Halle Berry, Venus Williams, Mary J. Blige, and Sandra Bullock. (Yeah, you see my desires can be whatever I want them to be, no matter how ridiculous they are) *No disrespect intended just engaging in hyperbole to show the ridiculousness of desires.

My Requirements: I want to wake up in the morning not covered in 6ft. of dirt, (hot chocolate, and those wonderful women, that’s icing on the cake, as if my desires were ever going to happen or should ever happen.)

You see desires are what we want, or even fantasize about, and should not be used to determine the process of hiring, if so put it in the requirements section., but you see you can’t put desired skills in the required section, because to an extent desired talents and skills are not the primary scope to the request.

Expecting the Software Architect, Engineer, or Analyst to code is equivalent to expecting the Architect, Engineer, or Analyst (Inspector), of a building project to be out there pouring concrete, laying bricks, and framing the building structure, yeah that’s a good desire, but really should it be a requirement. Just remember if they are doing that, they are not doing the job they are being paid for.

Just some food for thought.