Jan/080
Handling Error Flow
Handling your applications error flow can be hard to manage. I’ll go through some common tips on what your application should do when problem occurs and how to track your error flow.
Jan/080
Cargo Cult Scrum
After my post Scrum My Day! I received some feedback about using Scrum. Clinton Keith pointed out that our team wasn’t using it right. After that I’v been doing loads of reading and researching about Scrum. I’v been only using Scrum for two months so I can’t yet say I have seen how it really works, but at least I’v seen how it doesn’t work. 
Real problems :
- Daily Meeting
- We were only saying what we are going to do and updated our task properties.
- Not having a sprint ‘post mortems’ – Sprint Retrospectives
- To discuss about what we did right and what we didn’t do right. Enables us to improve things for the next sprint.
So now after I’m a bit wiser I can say how the daily meeting should go :
- Everybody tells :
- What they did yesterday.
- What they are going to do today.
- What is preventing them from doing something.
- Point is not to give a report to single person, instead give an overview of what are you doing and what are your problems to your team so that they can react to it.
Also use iterations (time boxes) so that you get good enough result. That way you are able to control time usage instead of trying to do everything perfect, which would take too much time in most of the cases.
Jan/080
Learning Marketing : Chapter Three
Top 5
- 870 unique visitors since the launch
- Added Money Machine page – if you think my articles are good, use this to give me a few bucks.
- Trying Google Adsense (is it really worth of it?)
- 8 Registered Memebers
- 5 Free Months Left (one for each new user).
Marketing in general has gone well, I gave up with StumbleUpon for now, it worked, but I’m pretty sure it didn’t reach my target audience so I’ll continue doing that by myself. That’s about it.
I was thinking about on how often I should write here and I decided to follow this rule : if I don’t have anything to say I won’t write anything. I’m aiming to write daily, but I know that it isn’t going to happen so I’m not going to lie and invent some posts.
Jan/080
Is your code understandable?
At work I’m constantly trying to improve our code base and at the same time teaching others to do the same thing. One of the biggest problems is that when people write code they don’t think about what they are writing.
Some tips for writing better code :
- Comments
- Keep clear.
- Don’t write too long comments, 1-5 lines should be enough in most cases.
- How many things you need to memorize during reading to understand it.
- Try keeping it in1-5 different things (e.g. variables, special rules..).
- Is there a better way to do this?
- If there is and it doesn’t take too much time then do it!
- Why are you doing this?
- If there is no reason to do it, then don’t!
- Can it be simpler?
- Try divide and conquer, e.g. split function.
- Don’t duplicate code!
- Don’t copy & paste the same code around, make one function for it and then call that.
- Naming
- Don’t use variable names like temp or index, give them a proper name -> temp_vertex_buffer or vertex_buffer_index. Same goes for functions!
- Don’t write huge functions
- Smaller functions are easier to handle and have less bugs.
- Minimize Function Dependencies
- Try writing functions that are independent, e.g. don’t call other functions.
- See Function Cohesion
Jan/082
Software Disease Diagnostic
I got House M.D. season 2 as a christmas present and now I’v been watching it through. In it Dr. House is trying to find the right diagnostic before the patient dies. Making the right diagnostic is really important as otherwhise they won’t be able to cure the patient. The same thing apply in software development.
In software development you have a bug (disease), but before you can fix it (cure it) you’ll have to know what is causing it (do diagnostic). The bug causes problems (crashes, etc. – symptoms). You can’t always do the diagnostic just by looking at the symptoms, as those might match to bunch of diseases. You’ll have to do tests to get more information about the disease. Decrease the amount of possible diseases until you have only one left, it is an iterative process.
How long it takes to do the right diagnostic depends mostly on experience. If you have met the disease or heard of it earlier, you are probably able to cut down the list of possible diseases or even find it immediately. And that, ladies and gentleman, is really important as we spent most of our time on finding the right diagnostic, e.g. what is causing the bug. Time is money and we don’t want to spend too much time(money) on fixing bugs.
Now to make it harder to get diseases you’ll need some protection against them :
- Good coding practices.
- Testing (there are 2 articles about testing at Tips & Tricks).
- Know what you are doing before you do it!
- Most of the bugs are created when we don’t pay attention to what we are doing or we don’t know what we are doing.
I have heard that you should not compare software development to anything else. Bull shit, everything can be compared. As far as I’m concerned different things should be compared, otherwhise you’ll miss different point of views and oppurtunity to learn, e.g. if somebody else is doing it better. One thing that makes a huge difference on skills :
- People who are open to new things
- Learn from everything they can, multiple point of views.
- Learn from everything they can, multiple point of views.
- People who aren’t open to new things
- Limitted to their own point of view.
So my advices are :
- Keep your mind open.
- Compare things to get new point of views and oppurtunities to learn.
- If you find something better, use it!
Jan/080
Ownership To Boost Development
In many companies you aren’t encouraged to take the ownership of your code it. You should.
Jan/080
About Coding Language
I received some feedback about my code examples. Apparently it is not good way to use old C-88 in examples so instead of that I’ll just write pseudo C, meaning that it is C – like, but won’t probably compile when you copy & paste it.
Note : the code samples are there just to visualize the case to make it easier to understand it.
Another reason for this is that I don’t want to raise any code language fights here.
Jan/080
Site News!
First of all, my 500 – unique visitors goal succeeded, yesterday I already had about 580 unique visitors.
Next thing, I released two Tips & Tricks – articles today, one public and one private. I won’t be releasing new public Tips & Tricks – articles for a while now as there already is 5 of them :
- Function Cohesion
- Warnings
- Do not use magic numbers!
- Can your software handle the stress?
- Scrum My Day!
I’ll be concentrate adding more content to the private side. So to see more Tips & Tricks, you really should register to Tips & Tricks service.
Also remember that there are still 7 open user registrations who will get a free month!
Jan/083
Scrum My Day!
I’m currently using Scrum project development method at my work and I’d like to share some experiences and opinions about it.
The Scrum works well for small groups, it requires daily meeting and good time estimation. Do you see a problem here?
I see at least two of them :
- Daily Meetings
- Time Estimation
Daily Meetings
15 minutes at max. But I still haven’t got the real idea of it, we just update our tasks : time used, etc. At Nvidia we had project meeting once a week, that was enough, and we had some real things to talk about. I mean, what’s the point of doing a meeting almost every morning which goes like : “Good Morning!”, “Let’s see our tasks..” … update the tasks properties, “Anything else?”, “No”, “Ok, let’s get back to work.”.
How to improve :
- Everybody updates their own tasks on daily basis, without the meeting.
- Meeting once a week.
- If you have a problem, don’t wonder around waiting for the next meeting, ask about it right away -> in bigger issues schedule an extra meeting.
Time Estimation
This keeps popping up everywhere, we try to be so exact and still we are always late, why is that? Because it is not possible to estimate the time used for software project exactly.
We are currently estimating our tasks on hour basis and I don’t like that. More accurate time scale means more noise, and that is something I would like to avoid.
How to improve :
- Estimate how many days the task will take, that is more realistic than hours.
- Always estimate with the worst case. If you can do it earlier that’s great and leaves time for other things.
Jan/087
Variable Life Time
We all use loads of variables in our code and we want to ensure that it is easy to follow their usage. One way to improve is to think about the variable life time.