The role of software developers

I came to understand that generally accepted stereotypes about software development don’t reflect the essence of this activity quite long time ago. That’s why I want to provide a short insight on this topic. Perhaps it can help you to see the problem from the other point of view.

What do you call a final product? “That’s obvious”, you might say. The final product is a program that helps people reduce their intellectual efforts and optimizes various processes. Besides that, the program itself is nothing but a list of events that your PC computes.

Low-level events are simple commands on memory processing. For example, on adding two values you can insert the sum in a memory cell or compare between them in the register and so on. To sum up, it’s all about the PC doing a task for the user – let’s call him a program client.

Naturally, there would be no need for software developers, if a client could ‘talk’ to a PC straightly. But unfortunately, here we are facing two main issues. Firstly, among the Earth’s population, you can barely find a person to express his thought by means of the low-level commands. Secondly, we face the main problem due to the client, who seldom understands his needs and can’t describe the field he wants to have automatized in most cases (leaving alone his knowledge of the subject’s details).

That’s why a client usually needs a third-party monitor. It should be a person who can answer to client’s needs, analyze his capacity. The first facilitator of PC and client communication is a Software Analyst. On the one hand, the analyst should have an appropriate skill-set in the field that he automatizes. On the other hand, he should be able to communicate easily with the software specialists.

The next link in the software development chain is a Software Architect. This person needs a complete understanding what software development is. Large and complicated projects can’t be successfully completed without such specialists. A Software Architect outlines main structural points for a system body. On the other hand, this job includes transforming client’s data (that we get from the analyst) to a model description. The description is usually written in a professional IT language that already contains rather PC related terms than the subject field ones. At this stage, if you look through the model description text, you can still find some informal, ‘common’ words and expressions.

Eventually, it’s a Programmer, who holds software development process at the last stage. The skill-set for this position stands in between formal, ‘technical’ and informal, ‘human’ languages. For all the positions, stated above, you can use common words and expressions, but the programmer can’t. The PC’s system wouldn’t get his commands clear. The commands, containing even the slightest syntactical mistakes, will be ignored by a programming language, or, furthermore, computed according to its default syntactical rules. For example, in strongly typed programming languages it’s possible to set a function 3+ “Jim”, but the result greatly varies depending on the language rules.

To my mind, a programmer can be compared to a customs officer, serving as a human and machines world gatekeeper. He mustn’t let the unclear statements passing by.

Software development teams usually face conflicts between Programmers and the Developers, who think in a common language. Because of their lack of knowledge or laziness, Developers often drag programmers into the ‘language formalization’ process. This isn’t the best decision in most cases because a Programmer would usually rely on his problem understanding and individual experience while writing a code. The second problem here is a weak understanding of PC’s limits and functioning modalities. Sometimes, programmers can be forced to make a decision, that doesn’t comply with PC’s standards. After all, this situation reminds me of a translator, speaking to an indigenous tribe about a wristwatch, though they don’t understand the concept of time [3].

After this stage, formal language is automatically transformed into simple commands. From now on, there are only two options: the program will rather work… or not. The worst situation is when the program does work, but not exactly the way the client wanted it to do.

Dear Software Testers, Designers, System Administrators, Technical Writers and Project Managers, I beg your pardon. I’ve simplified the software development process to share the main idea: a Software Developer is nothing but common-technical languages translator.

Naturally, a good translator not only speaks both languages but also possesses knowledge in the subject field.

Unfortunately, software developers’ teams suffer from a misunderstanding. An analyst would often misconceive client’s muttering; Software architects are always trying to stuff the structural model with a data from the analyst; Programmers suffer the most because they need to transform all the distorted data to a formal programming code [1]. So when it comes to PC’s computing the code, it executes only those commands that were clear enough (usually, not the exact thing the client wanted to see) and here we start again…


Software Development is a process of subject’s technical requirement translation to a programming language. To simplify the sequence of actions, developers should create and use subject’s field language [2].

The developers who deliver unclear data or commands just don’t understand their role in the process.

In addition, we can claim that programmers who have a decent working background in some fields are valued the most because of their capacity to get what a client is trying to say and transform his needs to a programming language a machine would be able to work with.

Very often a client doesn’t understand these peculiarities of the software development process, so a programmer is suggested to play all the roles: an analyst, an architect, a tester and so on. Although, very few of the specialists are qualified enough to perform all the processes.

With the computing devices’ rapid development, programming languages evolve either. A programmer operates abstract terms, which stand for lots of low-level commands. That’s why I am sure software developer position will drastically transform with the progress of an artificial intelligence. In this case, data structuration will be the main goal for developers’ teams, not the algorithmic coding. After all, understanding another person is the hardest part of this job. 🙂



    1. Emil Manukyan, Programmers and the human factor.
    2. Eric Evans, Domain-Driven Design. Tackling Complexity in the Heart of Software (DDD).
    3. Jason Palmer, Amondawa tribe lacks abstract idea of time, study says.