The broken window theory says that if a window in a building is broken and not repaired quickly, people will be tempted to throw stones and break the other windows.

In the ABAP world, the rule is to do it once and never touch it again. Once done, forever frozen. What nonsense.

You’ve been asked to create a new feature. You’re ready to build it. But hold your horses. Before you start, I suggest you find answers to a few questions. Finding a good answer to each of them is fundamental to ensuring that what you build is solid and elegant.

Every time you switch contexts, you lose the thread slightly. It’s human nature. So the less you do, the better.

Still using SAPGUI instead of Eclipse ADT? Get ready to be made fun of.

I read somewhere that Eastern mathematicians tend to solve a different kind of mathematical problem than Western mathematicians do.

You Ain’t Gonna Need It means Do what you want, but don’t say I didn’t warn you. Just kidding. Not really.

It’s very easy to mess up with object names in SAP. I recently found a way to minimize that problem: set rules to fix per-package prefixes for certain object types.

I obsessively package everything that moves.

Did you know that you can finally make radical changes to a development without fear because there is a simple way to undo all those changes?

OO exceptions always need a parent. They always have to inherit from somebody. And ABAP gives them 3 alternatives.

In SE24 the class code is partially hidden from the programmer behind a GUI. This is apparently convenient but ultimately limitative.

Are you sure your SQL is bulletproof?

When a program is bad because it has duplicate code, it usually becomes shorter once we rewrite it to make it better. But, if its problem is not being properly structured into several classes and methods, if we rewrite it according to the best practices, it will probably end up longer.

Most ABAP programmers are like swans. They marry ABAP forever and are eternally faithful.