How to make good software?
How do you make good software? Apart from the fact that also woman makes good software (at least here with IMS) the question is not so easy to answer. Because software is complex. And good software? Paradoxically, it is less complex. Creating them is more complex. Because there is much more to do for good software than simply writing code.
It's a bit like using the software like everywhere else in life: first think, then act - and of course coden. In order to keep the code clean and as flexible as possible, a lot of considerations have to be made in advance of every development:
- What should the software do?
- What is the essence of the solution?
- Which elements need to be programmed as robustly as possible?
- Which elements need to be programmed as flexibly as possible?
- What is to be connected, read in, spent?
- How do I best combine the various elements into a functional unit?
Everyone deals with questions of this kind Software Developer extensively before writing the first line. Incidentally, the team can answer these questions even better, and then the four (or six or eight) eye principle helps to detect and eliminate possible pitfalls in the design at an early stage.
The head as a tool
Of course, the programmer needs tools. A good programmer can gain mastery with any tool. The principle is similar to that of the universal craftsman: He can work with any tool, but must also have the same knowledge for each tool.
But the real tool is the head. This is where the abstract constructs of each software are created. And good constructs are beautiful! The joy of the beauty of the software is a rare bonus in the professional field of the software developer. Importance is thus both knowledge of languages on the one hand and skills for pattern recognition and abstraction on the other. This means in detail:
Whether C #, Java, Python, HTML5, Basic, Ruby - who wants to program, must know his language (s). It's like on vacation: no words without words. Language knowledge is thus elementary. I can not express what I do not know. I can not program what I can not express.
Sits the vocabulary, next comes the pattern recognition. Patterns exist in completely different forms. A very simple but very important point is eg "do not repeat"! Everything that is the same or similar needs to be programmed only once, but then has to be designed so that it can be reached and used by all elements that require this function.
Also part of the pattern recognition is to recognize coherent sequences of functions and to be able to implement them accordingly. At the same time, this requires abstraction, ie the ability to build the structure of the entire product in the mind. Because only those who completely understand their task are also able to define the best solution.
Logic with and without math
Here is a keyword to mention: logic. Who wants to program, must be able to think logically, because above all there is always the question: Which action has what consequences? The basic structure of logical thinking can be learned at school in the field of mathematics, which can therefore be important for software developers - but not mandatory, because although the thinking is similar, it is not the same. And there is also complex logic, for example, in philosophy (and not just in Ludwig Wittgenstein's Tractatus logico philosophicus).
The next step is to follow the design principles. These principles for the design of good software have changed little over the years, despite huge technical changes and advances. A general theoretical approach has already been found in object-oriented programming, and many of the findings apply to working with non-object oriented languages.
Some examples are:
- Capsule, what is different.
- Address interfaces instead of programming an implementation.
- Each class of your application should only have one reason to change.
- Classes should be open to extensions, but exclude modifications (OCP).
- Avoid duplicates in the code by abstracting which core function must be fulfilled (DRY principle)
- Each object should have only a single function, and each method of an object should primarily aim to fulfill that function (SRP)
- Subclasses should be usable as objects of their base class (LSP)
The biggest do not in this context is called to this day: Do not write a monolithic block. The largest Do means accordingly: Write structured and in meaningful functional units.
And another principle is essential in software design: Be supple about changes! Changes take place constantly. Therefore, when designing a software from the outset to pay attention to which parts will change and which will not. Those that will change must be designed so that the changes are easy to implement and their functionalities are robust to change.
There is nothing good, except one does it, they say. This also applies to Software - the more complex, the more. And what about the good software?
At IMS, we always keep our eyes open so that our software functions as reliably as possible, performs optimally, is easy to use and generates long-term benefits.
Modern programming standards are at the same time as well as the latest developments in languages and third-party systems. A 3-tier architecture is as compulsory as usability. And mobile-friendly design is as much a part of it as web optimization and much more.
That's probably why IMSWARE is so successful on the market.
PS software development is your thing? Then have a look at ours current job offers past...
We are sorry that you did not like this post so much.
How can we improve that?