May 2007 - Posts

• Do less

  I just read Getting Real book and I really liked it. It was written by guys at 37 Signals, creators of Ruby on Rails and a series of successful online services. The book is about how to be more practical by staying simple and focusing only on currently problems. Among other things it shows that by doing less you can be more productive. In other words most of the crap we are doing, or I'm doing, doesn't really matter and has no real effect on my life. I agree with that. I knew about the concept for a long time, but was never able to do much about it. After reading the book and thinking about it I'm starting to get it (maybe). Doing less is doing just enough, not everything. There's no perfect or complete state. People often talk about Pareto principle. In the context of this post it means 20% of all actions produce 80% of the value. According to it I just need to focus on that valuable 20% of the actions. I always understood this principle, but could never apply it practically. It's an interesting concept, but I must be missing something. Solving only problems at hand seems more practical and easier to do. When I first saw the idea I thought, "Don't I always try to solve problems at hand?" As I read and learned about it, I realized that, no, not really. I make several mistakes. Try to optimize my time by solving problems early. Cost of most problems grows over time, but most of the problems I think of never happen or are completely different in reality than I thought they are. I act on what's urgent. In many cases urgent isn't important, but I'm afraid to lose an opportunity. What I came to realize is that many things that appear urgent, are not urgent at all and can be done at any time. Do something without understanding of what I'm trying to do. I try not to do that anymore :) I don't fully agree with the book on solving problems as they appear. We can anticipate for them to happen and do something early to make it easier to solve them in the future. In a way it's prevention instead of solving something that isn't real yet. With software development I try to follow good design practices to make my code easier to understand and maintain. When I don't, I usually need to go back and change it later on, thus increasing the total cost. If I don't separate concepts and make sure my classes are independent it's hard to replace an algorithm later when I run into performance problems or switch to database from using files. Speaking about performance, premature optimization can be bad, but if I don't think about it at all until I'm having problems I can push myself into a dead-end and have to rewrite large portions of the program. Normal life (like I have any) is the same way actually. I can't solve all my health problems, but I can help prevent them and make it easier to handle them if they appear by eating healthy and exercising. Don't solve problems you don't have, let that which doesn't matter slide, but don't completely close your eyes. Problems will appear. Be flexible, expect the problems to happen, expect that you will have to change your code. Most importantly, be smart about it. It's possible to go too far with anything, prevention including. Be practical and stay real, and do less, just what's really important. Share this post: Email it! | bookmark it! | digg it! | reddit! Readability Stats: Word Count: 597; Sentence Count: 40; Grade Level: 6.6, more info... Posted May 16 2007, 06:20 PM by Ornus with no comments Filed under: General

• Estimation, Part II

  In the last post I talked about estimation points and why they can result in more accurate estimations. In short summary, relative estimation is simpler and more accurate. That's what estimation points are, relative size of one task compared to the other. How long it takes to complete each point needs to be approximated from several initial iterations. Today I want to introduce additional techniques to make estimation easier. It's usually easy to see if one task is twice as big as the other. If another task is 1 point, the twice-as-big current task is 2 points. What if the current task is about 10, 20, 100 times larger? It's impossible to say if it's 100 or 101 points. It's hard to distinguish between 20 and 21 and even between 10 or 11. It's also not important because estimations are inaccurate. 10 or 11 are close enough for errors in estimation to make it possible for 11 points task to be smaller in reality than 10. By making a task 10 or 11 we are just guessing that it's somewhere in 8 to 15 points range. To make things easier we can group different ranges to hold all items close in size. For example all tasks in 8 to 15 range will go into 10 group, 15-25 to 20 group and so on. Two series of groups are popular - based on Fibonacci sequence (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) and on 2^n sequence (0, 0.5, 1, 2, 4, 8, 16, 20, 40, 100) or something along those lines. Around 20, groups become 20, 40, etc. in size. It doesn't really matter if it's 20 or 21, but it's easier for people to think in rounded numbers. I tried to use this system with Sider. It was easy and fun. I didn't feel anxiety to say if something is 8 hours or 9 hours. Instead I just chose appropriate group. I also didn't have to guess if my hour is really an hour. I knew I can figure it out later. The problem for me was that I couldn't really switch to thinking in points instead of hours and days. I almost automatically decided that 8 points is 8 hours - 1 work day. I ended up comparing each task to something that I thought would take a day or an hour. At this stage I've no idea if my estimations are accurate and when I will complete the next Sider release. In several iterations I hope to have a better picture and a better idea when the release will happen. I also want to mention teams. Most of the time people work in teams and they need to give estimations as a team. I usually work alone so I can't really share any experience or talk about related problems. I suggest you check out Planning Poker, a procedure and a game created to help people overcome frequent problems and give accurate estimation together with their team. To learn more about estimation I highly suggest listening to Agile Estimation podcast. Share this post: Email it! | bookmark it! | digg it! | reddit! Readability Stats: Word Count: 524; Sentence Count: 37; Grade Level: 5.5, more info... Posted May 08 2007, 02:41 PM by Ornus with no comments Filed under: Design

• Estimation

  People need to estimate as part of planning. It can be time (tasks), money (budgeting) and so on. The point is to understand the value of something. We can then decide if it's worth the time or money or in what order should we do/get things. When working with tasks we focus on more valuable actions first and if there's time we complete the rest later. We also want to know when a project will be done. So, software developers are often asked to estimate. We often miss and underestimate. Why? Here's my list of the possible reasons. There are many books written on the subject. I have hardly read any of them so I probably miss something. We've never done it before, so we have no idea how long it will take. We just guess. We lie, because we wish we would have been better developers and could develop it quicker, or because we want to tell somebody what they want to hear, not our opinion. We fail to fully grasp the scope. We estimate what we see, but there are a lot of hidden additional work. In the first case it's just a matter of experience, but I don't think this is a big factor. In either case there's not much we can do about it. I'm stuck with whatever experience I have. In the second case, we just need to learn to be honest and face the truth, even if it's not pleasant. It might be hard to acknowledge the problem and do something about it now, but later on it will be more expensive and more unpleasant. This is applicable to all aspects of life. People hide from reality, hoping that the problem will go away on its own. It might, but if it doesn't, it grows like a weed. We can actually do something about the last case. When we make mistakes in estimation we are consistent about it and we can compensate for it. That's exactly what an estimation point system and velocity are designed to do in Agile Development. While listening to Agile Estimation podcast I finally understood how point estimation works. Each point is just an abstract unit used to measure relative size of the task. It assumes that it's easier for people to estimate relative size of two objects or tasks when they compare them side-by-side than to estimate an object on its own using standard units (time, length, etc.) The size of 1 point is unique for each project and each team. When estimating we don't know yet how long it will take us to complete each point, but we can say that 4 points task is twice as large and will probably take twice as long as 2 points task to complete. Velocity is how many points are completed during each iteration (a week, 2 weeks or however long an iteration is). At first we don't know how big it is, but after a few iterations we can look back and guess how many points we will be able to complete in the future. This makes it possible to project when the project will be done, while compensating for estimation mistakes. There's more I want to say about estimation and I will continue writing about it in my next post. Share this post: Email it! | bookmark it! | digg it! | reddit! Readability Stats: Word Count: 559; Sentence Count: 37; Grade Level: 7.5, more info... Posted May 02 2007, 12:33 PM by Ornus with 1 comment(s) Filed under: Design