ideas: technology
Programming principles applied by me

“Everything should be made as simple as possible, but not simpler.”
Albert Einstein


It is also said like this: keep it simple stupid(the KISS principle). I would translate Einstein’s statement to programmers langu-age like: use as few object and commands as possible to solve the problem. I always check for example if I can do something using less variables. Of course the code should be readable and easily understand-able, but don’t underestimate the power of simplicity.


Check out the example on the other side.
>>>>>>>>>>>>>>>>>>>>>>>>>>

 
* Basic example(In ABAP language):
* Instead of doing this:

form add_element using p_apple.
data: temp_apple type f.

temp_apple = apple.
add 1 to temp_apple.

table-apple = temp_apple.
insert table.

endform.

* Better to do this:
form add_element using p_apple.

table-apple = p_apple.
add 1 to table-apple.
insert table.

endform.

* I know that it is very basic,
* but I’ve seen it so many times,
* that I had to write this down.

 
 
Be as close to the end user, as you can.
(Comes from extreme programming)

Usually a programmer cannot write a good program all by himself. He needs to consult with the client continuously. While programming, there are questions, what can be answered only by the client. If the client is not there the programmer’s decision can be good or not. So it’s recommended to have at least one end user in the same room with the programmers or max. next door.

Create value as soon as you can
(Comes from extreme programming)


This world changes constantly. So do the needs of the client. Besides if you are only creating one big final release, you can do it for years without reaching the end product. Better to define and make small steps. In the book Extreme programming installed they give a good example of how you can split the unit of a payroll system. When they have already a running payroll, you can give them a tool, with they can maintaing master data
 
better. Then you can take only a part of the employees to the new system. You can make a separate tax report. Someway you should find out, how you can make releases of your work in each month.

Finish your programs

There is no finished program without test. The program is actually finished when the user is using it and have no problem with it. Until that, nobody can say it is finished. Many times programmers are not carrying through until this point. They make something, they say its finished and they go away. And then you have to employ another programmer to correct this program for weeks. It’s better to do one job one time and carry through until the user actually uses it.
 

Do not tell your problems, show them

As I experienced, it is always good to sit down before the computer and show something instead of only speaking about it. There are things what you cannot tell with thousands of words, but you can show it very easily. When there is a mistake somewhere, I ask people to show it, so I can see it and interact with it. I think I’m closing down problems in half a time with actually going into the system and checking it.

If it is not tested, assume it is wrong

I saw this principle on the Flashforum conference in Cologne and I totally agree with it. If you have a program that is not tested, it is wrong.

Use Test Driven Development

I've found this method very practical. First, you create examples or test cases and only then you start programming to solve them. I use this continuously.

 
Consider using SCRUM phases

If you have a backlog in a field and you want to handle it fast, you might use SCRUM. Besides XP - extreme programming - I consider this method useful.
Main principles are:
-Real stakeholders commit themself to do certain tasks until a deadline
-Nothing, really nothing stops a scrum run. The work on this thing is started and finished without breaks or other tasks.
 
Published on zbalai.com in 2004.