This is an opinion article about the state of affairs in the software engineering field. It discusses the real challenge and the real duty of a programmer. It divides programmers into four categories: Intelligent, Bandits, Helpless and Stupid with two additional categories of Naive and Ignorant. It talks about how a programmer must be familiar with a particular domain is not only able to code but actually to create solutions. And it touches on the failure of agile software development.
Failure of software projects defined as a miss of deadlines, budget overrun, missed functionality and malfunction is prevalent in the software industry. A lot has been written about the reasons for this situation, blaming unrealistic project goals, inaccurate estimates of needed resources, badly defined requirements, poor reporting, unmanaged risks, poor communication, immature technology, sloppy development practices, poor project management, stakeholder politics or commercial pressure. Most of these put weight on the management side of the development process, properly identifying it as a cause of these failures. In my opinion, which is based on years of observation, there is another factor of this misery almost totally overlooked or intentionally omitted – programmers themselves.
“Smart” Programmers
The common belief among society in general and among programmer society as well is that “programmers are smart”, that they recruit from the most intelligent part of the society. I believe that this is based on a false assumption that programming a machine is difficult. I dare to disagree with this assumption as in reality, writing code is no more difficult than writing a proper culinary recipe
The Nature of Challenge
Coding is not a challenge. In fact, code is the last thing anybody is willing to pay for (though, ironically, it is the most important thing that gets produced in the end). The real challenge, and the real duty of a programmer, is solving problems that customers face, most likely with code but not necessarily. These problems are usually only partially “technical”, often sociological, often complex, often wicked. As problem complexity grows, the required effort, intelligence, knowledge, and dedication to solve it grow as well, sometimes exponentially. Recognizing complexity, confining it and minimizing it is the ultimate goal of a programmer. This raises the bar so high that an average person might fail to present the sufficient personal qualities required for the job, and turn out to be relatively stupid.
As David Parnas states: “I have heard people proudly claim that they have built lots of large complex systems. I try to remind them that the job could have been done by a small simple system if they had spent more time on "front-end" design. Large size and complexity should not be viewed as a goal.”
The 4 + 2 Model
It is necessary to unambiguously define stupidity in the context of programming.
“A stupid programmer is the one that puts complexity to a software product that negatively impacts other programmers, customers or a whole company while achieving no gain from this fact and even possibly negatively impacting oneself”.
By putting complexity, I mean either failing to reduce the inherent complexity of the problem being solved with software, by using so-called “brute force” solutions or actually introducing of accidental (usually technical) complexity, that could be avoided if more thought and care was given to the solution.
By negative impact, I understand the increased workload, reduced efficiency, and higher cost.
The Great Misunderstanding
Programmers are technology-oriented. They get attracted to computing because of their technological bias. Their job though is not to write code as they often think, their job is not even creating software. Their job is to solve customers’ problems and software is just one of the means to do it. Sadly, seldom do they manage to understand this.
A Bitter Pill
I found this enlightening quote from David Parnas:
The most often-overlooked risk in software engineering is ‘incompetent programmers’. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.”
If the project is late, it is better to fire bad programmers than to hire more of them. At least, they will not get in the way of good ones.
one of the best articles I have read on CodeProject ever. I read it 4 times over the past month and made every lead in the mid-level software management team read it too... read more at https://www.codeproject.com/Articles/5061258/The-Psychological-Reasons-for-Software-Project-Fai
Your new post is loading...
