Why there’s Never No Bugs
It’s hard to accept but yes, you can’t write code without bugs from the first try and it’s the developer’s rule. Not an axiom, because everything that we will write in this article has exceptions but nevertheless, we want to calm everything down and show you reasons of bugs in code and why it’s fine for the working process.
There are many such statements in programming: some of them are just jokes, but there are clear principles directly related to development. We’ve put these programming laws together so that abbreviations like KISS or POLA don’t scare anyone else on the forums. Let’s see through rules of technical life experience why we always stuck with bugs.
Deadlines and their Causes in Bugs
According to the Brooks’ Law:
if you add manpower at a later stage of development, it will further delay the release of the project.
Brooks points to the main factors that explain why it works this way:
So if you decide to increase the team to speed up the release of an almost finished release – think again.
Of course, there are different cases: Brooks advises to pay attention to the type of task – whether it can be divided at all. Conventionally, 9 janitors will collect leaves sooner than 1 (unless they interfere with each other), but 9 women will not give birth in a month.
Software development can usually be shared. However, the new person will not be productive right away: the old participants will spend time learning new ones, they will make mistakes – so the process will take longer.
Another point – this rule applies only to those projects whose release is really delayed. If we are talking about too optimistic forecasts and schedules, then the problem is obviously not in the team and productivity, but in the wrong planning.
The ninety to ninety rule is dedicated to planning: the first 90% of the code is executed in the first 90% of the time, and writing the other 10% of the code takes another 90% of the time. The rule is ironic but successfully illustrates two truths: people tend to postpone the most difficult stages for later + there can always be unforeseen circumstances.
Broken Windows and Debt Code
The theory of broken windows was formulated by political scientist James Wilson and criminologist George Kelling. The idea is that as one window in the house was broken and no one put a new one – soon all the windows in the house will be destroyed. This thesis is often quoted to confirm their (any) ideas, but no less often it is denied.
In programming, there is a similar concept of technical debt or code debt. If the code is not optimized immediately (and this requires time, resources, etc.), indifference will increase, the simplest solutions will be preferred, and as a result, there will be code with a smell, which is in dire need of refactoring.
Keep in mind the law of Canadian computer scientist, Kernighan: debugging code is twice as difficult as writing it. Therefore, if you wrote the most complex code you could, it means that you will not be able to debug it yourself. And according to Lyubarsky’s law of cybernetic entomology, there is always another bug.
Experience and How it Influences on Work
The technical sphere is living for many years. That’s why we got so many theories and rules that we can just combine them into abbreviations and just remember during work.
D.R.Y. = Don’t Repeat Yourself
A fundamental rule and a popular mantra among developers, which sounds like this: each piece of information must have a single, unambiguous, authoritative representation within the system. But while clean code and avoiding continuous copy and paste is good, understanding and considering context is also important.
Violations of the DRY principle are jokingly called WET – “Write Everything Twice” and “We Enjoy Typing”. Add nothing, period.
Advantages of keeping a DRY code
Maintainability: Because you have already identified a logic that would make more material when you need to update the code later, it would be easier to change the material in one logic, which then applies to any other applicable item.
Readability: You can follow the codes easily.
Could be reused: one of the good features is that you can reuse the already written logic because the same operations are performed.
Charge: this approach of coding is about the safe: money and time.
Testing: it becomes easier because you do not need to define configuration and testing functions for each function. But with the WET code, you will conduct more unit testing.
P.O.L.A. = Principle of The Least Astonishment
This is the rule of the least surprise: if the function has a high surprise factor, it may need to be reworked. That is, the behavior of the elements should be expected and not too surprising to the user. This is relevant for both software development and interface design.
Y.A.G.N.I. = You Ain’t Gonna Need It
If the system does not provide certain functionality, you do not need to register it in the code (even if you really want to). At some stage of development, it may seem that additional features will not interfere, will be needed in the future, and will not be superfluous. But the time for testing these functions, documentation, implementation is lost, and one redundant design can lead to twelve more – and the product eventually becomes too complex, resource-intensive, and bloated.
K.I.S.S. = Keep It Simple, Stupid
For the end-user, it doesn’t matter how ingenious the developer can be, the main thing is that everything is clear. The simpler the product, the more people will use it, and therefore the more useful it will be.
Now, this principle applies most to development and design, but its authorship belongs to aircraft designer Kelly Johnson. He designed aircraft so that they could be repaired in the field by mechanics with minimal training and a set of tools.