slashbinbash.de / Opinions on Software Development

This is a collection of personal opinions on different software development topics.

False Assumptions: The Root of all Evil?

In my experience, false assumptions are one of the most common mistakes that lead to bugs. False assumptions creep up everywhere, especially along abstractions and interfaces.

User requirements can be based on false assumptions about the problem that needs to be solved. Translating user requirements into software functions is another source of false assumptions, if the programmer is unfamiliar with the language or terminology of the problem domain.

Programming languages have many abstract concepts whose behavior cannot be correctly predicted, unless they are fully understood by the programmer. The programmer may draw wrong conclusions if their mental model is based on false assumptions about the code, or the system that the code is running on.

Operating systems behave differently depending on the version of its APIs, drivers, libraries, and the overall configuration of the system. Your program competes with other programs for resources like memory, threads, access to hardware, etc. Any system that is a black box from the point of view of the programmer, inevitably leads to the formation of false assumptions.

If you have false assumptions, you cannot make any reliable predictions about how your code will behave. Learn to recognize when you are making an assumption. Admit that you are making an assumption. Evaluate the risk of what would happen if the assumption were false, and estimate the cost of mitigating the situation.

It's better to admit that you don't know something, than to base your work on false assumptions.

What programming language should I learn?

It depends on what you want to do, but I generally put programming languages into three categories:

Most software developers that I know, know at least 3 or 4 different programming languages.

Should I make my project open-source?

I have a somewhat reserved opinion about open-source.

In my opinion, there are only a few types of projects that need to be open-source:

That's not to say that you shouldn't make your project open-source, if you want to join and contribute to the open-source community.

Resourcefulness and Optimization

I'm frustrated about software developers who have no regard for efficient resource management. The bloated and slow software that we use today, is a result of the industry and academia failing to address the cost of computing.

The truth is that every memory that you allocate, every function that you call, every thread that you create, every file that you open, every framework that you use, has a certain cost attached to it. This cost might seem insignificant to you, but it is not zero. You should always consider the performance and memory implications of your algorithms.

Considering the performance and memory implications of your algorithms is not premature optimization. It's good design! Making optimizations based on false assumptions, that's where people make mistakes.

The least that I expect from a software developer, is that they don't shrug off matters of performance, and instead search for solutions that strike a good balance between the resources that are required to run the program, and the benefit that they deliver to the user.

Elegant, Evil, and Clean Code

There are developers who are heavily invested in writing beautiful, clean, or elegant code by following the rules that are layed out by industry gurus. These gurus give the impression that there is a consensus in the industry about what constitutes good code. When in reality, these are just guidelines that are handed down by senior developers, who all have their own subjective opinion on how good code should look like.

I would argue that these words don't communicate clearly what it is that makes one solution better than another. Speaking of "elegant" code is highly subjective, and for most people a gut feeling. What seems "clean" to you might be incomprehensible for someone else. The use of "evil" may lead to dogmatic thinking about what is allowed and what is not allowed to be written in a programming language.

I would like to see developers who don't use words like "beautiful", "clean", "elegant", or "evil" to describe code. Instead, they should be able to articulate, in their own words, why one solution is better than another, given that both solutions produce the correct result. Otherwise, it is nothing more than opinion or personal taste.

Creativity in Software Development

I think there is a misconception when it comes to creativity in software development. What we need are developers that solve difficult problems in creative ways. What we don't need are developers who write code in creative ways.

Don't be creative when you write code. Write down what the machine has to do, as readable as you can. Try to make your decisions clear to other readers, so that there's no room for interpretation or false assumptions. If you can do that while minimizing the dependencies in your code, you are probably already better than the average developer out there.

Refactoring Code

You cannot reduce the complexity of a problem by refactoring code. Refactoring code will not make a problem less complex.

The only thing that makes software less complex is removing code. If refactoring code allows you to remove code, that's a win.

Otherwise, you are only rewriting the code in a way that you can read it. The next person who cannot read your code will rewrite it again. Don't assume that your code is more readable.

A Case for Software Engineering

Software Engineering implies that creating software is akin to building bridges, or constructing a hospital. I think that there are cases in which this is true. Language standards like the C++ ISO standard have to be considered when developing software with the C++ programming language. Decisions have to be made regarding the software architecture, i.e. how the different systems in our solution operate and communicate with each other. Frameworks provide the fundamental structure of our software. Hardware specifications and requirements have to be considered. Predictions are made about how the software will operate, including a risk analysis. Rigorous testing is done when software needs to be reliable and robust. Security aspects have to be considered when software failure may result in injury or death.

I guess in the end, you have to make up your own mind. I see myself as a software developer, I aspire to be a software engineer, but I'm not offended when someone calls me a programmer.