4. December 2022 Only a lazy developer is a good developer
Wait. What? A lazy dev is a good dev? Why is that? Let me explain: Laziness in the context of ABAP development means not doing things manually and not doing too much. Why? It is problematic for several reasons:
- It is inefficient. Doing things repeatedly manually. What is repetitive should be automated. It’s faster that way.
- It is error prone. Every manual action has some chance of errors creeping in. Automatisms always work the same way and (from a certain level of maturity) relatively error-free.
- “too much” generates follow-up costs. Everything you do generates costs, in multiple ways.
- Manual work leads to an inner resistance to things that are “unpopular”.
Could you find yourself in the abstract formulations? No? Do you know what I want to explain to you? Not yet? Let me help you 😊
- Do as little as possible by hand that can be automated. Then you are faster and less error-prone. A good example is testing: Clicking through processes in the QA system and documenting them is time-consuming. If an error occurs, you have to make another adjustment in the DEV system. Then deploy gain, test again, etc. It takes some time and sums up. Instead make sure that the highest possible quality arrives in the QA system: Write unit tests and execute them automatically (CTRL+SHIFT+F10 in ADT and SE80) during development. This way you save time on manual tests.
- You recognize a problem in the source code: Your method is getting too long. It already has 200 lines. You feel uncomfortable with it, because you know that the maintainability decreases. You decide to extract 10 lines into a new method. Your IDE is SE80. This means a lot of manual work: create method, set parameters, copy code over, replace old code with the method call, control parameters. Save. Pretty Print. Check… ERROR. Use what your IDE offers you – automation of „Extract Method“ (ADT CTRL+1 Quickfix) and the error rate drops rapidly.
- Do not write more code than required. Each line of code costs money. The first time when it is written and again each time it is read by you or your colleagues, and yet another time when it is a source of errors. Maybe the client won’t even pay for what you include in addition. You can’t anticipate a requirement for the future. Write the minimum code that meets the requirement.
- Manual work takes time. That’s why there is often the following (or a similar) situation: A variable name doesn’t “fit” anymore. Its name doesn’t represent what the content of the variable is anymore. You would like to rename it, but it is used in many places. Renaming it would be effort and no fun at all. A resistance arises. You decide yourself against the renaming. Somebody else will do it.
The higher the effort to make a change, the lower the chance that it will be made. That’s why Clean ABAP won’t catch on as long as you use SE80. The missing Quickfix-features make “clean code” so costly that it is just not attractive to do. Use the refactoring tools of the ADT and your codebase will be cleaner.