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.

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.

I haven't written here for quite a while and I would like to attempt to fix that today. Last time I talked about what design is. Today I want to continue talking about design.

Recently my girlfriend has exposed me to the beading (Beaded Flora is her blog on the subject). She uses beads to create complex, but beautiful flowers and animal figures. When I learned more about beading it reminded me about development and design, and I thought it would be interesting to write about it.

At an abstract level beading deals with basic building blocks, beads and a thread of wire. There is also a simple set of rules and constraints (describing how the wire can be bent before it breaks, how different colored beads can be combined, etc.) From the above techniques and patterns emerge. To create a net or a sphere with a wire one needs to follow steps described by a technique. Those shapes are combined to have a figure.

As you can see beading is quite algorithmic. Creativity is used to come up with new techniques (this is really hard and time consuming) or figuring out what shapes are required to create a flower and what techniques could be used to create each shape. This is a simplified example of software development. It demonstrates well though how to tackle complexity of the problem solving.

It's impossible to create the whole flower as a single solid figure (or rather it's very hard). Instead a beading artist beads each part of the figure separately. When all components are ready they are combined together. This is one of the widely used (often intuitively) approaches in design. How do we design and develop a really complex program? We can start by separating the program into logical parts, developing each part individually and then connecting them all together. This is already used widely.

The problem is how to split the project up. With a flower it is easy to see all parts it is made up from (leaves, petals, flower bud, etc.), but doing it to a program is not quite so simple. It's much easier to split a flower up over a program because flower is a physical object that we can see. Program at first is too abstract for our brains. We need to give it a shape, a form. Diagrams are often used for that (UML for example). We could write out the program description and try to derive it's components from it. This is partially why design is a creative process. Now I want to try and get something useful out of the analogy between beading (and it's design) and development (and it's design), and design process in general.

In beading, there are tight restrictions on what can be done. There's only a single thread of wire and it can be bent only so much before it breaks. Building blocks are very simple (wire and beads). This dictates how to separate the figure into sub-parts and how to connect all sub-parts together. Maybe if we can describe (or even create) certain constraints we can make our job much easier. Too many constraints, however, can make the problem even harder (so common sense should be used). We could try changing constraints, make them tighter and loser to see what kind of design we will get as a result. It would be wise to make the whole process dynamic and experiment with different attributes, but that's a subject for a different post. It's possible to use sliders tool to do show a list of constraints and try to come up with different constraint combinations. For example we could create artificial constraint of a class having a limited number of visible members. What if the limit is 2, 5, 10, 50? We need to have a good way to come up with design quickly. Drawing diagrams could come in handy.

Another interesting thought just crossed my mind. To tackle combination of constraints we could design for each constraint separately, loosening the rest. This could make it easier to come up with required design that takes into account everything. For example, we need to design a user interface that has to be simple to use and easy to learn, complex enough to work on a specific problem, and compact (in number of controls). First step could be to design an interface to be simple and easy to learn, then design it to help with specific task as best as possible, and then create a compact interface. When we have all three versions it could be much easier to come up with a general interface to take into account all three requirements.

I also want to point out that design tries to approximate perfect solution. There is a large set of possible designs with different constraints, and we, as developers and designers need to choose the best approximation of the perfect solution (if discovering perfect solution is impossible at the time, and it usually is due to time constraints and unknown factors).

Today I want to write more on design. In a previous post I talked about design goals, complex vs. simple design and how to recognize whether design is too complicated or not. Design is quite important in all aspects of life and so it's very important to understand what it is and how it can be improved. Personally I want to get better at it and I think one of the best ways to get better at something is to try to analyze what it is, how it's done, how it can be improved.

First, I think we should define what design is. Joel says it "is about making trade offs". He also points out that in the long run it's beneficial to spend more time to create a better design and quotes Themas C. Gale ("Good design adds value faster than it adds cost.") Dictionary.com defines design as "a drawing or a sketch; a basic scheme or pattern that affects and controls function and development". There are more definitions, but I tried to pick definitions related software development. In other words, design is a plan of how to keep the balance, how and where to make trade offs. However, when I see something really well designed, I don't really see a plan, I don't really see all the trade offs, issues that had to be balanced. I see a product that looks good, easy to use, etc. It would be more appropriate to say that design is a shape, color, features, some parameter (or combination) that is important to me (the user) and that makes my life better. The better my life (or some aspect of it) ends up the better the design is.

Design label is slapped on several related things: it's a process of creating a plan to balance trade offs that would result in an aesthetic product. And I'm barely scratching the surface. There are different types of design, from fashion and graphic to industrial and system.

Even in one field, such as software development, there are different levels and types of design. Web design (combined with graphic design and programming) is often used to talk about the external view of a web page. Class design is related to internal parts of an application. System design talks about how everything works together. Design is everywhere!

If you want to learn to create better design I think it's important to recognize what it is for you and to be able to recognize good design vs. bad design, and at some point to see how things can be improved. As an exercise I propose for you to look for design when you are using something, or just when something catches your attention. Try to see what was done well and what was done badly. What trade offs (money, time, usability, aesthetic) did the designer have to make and how did he balance the issues. Think about possible users of the item. Would everybody like it and would it be intuitive to use for everybody? This doesn't have to be an involved exercise. Just a quick thought to get into a habit of thinking about design. I will try to do the same and write more on what I notice.

In my next post on the subject I want to talk more on the meaning of design. Knowing what it is (a process and it's about trade offs) should make it easier to improve it. I'll try to explore that.

I was thinking today about what design is and what it should do. My short version: good design keeps things intuitive for the user. Seems simple, but in reality it's not. I often forget about who I'm designing for at the moment (myself, another developer, user, another class?). Sometimes it's not so clear who the user actually is. In addition good design keeps things well-balanced, and that's the hardest part.

Let's look at example of creating a class. It is made up of several parts (interface, code, documentation, etc.) that potentially have different users. Actually everything starts with the application design. It should make it easier for me (the developer) to create classes that focus on one thing, but at the same time can be used in a variety of places. It would be best if the architecture design would take care of connecting classes together and initializing them (that's what dependency injection does).

Class interface must be simple so that whoever is using the class can use and reuse it easily. It should emphasize the one thing class is trying to do. Everybody is familiar with this (high cohesion, low coupling, etc.) These guidelines, however, come from a more general principle: KISS (keep it simple, stupid). Keep it simple for the user (another developer, another class that will use this class, for the build process to generate good documentation, ahhhh, so many users to make happy). Simple to understand, simple to use, simple to document.

There are a lot of potential issues with simplifying everything. At first it seems that by making things simpler you lose potential power, lose some features. For example a task item in it's simplicity could be just a text field describing the task (this is what BaseCamp does). In more complex scenarios the task would have text fields for the title, for notes, there would be an author, due date, duration, etc. The problem is that as the task entry becomes more and more complex it will be harder and harder to present information in the way that would be easy for the user to understand. It will probably require more detailed documentation (that probably nobody will care to read). If design is poor (and it's harder to make it good in more complex scenarios), the user will have to spend more time learning. In the first case the user could just jump in and create tasks quickly. Where is the balance?

It's different in every case. On one hand there's simplicity (one field) and on the other there's a complexity (many fields). As things move towards complexity they become less and less intuitive. As soon as they stop being intuitive and easy to use design is too complicated. In addition, as user learns, things become simpler. So design needs to be simple at first, but provide new features over time.

Start by making everything as simple as possible. Not as generic as possible, as simple as possible. Don't think about how how many ways something can be used. If you have a square hole you need a square plug. Creating a plug that can shape shift to fit in both square and round holes  makes the plug either too complicated to use or of such a shape that it doesn't fit anything anymore.

Remember, potential users of your class include other developers who might want to reuse existing code. Aim to solve the problem at hand, but think about the possibility that the class could be extended in the future. Start by solving a problem. If a similar problem arises in the future you could try to go back and look at your code to refactor out common pattern that can be used to solve both problems. The simpler initial design wa,s the easier it will be to find such pattern and adopt it for new use.

I'm not saying anything new and that all of this is common sense that was around 50 years ago. Still, I think it's important to remind that no matter what you do, keep it simple (but don't lose perspective). In the end you will make things easier for yourself.

Joel is running a long series of articles on great design, if you are interested in more details on design topic.