Last week I made a mistake. I confused the meaning of private/public key and their usage in asymmetric cryptography algorithms. I understood my mistake and excused to my colleague with whom I talked. So in the first moment when I understood that I did a mistake I was angry on me. But when I got calm I remembered that I could apply the last posted principle of the software monk. So I started thinking why I made this error and what can I do to not repeat it this mistake and even how can I escape problems with confusion of my knowledge? I considered the situation and understood that I change the knowledge domain almost every week. For the last 2 or 3 weeks I had to start implementing code on Python and Java, modify servers implemented on Python and C which I didn’t know very well and so on. This facts hints me that I have to cut these kind of problems to the root. My decision which I found out for me was to start making a brief review of the basic concepts in every new area where I am making new steps or I haven’t work more than a year. Probably this approach will cut my mistakes a lot. According to my colleague Mircho 60 to 70 percents. My experiment will show me what will be the result !
Archive for August, 2009
Recently I thought on ‘How can I reduce the bugs to minimum ?’
My decision was to execute these steps :
1. Stop and fix the bug if it is serious or log it for a later inspection .
Note : See TPS (Toyota Production System) and why they stop the production line when there is defect.
2. Ask 5 times ‘Why I did this?’ regarding this bug.
Note : I search the root of the problem(bug) I don’t want to fix only the bug. The decision will give us a principle in a lot of situations, not a fix for the bug in a single case.
3. Describe the bug in a file and its decision. If the bug is related with some principle then I fixed the bug perfectly.
Note : It’s very easy to forget the problem, the fix ,or principle which fixes all group of bugs.
4. Make a revision of your principles and the way you mustn’t do something if you want to reduce the mistakes. It’s something like reading of the bible. Probably It’s good idea to talk on every teem meeting for the bugs written in the file when you work with a teem with monks.
Note: Item 3 and 4 are practices are taken from the book “TEAM SECRETS OF THE NAVY SEALS’ “
Now I have the perfect practice for the job I do! I reckoned that the time for fixing a bug will be reduced in future a lot. I won’t do bugs in future ! 
I know this approach needs from me to be orderly but If you have the best one tell me.
Recently I read this article by Bill Curtis. I think that this one of the articles which should be read many times because it shows us one of the roots of our problems in software development.