The Programmer And The Forgotten Alternatives

Inspired by the talk of Malin Lidén at #sitwdf about community and trying a few thoughts came to my mind…

At SAP Inside Track in Walldorf this month Malin talked about how community made her stronger and mader her believe in herself. She shared her experiences in the sap community and also gave some tipps how to deal with challenges.

The most important tip was: Doing something wrong is not important. The community will help if something dows not work out as expected. Important is to simply do.

Malin’s keynote Success Factors for Innovation.pptx can be downloaded HERE.

10.000 Ways

At this talk a quotation of great Thomas Edison I shortly heard came to my mind:

I haven’t failed. I found 10.000 ways that don’t work.

This is a really important view to knowldege because most people think that only their success is a success. But that is not true. Also the ways that lead to wrong results are kind of a success. A success in learning things.

If you only concentrate on the successful things you might step into traps you earlier already fell in. You also might be disappointed because you only success of others. But believe me: Others also fail!

Traps And Alternatives

something that is wrong mostly is not the opposite of right. It is just an alternative, a different way, another possibility.

Something that is wrong now might have been correct earlier or in a different surrounding or with different data or under other circumstances. Maybe something does not work anymore because the database changed or the amount of data has changed or the requirement has changed.

That is one point. Think about alternatives, think about better solutions if it is required for whatever reason.

But there are two other important points:

1. think about alternatives before things change

2. write down all alternatives and document the reasons why one alternative won and the others are not ideal.

legacy code

Sometimes if these things happen and outdated code will be replaced by a new alternative, you might find decommented code within the function. Mostly there are no documentations why this code has been replaced. If there are no hints on earlier used different code is left in the code then the next programmer might replace the new code with the same technique that has been deleted once…

Example:

A commit work often causes trouble. Sometimes when missing, sometimes when implemented. Maybe COMMIT WORK is coded somewhere and everything works. Then the function or report will be used in another process where the COMMIT causes some trouble (e.g. background task). You will realize that the COMMIT WORK is wrong in this case. You change it and the former process will not work anymore. Another colleague finds the missing COMMIT and reactivates it beacuse there is no hint about the new process and its problems…

Thoughts On Point 1

If a programmer has to solve a problem or has to create a program based on a specification than he often uses the same techniques he has always used (habit). So he “knows” what to do without really thinking about it.

On one hand it is good because if a programmer works like this it means that he is very skilled and has good experiences. On the other hand he might step into very simple traps that could be avoided.

Example:

programmers often have to offer a selection for the user where the user can choose between different options. At first glance I can think of the following three techniques:

1. radiobuttons
2. Listbox
3. Input field with F4-Value-Help

Every of these alternatives has its own advantages and disadvantages. If there are only three options A, B and C than you could use a listbox. But using a listbox instead of radio buttons means two disadvantages to the user:

a. The user has to click two times to select the desired value (first click for dropdown and second click to select the value).

b. The user has to click to see all possible options.

But there are also two advantages of the listbox:

a. The values can easily be used dynamically (if sometimes only A, B are needed and sometimes A, C, D and F)

b. A list box uses less space on the screen

however. This example is a very easy one where it’s not really worth to think very a long about taking a listbox or radio buttons instead. If one variation turns out to be unhandy than you can easily change it. If not, the user can use the program anyway.

So as a programmer or GUI designer you should think about different options before even if it’s not really important. But if a programm will be used by a lot of users everyday such simple design things can make the difference between a good program and a not so good program.

Document The Alternatives

One very challenge is decision-making. The most important thing is, that you have a decision at the end. But more and more important will be why the chosen option turned out as the best one. There might come the day where the decision once made will be questioned.

• Why don’t you use function module abc to get the data?
• You select all the data immediately although some data will not be used. Why don’t you do a preselection?
• A tree-view would be much better than the alv. Why do you use the grid-view?

Of course you cannot think about alternatives and write them down for every single select you do and for every field you put on the screen. But if there are options you think about then write them down. In the documentation, in the code or share your thoughts on a blog. If something makes you think about a topic then it can help you and others if they read your thoughts and opinions!

If you share your thoughts than a novice might think: “oh, I did’t know that this was an option anyway…” or “Great. I have not thought about this aspect so far”. Another programmer might correct you because one issue has changed with a new release or with a different database. For example a lot of people still think that SELECT INTO CORRESPONDING FIELDS is much slower than selecting values in exactly named work area. With modern databases it does’t matter anymore!

Your colleage also might give you some other hints or views you might not have thought about so far.

Remember The Reasons

But the best reason is: If you are urgent to find a different solution than you often do that because there is a very specific deficiancy in the code or the technique. Often the new code will be more complicated and longer than the code before. If someone asks you why you don’t use the easy way you can explain! You often cannot remember the exact reason after a while because the circumstances are very specific and very complicated. If you write down a little note with a short example of what does not work with the old code than it will help you and others a lot.

To close this topic I would like to use a quote of sokrates I like very much:

I cannot teach anybody anything. I can only make them think.