The Importance of Non-Programming Programmers

I think most of you would agree with me when I say that software is becoming as important as ever these days. The obvious examples that come to mind include the software financial institutions use, e-commerce systems for online shopping, among other mission critical systems. As you can probably conclude on your own, the more software becomes the focal point for more businesses, not just the demand for but, the need for talented and highly skilled software developers is going to increase dramatically. As a programmer, it makes me want to know how I can capitalize best on future opportunities that I might come across. (and I'd like to emphasize the ‘capital' in capitalize).

The first thing that comes to mind is to become the best programmer I can be. But when I dig deeper, and look at what that really means, I see a deck of cards that is not stacked in my favor. Why? I blame it on all the non-coding work a programmer has to do. When I say ‘has to do' I am assuming you want to not only write good quality code, but you also want to ship it out the door and get paid for it. So what is all this non-coding work you ask? Here is a list I compiled from my copy of Code Complete:

• System Specification
• Requirements Analysis
• Architectural Design
• Detailed Design
• Unit Testing
• System Testing
• Maintenance

Now bear with me here. If you code somewhere that has a separate person performing each of these functions and you all collaborate on projects, you can stop reading this if you'd like, as most of what I'm going to say won't apply to you. And for you picky readers out there, yes, I understand not every project needs detailed UML diagrams or PDL comment documents before code is written. I'm generalizing to a degree here while being slightly biased towards those carrying out projects mostly or all on their own.

You can probably see that in addition to writing all the code you are also responsible for deriving business rules from the business processes that will make up the system, you also need to determine how the UI is presented, how the database will be designed, which design patterns might best fit certain components of the system… I could go on here but I think you get the idea.

When was the last time you met a business analyst that could contrast early-binding versus late-binding or knew how to create a strongly-named assembly? This is where as a programmer, your job starts looking ugly. Maybe as a programmer I'm biased but, I think this has always been a little one-sided. To date, I think many people and/or organizations in the software business have gone about tackling these issues the wrong way. Some just turn the other cheek, while others struggle with it, claiming all these things are important to them, but never actually make them a priority. Most businesses don't realize the treasure they hold when they have one person that can accomplish each of these steps in addition to doing the coding.

So what's the solution for the lack of expertise across each phase of programming? The non-coding programmer. Non-coding programmers are people such as requirements analysts, GUI designers or graphic designers, testers, etc. They're good at the things programmers are told they should pay attention to, but don't really want to deal with and aren't very good at. Programmers enjoy coding mainly, not learning how to create a drop-shadow or bevel for good looking icons.

Programmers also enjoy learning development platforms, not how tax for each state is calculated. Also be aware, just because these people aren't coders does not mean they don't have to be a techie. Don't get someone to do unit testing if they think ‘VB' is some kind of beverage.

As an organization, employing non-coding programmers can benefit your software development in many ways:

Common Ground: Reaching an understanding between you and your client on anything can be challenging. Requirements aren't always clearly defined and can leave your coders wondering exactly what it is they are supposed to code. Having a non-coding programmer define what's been required for the system and then communicate that to the coders in a language your coders can understand provides common ground for your company and the client to stand on. I've had to read too many very poorly written design documents to hear arguments on this one. I mention this one first because it has to happen if software is going to move forward. With software being as complicated and important as it is, it is vital that something like this happen.

Better Quality Code: With your coders having more time to focus on their main objective, writing solid code is more likely to be the outcome. Also, your coders will go into coding having well defined specs written. They should already know or have a general idea about what kinds of methods need to be coded, what those methods should or should not accept as parameters and so forth.

Well Tested Code: As before, this stems from clearly written requirements. With them, building and executing unit tests goes more smoothly. Having another non-coding programmer that can read between the lines of error messages can be handy here. For example, if I were unit testing VB.NET code and got an error like “Invalid Cast Operation” I know what type of call generated this error. If I had print outs of the source code I might be able to locate the erroneous line for the coder.

Less Time Spent On Maintenance: Not including enhancements or new features, code maintenance becomes less of an exhausting process when your code is well written and tested properly. The non-coders can also help decide whether something is really a bug or just a lack of knowing how to use a feature properly. This cuts down on time the coder has to spend servicing those requests.

Better Overall Organization: Having an impartial 3rd party (non-coder) involved in decisions like which bug tracking system to use or how to setup the source code control hierarchy can be helpful in keeping your code organized and accessible to the non-coders that need to get to it. Naming source code control folders like “asp includes” might not be as clear as “commonly used web files” or “reusable web scripts”.

Having said these things, I do realize that software is still a relatively new practice when compared to other (more established) professions. It will take some time until the majority of coders/developers/programmers/whatever you want to call them are implementing best practices. What I feel is that for software to move forward, something has to give. That something is a remodeling of the construction of software itself, and who's involved in it and at what levels. Still being relatively young, I hope to have a front-row seat as these things change throughout the industry.

Do you think that non-coding programmers are a good idea? Who handles the non-coding programmer tasks on your projects? Talk back!