Mr. Smith had a serious headache, so he went to see a doctor. The doctor told him: “I think you should get some insulin.”
Mr. Smith replied: “Are you crazy? Insulin for a headache? Why do you say that?”
The doctor answered: “I’m an endocrinologist. I treat people with diabetes; all my patients get insulin and feel much better.”
Then Mr. Smith went to another doctor, complained about his headache and the doctor told him: “I think you should try radiotherapy.”
Mr. Smith replied: “Are you crazy? Radiotherapy for a headache? Why do you say that?”
The doctor answered: “I’m an oncologist. I treat people with cancer; all my patients get radiotherapy and feel much better.”
Well, I think you get the idea. Now let’s talk about software development…
The Insane Arguments About Software Development
I’ve been working as a professional software developer for more than 20 years now. This field is only getting more complex and diversified with time. Today we have dozens of different programming languages in use. We have people building Web sites and mobile apps, and software projects that may be classified as front-end, back-end, server-side, real-time or embedded. All the people working on these different kinds of systems call themselves software developers. And they are constantly arguing with each other.
Our personal opinion is based in our experiences. Why should a C++ programmer writing a server-side system have a similar experience to a JavaScript programmer using frameworks to build the UI of a Web site? Why should they agree on the relevance of Design Patterns? Why should they have similar opinions about Agile software development? How much these two guys have in common regarding the importance they give to non-functional requirements?
It is perfectly normal that for one software developer Design Patterns are extremely important, while another programmer has absolutely no idea about the difference between a Facade and a Decorator. I can also understand why some software developers are enthusiastic about Object-Oriented Programming while others think that Functional Programming is awsome. These are different opinions based on different experiences.
I think that most discussions about software development look like this:
“The best way to build things is using a hammer.”
“Wrong, if you want to build good things you must use a screwdriver.”
“Nobody needs such complex tools, I can build anything using chewing gum!”
“You are so primitive, I only build things using Lego blocks!”
Worse than the discussions about tools, are the arguments about methodologies. For example, it is easy to find software developers fighting each other because of their opinions about Agile methods. Some people will tell you that Scrum is wonderful, others will say that there is nothing better than Kanban, but many programmers are sure that Agile is not useful and in some cases may even cause real damage.
The Solution
In my opinion we need to stop talking about “Software Development”. It is too abstract, too generic, and as such not useful to have proper discussions. We may have a discussion about implementing “a server-side system handling thousands of requests per second with less than 100ms average latency”. Or perhaps we may discuss building a “highly responsive Web site that adapts to different browsers running on all kinds of screen size”.
The same is true about software development methodologies: we cannot ignore the factors that may influence the success or failure of an approach. What is the importance of the company culture, the team size, the developers’ skills and the system complexity? Have these developers built a similar system in the past? Were they using existing frameworks? Did the final system have 100,000 lines of code or a million lines of code?
It is very easy to observe our past projects and classify them into successes or failures. It is a bit more difficult to try to understand the many factors that may have influenced their outcome. It is even more difficult to imagine the impact of different conditions. We should be very careful to understand the reasons people may have different opinions before we start arguing with them.
Effective Software Design 
As usual – great post.
Completely agree with you. I’m too, sick and tired of endless discussions about the latest buzzword, language, tool and framework.
The most funny fact is that almost all shared/common things for various software projects laying outside of design or coding areas. Requirements management, issue/dependency tracking, testing methodology, integration and deployment patterns are pretty much the same for all the spectrum – from Pokemon-style games to embedded micro-controller programming.
I agree partially. Your point about the factors being important is spot on in my experience. However when using consulting companies to do the initial development and internal resources to do updates and support, the conversations around development practices need to be had to set expectations or quality type constraints. The same is true when doing co-development.
Endless discussion and argument about technical architecture, plumbing and technologies, dominates nearly all conversation I hear. I’m sure there are many developers around who think that is all there is to computing. Methodologies? Doesn’t that today mean recursively hacking (sorry refactoring) at a problem until one hits the solution?
Easy to say. I know many people that will argue over night protecting Java over .NET and vice versa. And these two almost parallel languages, not to mention another technologies stacks. Arguing in that case comes from lack of information. Like in doctor example you should not come to javascript developer to write a driver for linux.