Table of Contents
Introduction
I believe, and this might be a bit controversial, that many people write code, but not all of them are programmers. Programming has nothing to do with tools, languages, frameworks, IDEs per se, it has to do with your way of thinking. The process you follow to analyze and decompose the problem successfully, then to pick the right tools and use them correctly, without abusing them. My math professor, at the university, used to say: “Don’t kill a fly, with a shotgun”.
The people
Do you know how to think? You know how to code. But do you know how to think? How to analyze a problem, its included parameters, its mutations (if exist and needed), the optimizations that might be required? It’s not only to know the requirement analysis techniques, but trying to find the right angle to analyze the problem. Is it easy? No. Is it obvious? Neither.
An example: Let’s say you are in a hospital and in a specific clinic. You walk around. Let’s assume the operation rooms are at the same floor. Do you know which corridor leads to the operation rooms area? Probably not. Or probably you know it by a sign with an arrow and a message hanging from the ceiling. But if that sign didn’t exist how would you know? The corridor that leads to the operation room should have specific features:
- Different color, even just the sides of it
- Should be wider
- No chairs or other objects (coffee machines, chairs, big medical instruments) should be allowed on the sides
- The corridor’s surface material (I think it is called profile) should be different to minimize the friction with the wheels of a wheelchair or a stretcher.
- The corridor should be one with a slope, in order to achieve greater speed when pushing the wheelchair or the stretcher.
Details? For common eyes maybe. But for a engineer? This is the problem that had to solve. The best way so the medical staff to reach as fast as possible to the operation room without anything stopping them from doing so. We programmers face similar problems, but instead of buildings, patients and medical staff, we have software architecture, codebase, stakeholders, users, hardware limitations or cloud costs, optimizations issues, database indexes fragmentations, time estimations, insufficient or blurry requirements.
Plus, unfortunately, many think that because nowadays we have unlimited RAM, hard drives, and network bandwidth cause of the modern cloud infrastructures, that requirements come without any limitations. And this leads to bad software design, and ugly implementations. Plus that companies push for unrealistic deadlines, cause “everything is automated now”.
The domain
A major issue in university computer science depts. (and in companies too), is the lack of teaching and supporting requirements analysis in depth. How many times at the university were we forced to solve a dog, cat, pet, problem? Or analyze ultra simplified unrealistic requirements of a fictional company? Yes you have to start from somewhere. But don’t stay there.
Α graduate after the university, joins a company and suddenly the cats and dogs examples become “Calculate with threads the risk when Japanese NIKKEI is down and sun rises from the West”. And you don’t know if the programmer will be able or willing to understand the problem or even more, break it into smaller ones.
A former boss of mine told me some time ago, and I quote his words: “Not all programmers are willing to learn and understand the domain“. Although my position is clear on that topic, I totally understand it. We were never trained to pay attention, understand and learning the domain. Even today, we deal with articles, books, videos, about zillions of tools, new languages, frameworks, new infrastructures, agile, scrum, lean or whatever the industry and the community produce, but we never took the time to define how we can use all the above in our domains, cause we don’t know how to use them correctly and we don’t know the domain too. Too much noise rather solutions that make any difference.
The tools
If we had a better understanding of what the fuck we do, maybe we wouldn’t need a new whatever framework every month. And unfortunately many companies force the use of specific tools for marketing reasons or bilateral relations, not because the programmers actually need them. Leave aside the fanboys. In the endo of the day we don’t need more tools, we need programmers to think in better ways.
First we had the languages war in the 1980s. Then the OS war. After that the browsers war. And it keeps going. PHP frameworks, Ruby frameworks, ASP.NET and ASP.NET Core now, Python and Node.js. Close to that we had a JavaScript frameworks boom too. jQuery solved many problems indeed, but then a hell broke loose and we lost track and control. There was a fashion that each one of us should build the new JavaScript holy grail. A new JavaScript framework to solve the same problem in a different way. Why?
Now we have the infrastructure and automation boom (CI/CD Docker, Kubernetes, Open Stack, Azure, AWS, Chef etc.). Suddenly crappy, old legacy systems, with bad support or even underpaid or inadequate programmers, bad managers or bad companies in general, have to be shifted from monoliths to containers. Well you just moved your code base problems to the cloud and added some maintenance ones.
But we are not done yet! Agile is in our life too. Companies shout that they are agile, apply scrum, lean, whatever methodologies, and the only things they are actually doing are standup meetings every morning and use Jira. But at the same time they keep using the same dinosaurs-ish rigid structures, managerial strategies and flows that any agile flexibility is crashed by them.
The impact
Nowadays, besides a super fragmented labor market, the programmers have become a little bit “lazy”, and it’s not exclusively their fault. Many times the first words Ι hear are “… find the libraries”, and the companies push to that direction for the sake of deadlines but sacrificing the quality and not only that. Ηowever The first words should be “… let’s analyze”.
Unfortunately, our science is still young and immature compared to medicine or architecture, but at the same time is so fragmented and moving so fast that in the end it hurts the programmers. What I can say for sure is that we need to slow down and stop embracing every new toy that is out there.
What’s next?
I have no fucking idea. It’s a topic of huge research and unfortunately I am on not at the top of the food chain to give you a hint. If I worked for Microsoft for example I could tell you more. But what I can tell you for sure, is that we must slow down, cause when you run too fast in the end you crash, you don’t arrive to your destination faster.