Is there any science to software development?
What's the root of elitism in the software industry?
In this video I discuss how I'd answer these questions, prompted by this comment and article.
We're a place where coders share, stay up-to-date and grow their careers.
Is there any science to software development?
What's the root of elitism in the software industry?
In this video I discuss how I'd answer these questions, prompted by this comment and article.
It's just people tend to confuse science and math or hard science whereas there is a scientific method which can be applied to any fields even out of hard science to litterature or history ;) For example Deming PDSA (Plan Do Study Act) is based on Walter Shewhart scientific pattern, which people think it's PDCA on which is based scrum. It's not a hard science on the business requirement parts because there is some human part, that doesn't mean there isn't a science. So this has nothing to do with choice of such or such programming languages, frameworks, etc. they're just tools. Like architecture, it's not a bunch of frameworks.
As much as I agree, software development is subjective; itβs important to understand, it's a real form of engineering. Engineering could be described as using scientific principles, to design and build systems.
Like all fields of engineering; software development is governed by scientific fact as well as the environment. There are 8-bit's in a byte, the speed of light in glass is approximately 200000000 m/s (or c/1.5). We canβt change these facts. some may say we could make a 10-bit byte. Well yes, we can make a computer which uses 10-bit bytes, but it would be incomplete with the environment, as all modern technology takes a byte to be 8-bit's as a fact.
As software developers and engineers, we design, build and produce systems that comply with scientific restrictions. We also work to overcome these restrictions, to innovate and progress whats posable.
Most of we do is not possible if you don't understand the science behind it. and like any good engineer, we make subjective choices based on our own understanding of computer science, electronics, and physics.
For further actions, you may consider blocking this person and/or reporting abuse
Sloan -
shammisharma -
Ben Halpern -
Ben Brazier -
Once suspended, marek will not be able to comment or publish posts until their suspension is removed.
Once unsuspended, marek will be able to comment and publish posts again.
Once unpublished, all posts by marek will become hidden and only accessible to themselves.
If marek is not suspended, they can still re-publish their posts from their dashboard.
I would say it definitely happens in the professional realm. It isn't quite as heated as online toxicity, but it can cause some similar negative feelings. I think it is all about how software development is almost entirely subjective which leads to difficult conversations.
Software development is subjective because there is no science to it. There is computer science which is the basis of it, but that is more of a mathematical discipline. Modern programming languages are abstractions on top of the 1s and 0s, so anyone is free to create or use a programming language for a program as long as it can be translated to run on a computer. Different developers have different tastes and different types of programs could benefit from different programming language features. It is someone's opinion making that choice, not a well-defined set of rules based in science.
I think that the subjectivity is the root of any elitism in development. Developer A is writing a program a certain way using a particular language, developer B tells them that they shouldn't be writing it that way or using that language. I feel that represents the format of any negative interaction regarding software development, but there is no clear winner.
This manifests itself in the workplace regularly. It may not be hostile like online comments, but it can be difficult to navigate. At times, being a software developer can be more about working with people than working with code. Everyone thinks differently and it can be hard to reach a consensus. When developers cannot work together effectively, it leads to different styles of programming or a mix of tools being used. This negatively impacts the product, the budget, and the overall team morale. One developer could be concerned with getting a task done as quickly as possible with no regard for future problems, another developer might have heard that functional programming is the new hotness and they want to rewrite all the things, and a third developer could be jaded from hastily implemented code or jaded from adopting something that was not the right fit. Combine that that with personalities and emotions, it can quickly turn into a heated discussion over what is best.
To avoid this at work, I recommend a few things: