Sharing the thrills with the customer: the good
Programmers want customers to use their software. Some of them want to be given feedback in order to improve the software. Most programmers, want even, their customers to be thrilled by their software, if they are thrilled by it. They want their client to share this with them. This is a good thing, it makes us developers proud, knowing that the software is being used, that the customer shares our enthusiasm for a solution we thought of, doesn't it? This is good.
Sharing the thrills with the customer: the bad, the ugly
Unfortunately, programmers want more, and like any excess it ends up bad. The programmers want the client to be thrilled by their technical accomplishments, by the 'smooth' things in the solution, techincally speaking, by how ingenious the solution was developed. They want the customer to be excited that the programm works 28 times faster then another solution. This is bad and ugly. It is naive. We programmers like logical things, but this is against logic. At least at the beginning.
The customer will only be thrilled by a software if it will improve his life, if he can achieve his business goals faster. It doesn't matter if the product was ingeniously build but whether the product is an ingeniuos tool for him. He doesn't care whether it is faster 28 times faster then another technology, unless the second was slow by his standards, he doesn't care if you used n-tier , unit testing or automated builds, 'healthy' approaches or not. He only cares if he can be more efficient with his new tool, your software.
So where is the problem in sharing the thrills with the customer?
Programmers and customers are both thrilled by being good at what they do. This is the common thing. The problem is that they act in completely different areas (mostly), so 'at what they do' means completely different things. Let me give a very simple example: management likes reports about what developers do, so sometimes as a programmer you're not very happy at the end of the day to fill in a report about your activity. Well that data makes them happy, but takes time out of your programming time. They even sometimes, show you the reports very enthusiastic believing that you would share that too, but do you?
Software is a tool. Just having it doesn't make your customer happy
It's not that easy to be thrilled just by the fact that you have a tool. You'll be thrilled only by achieving a goal. If achieving this goal, involves using a tool, you will be thrilled by the action of achieving the goal and not by the fact that a tool helped you achieve it. Just having a tool or using it without meaning doean't make you happy.
Let's say that you're a mobile phone manufacturer. You want to sell your customer mobile phones. If you sell them mobile phones, they won't be thrilled by how good you phones are. They will only see their potential when they'll achieve the goal of speaking from everywhere. They will be thrilled by the fact that they can go everywhere, and still be able to be called and call anyone they like. This is the first thing they will notice, this is their goal, to be mobile and not to own a mobile phone. They won't care if it is GSM or CDMA, if it works on triband or not. Fortunately, as the time goes, they'll start realising that in order to achive their goal of mobility better, they depend on the mobile phone. Some will even notice, that it works on three frequency bands. They will see that they can be more efficient at their primarily goal by improving their tools.
Turning priority lists arround
If you have real good marketing people, you might find out that at a time, this goal changed, they care more about having powerfull mobile phones with color display, calendar, mp3 player and camera more than speaking from everywhere. People become addicted. Another example would be skiing. At first you don't care about what helps you ski but about the action of skiing.
Unfortunately, we as programmers often missunderstand the approach we need to use. We think that proirities are already changed, and we show the client how great the software is compared to another, and not how it will help him. We assume that the customer is already addicted.
Show the client not how to use your software but how your software helps him
Think about car manufacturers (and salesman), 2-3 decades ago, when they suddenly realised that there a huge new market: women. So, the salesmen turned their entire arsenal towards women. They started showing women mustangs and corvettes, impressive V8 engines, incredible horse power, the beautiful roar of the engine, how fast and powerful they are, how fast they go from 0 to 60 miles per hour, how cool the cars were.
Cool vs Chic
Well, this meant nothing to women. They didn't want cool they turned out to want 'chic'. Women had no idea what V8, 5s 0-60, 160mph, roars etc meant. The first thing they wanted was a mirror to be able to powder their noses, check the makeup, a place to put their purse?, colors to match the shoes etc. Of course, I am kidding, but I am trying to emphasize that women had completely different expectations about cars. They didn't want 'cool', they wanted 'chic'. They didn't want to show power and masculinity , but independence.
The reason behind this strory is to explain how important is to know your market. Men knew how to sell cars to men. We programmers try to sell software to clients as if they were programmers, when instead the client has completely other objectives, just like women did with cars.
Sell to managers
I noticed that many presentations of a software solutions miss their target, because instead of showing the customer representatives there, which are mostly management people how the program works for managers, how to extract the info, because this is what managers want, they show them how the application can add and save data to a database.
The managers see the purpose of a program as getting THE information needed now. This gives them what they want: power by controlling the information. If you present a software to managers, show them the manager's dashboard that displays the instant data, the main reports and not how your application puts the data in (unless they ask).
I strongly advise you to look at Google. It is so sucessfull not by being a search tool, but by giving you the info you want. Everyone feel the power of getting information instantly at Google. They sell the solution because they know that the clients don't want to search, they want to find.
Conclusion
I hope to have achived to explain you that us programmers ofter put techincal ingeniousity before customer demands, we ofter tend to tell the customer what he wants instead of letting him tell us what he wants. I believe that because of this reason we do not build sellable products, but we tend to build expressions of our egos in our software, to show the other programmers how good we are and not the customers.
Sunday, March 20, 2005
Thursday, February 24, 2005
The beauty of MVC (article/technology)
You can download the sources: Sources
Introduction
I have two very "dear" design/architectural patterns, that I carry around with me in all projects, technologies, boundaries. I might say "their usage should be enforced by law". Just kidding :) One of them is MVC, the other is n-tier/layered architectures, so I decided to share why I like about the first and how I explain it to my friends and coworkers.
Why should we use MVC?
I noticed that most programmers when asked why do they use a method of separating the data (model) from the user interface (view), cannot give unambiguous answers. Some would just say: because it is a good practice or ... because Martin Fowler (or the java) world recommends it. In my opinion this answer is wrong. Wrong because, a technology that is not understood can be easily misused.
So why?
In my opinion each action should, at least try, to have a goal. The goal of this separation (ui from data) is achieving the other goal of delivering the customer, useful software fast. Now let's get back to the each (as each framework, technology etc describes that using it you can deliver faster:)) and explain why.
-debugging is much easier. Firstly, because by having two files, you can watch the code easier, because it is smaller, and you get tired just from scrolling. Secondly, and more important, because you know what happens where, you can track bugs easier.
-changes can be done easier. You can change some logic without affecting the ui, or change the UI (if you're really good you can even go from web to desktop or the other way round:))
-extensions are welcome - this will bring benefits too (I am sure you can make your client pay:))
Going back to the roots
I remember when I started programming and I had to do all kings of very simple programs to solve a simple problem. Sometimes not even programs, just algorithms and pseudo-code. Nothing displaying a "hello world" MessageBox, nothing mixed with either UI of database (persistence code). Well, let's go back to that.
The simplest program I can think of is one that computes a sum, of two given numbers:
public class Sum
{
private int a = 0;
private int b = 0;
private int result = 0;
public void Compute()
{
result = a+b;
}
public int A
{
get{return this.a;}
set{this.a = value;}
}
public int B
{
get{return this.b;}
set{this.b = value;}
}
public int Result
{
get{return this.result;}
}
}
It could have been solved just be making a static method, buy I wanted to use properties. I will show you why later.
Now this is our simple program, but of course the user has to have a form of using it, so an UI is needed. Let's try a Windows.Forms approach, like this:
Screenshot
In it we will have an instance (reference) sum of Type Sum the databinding code :
this.txtA.DataBindings.Add("Text",sum,"A");
this.txtB.DataBindings.Add("Text",sum,"A");
this.txtResult.DataBindings.Add("Text",sum,"Result");
and the button is clicked:
this.sum.Compute();
Now, everything works. Just as simple I could add the UI for ASP.NET.
The controller
Now, we have exposed Sum as the model, and we have seen the view. What's the controller for?
In some cases you don't want to mix UI interface create/layout etc code with the code that actually handles the user events. You could just make a class to do that, and include there all UI logic code.
One advice, don't let the model know about the view or controller. If you really need to do something that can't be resolved through the controller or data-binding, user events that are raised by the model and captured and processed in the controller. Another advice is that you shouldn't forget that the model is in the UI layer. Make it communicate/use/encapsulate classes (datasets etc) from the business layer.
Steps in applying MVC
First listen to what the user wants in that form then you adopt one of these strategies:
1. Bottom up - code the model as if it were the simple program that I told you about, then add an interface to it
2. Top down - design the interface with the user, when he's ok about it, think about a simple program that can handle the data you send from the UI designed and be able to send the result back.
I would recommend using both, depending on the situation.
Conclusion
So the beauty of MVC in my opinion is that it allows me to see software like a game of mind again, as when I started developing, and not like something completely automatic, where you act like a machine dragging and dropping controls, datasets, adapters etc and seeing them work. MVC is one of those things in software that when applied is both beneficial technically and mentally. It is beautiful :)
Introduction
I have two very "dear" design/architectural patterns, that I carry around with me in all projects, technologies, boundaries. I might say "their usage should be enforced by law". Just kidding :) One of them is MVC, the other is n-tier/layered architectures, so I decided to share why I like about the first and how I explain it to my friends and coworkers.
Why should we use MVC?
I noticed that most programmers when asked why do they use a method of separating the data (model) from the user interface (view), cannot give unambiguous answers. Some would just say: because it is a good practice or ... because Martin Fowler (or the java) world recommends it. In my opinion this answer is wrong. Wrong because, a technology that is not understood can be easily misused.
So why?
In my opinion each action should, at least try, to have a goal. The goal of this separation (ui from data) is achieving the other goal of delivering the customer, useful software fast. Now let's get back to the each (as each framework, technology etc describes that using it you can deliver faster:)) and explain why.
-debugging is much easier. Firstly, because by having two files, you can watch the code easier, because it is smaller, and you get tired just from scrolling. Secondly, and more important, because you know what happens where, you can track bugs easier.
-changes can be done easier. You can change some logic without affecting the ui, or change the UI (if you're really good you can even go from web to desktop or the other way round:))
-extensions are welcome - this will bring benefits too (I am sure you can make your client pay:))
Going back to the roots
I remember when I started programming and I had to do all kings of very simple programs to solve a simple problem. Sometimes not even programs, just algorithms and pseudo-code. Nothing displaying a "hello world" MessageBox, nothing mixed with either UI of database (persistence code). Well, let's go back to that.
The simplest program I can think of is one that computes a sum, of two given numbers:
public class Sum
{
private int a = 0;
private int b = 0;
private int result = 0;
public void Compute()
{
result = a+b;
}
public int A
{
get{return this.a;}
set{this.a = value;}
}
public int B
{
get{return this.b;}
set{this.b = value;}
}
public int Result
{
get{return this.result;}
}
}
It could have been solved just be making a static method, buy I wanted to use properties. I will show you why later.
Now this is our simple program, but of course the user has to have a form of using it, so an UI is needed. Let's try a Windows.Forms approach, like this:
Screenshot
In it we will have an instance (reference) sum of Type Sum the databinding code :
this.txtA.DataBindings.Add("Text",sum,"A");
this.txtB.DataBindings.Add("Text",sum,"A");
this.txtResult.DataBindings.Add("Text",sum,"Result");
and the button is clicked:
this.sum.Compute();
Now, everything works. Just as simple I could add the UI for ASP.NET.
The controller
Now, we have exposed Sum as the model, and we have seen the view. What's the controller for?
In some cases you don't want to mix UI interface create/layout etc code with the code that actually handles the user events. You could just make a class to do that, and include there all UI logic code.
One advice, don't let the model know about the view or controller. If you really need to do something that can't be resolved through the controller or data-binding, user events that are raised by the model and captured and processed in the controller. Another advice is that you shouldn't forget that the model is in the UI layer. Make it communicate/use/encapsulate classes (datasets etc) from the business layer.
Steps in applying MVC
First listen to what the user wants in that form then you adopt one of these strategies:
1. Bottom up - code the model as if it were the simple program that I told you about, then add an interface to it
2. Top down - design the interface with the user, when he's ok about it, think about a simple program that can handle the data you send from the UI designed and be able to send the result back.
I would recommend using both, depending on the situation.
Conclusion
So the beauty of MVC in my opinion is that it allows me to see software like a game of mind again, as when I started developing, and not like something completely automatic, where you act like a machine dragging and dropping controls, datasets, adapters etc and seeing them work. MVC is one of those things in software that when applied is both beneficial technically and mentally. It is beautiful :)
Friday, February 04, 2005
The GAP between what needs to and what is
The gap applied on an agile process: who was guilty?
After being a software developer for more then 4 years, working directly and indirectly with customers, I had the opportunity in the last two months to become a software customer. This experinece was quite beneficial, and "the gap" problem is one of the things I encontered direcly.
Both I and the developer, came in and stayed troughout the project with the best intentions. But there were still missunderstandings, that we successfully overcame but I wanted to get to the bottom of them. Many times, I was very occupied at work so I didn't have the time or was too tired to be able to update specifications, answer to questions in useful time. This disrrupred the main thing affecting any good collaborative project: communication.
Having other more important things to do all day, just increased the gap and might have comporomised the entire project, even between a customer and a client with the best intentions. This was mostly my fault. And probably every customer, thinks (rightfully) that he had nothing to do with the failure, because he had more important things to do.
The closer the customer, the better the software
The customer must make a good compromise between his job and the time he can allocate the developers , to answer questions, kill ambiguity in specifications, give feedback, "steer" the development.
This lack of time, or more urgent things to do in their day to day activity, will always happen with the customers. This is the thing that must be overcome but any agilist, people that try to get the customer involved as much as possible.
Sell this to the customer. The need to be as colose as possible. The need to reorganize some activities in order to be close to you when you need him. Probably this is the hardest thing that must be sold to the customer, along with the software, if you want to embrace an agile methodology, but is well worth it. Afterall, the closer the customer, the better the software.
Conclusion
Even with motivated parties involved in a project, a gap between what must be implemented and what is implemented wil always appear. Keeping this gap, as small as possible cannot be done in a single step, and must probably begin when you first contact the client, "preparing" him that his attention will be very necessary, even though he's got a lot of other more important things to do. Then by using an iterative/incremental development process, applied with small iterations (2-4 weeks), and with frequent releases to the users, that won't let the gap grow, . After all, if you try to cover this gap after 6 months, you might not be able to do it anymore ...
After being a software developer for more then 4 years, working directly and indirectly with customers, I had the opportunity in the last two months to become a software customer. This experinece was quite beneficial, and "the gap" problem is one of the things I encontered direcly.
Both I and the developer, came in and stayed troughout the project with the best intentions. But there were still missunderstandings, that we successfully overcame but I wanted to get to the bottom of them. Many times, I was very occupied at work so I didn't have the time or was too tired to be able to update specifications, answer to questions in useful time. This disrrupred the main thing affecting any good collaborative project: communication.
Having other more important things to do all day, just increased the gap and might have comporomised the entire project, even between a customer and a client with the best intentions. This was mostly my fault. And probably every customer, thinks (rightfully) that he had nothing to do with the failure, because he had more important things to do.
The closer the customer, the better the software
The customer must make a good compromise between his job and the time he can allocate the developers , to answer questions, kill ambiguity in specifications, give feedback, "steer" the development.
This lack of time, or more urgent things to do in their day to day activity, will always happen with the customers. This is the thing that must be overcome but any agilist, people that try to get the customer involved as much as possible.
Sell this to the customer. The need to be as colose as possible. The need to reorganize some activities in order to be close to you when you need him. Probably this is the hardest thing that must be sold to the customer, along with the software, if you want to embrace an agile methodology, but is well worth it. Afterall, the closer the customer, the better the software.
Conclusion
Even with motivated parties involved in a project, a gap between what must be implemented and what is implemented wil always appear. Keeping this gap, as small as possible cannot be done in a single step, and must probably begin when you first contact the client, "preparing" him that his attention will be very necessary, even though he's got a lot of other more important things to do. Then by using an iterative/incremental development process, applied with small iterations (2-4 weeks), and with frequent releases to the users, that won't let the gap grow, . After all, if you try to cover this gap after 6 months, you might not be able to do it anymore ...
Saturday, January 29, 2005
The two visions about n-tier/layered systems
The best of two worlds.
The problem of ORMs has longly been reseached and debated. In order to make programs, the best proved to be OO languages. In order to persist/retrieve data the best proved to be relational databases. They are simple and more importantly fast.
Now in order for these two to work together to enable the end user to achieve his goals through better and better software, in time, two approaches have been developed: The Java world approach and the Microsoft approach.
1. The Java world approach: application servers. Everyone already knows that n-tiered/layered systems are best, especially for entreprise applications. The java world decided to let the user enjoy Java, and disregard SQL and database servers. In order to do this they developed the application servers and the EJB technology. Also, lots or ORM tools. The main concept here is that the user develops the bussiness layer, by using objects and Java in his aplication or in his application server.
2. The MS way: - CRL stored procedures. This is just showing up, and just like .NET, benefits from the Java world experience and failures. Microsoft recognized that n-tier approaches are the best, but instead of building ORM tools and application servers, they had the idea of moving the bussiness layer from the application server to the database server itself, by hosting the .NET framework into their database server and allowing developers to build the bussiness layer directly in the database server, closer to the data and independent from the UI. Suddenly, looking at ASP.NET 2.0 SQL tags, which in my opinion was not a good approach as changing one table meant changing 100 forms, makes a lot of sense. You can use the new CRL stored procedures as your middle-tier, or bussiness layer, and give one application 10 UIs.
Well, I love having concurrency on the market, so that companies are forced to come up with better and better ideas and in the end, products.
Java world , it is your turn now. Let's see your next move :)
Dan
More about CLR stored procedures at: http://msdn.microsoft.com/sql/default.aspx?pull=/library/en-us/dnsql90/html/sqlclrguidance.asp
The problem of ORMs has longly been reseached and debated. In order to make programs, the best proved to be OO languages. In order to persist/retrieve data the best proved to be relational databases. They are simple and more importantly fast.
Now in order for these two to work together to enable the end user to achieve his goals through better and better software, in time, two approaches have been developed: The Java world approach and the Microsoft approach.
1. The Java world approach: application servers. Everyone already knows that n-tiered/layered systems are best, especially for entreprise applications. The java world decided to let the user enjoy Java, and disregard SQL and database servers. In order to do this they developed the application servers and the EJB technology. Also, lots or ORM tools. The main concept here is that the user develops the bussiness layer, by using objects and Java in his aplication or in his application server.
2. The MS way: - CRL stored procedures. This is just showing up, and just like .NET, benefits from the Java world experience and failures. Microsoft recognized that n-tier approaches are the best, but instead of building ORM tools and application servers, they had the idea of moving the bussiness layer from the application server to the database server itself, by hosting the .NET framework into their database server and allowing developers to build the bussiness layer directly in the database server, closer to the data and independent from the UI. Suddenly, looking at ASP.NET 2.0 SQL tags, which in my opinion was not a good approach as changing one table meant changing 100 forms, makes a lot of sense. You can use the new CRL stored procedures as your middle-tier, or bussiness layer, and give one application 10 UIs.
Well, I love having concurrency on the market, so that companies are forced to come up with better and better ideas and in the end, products.
Java world , it is your turn now. Let's see your next move :)
Dan
More about CLR stored procedures at: http://msdn.microsoft.com/sql/default.aspx?pull=/library/en-us/dnsql90/html/sqlclrguidance.asp
Friday, December 24, 2004
Encourage a win-win relationship with your employer
Two way, honest and close relationships
I am one of the believers in close and honest two way relationships. This are in my view the best relations even when it comes to work and being professional. This kind of relationships must be kept between you, the employee and the employer - the company.
What is a good job in my opinion?
My opinion is that a good job is a good balance between 3 factors: material benefits,
working environement, career opportunities. I believe that to be able to evaluate how good your job is, means from time to time to give a grade for each of these factors, then sum them and divide by three. You can subdivide the three factors and make the same for each of them to obtain that factor's grade:
- material benefits - money and other material benefits
- working environement - conditions of work, relationships with
colleagues, management, your team, company policy etc -
- career opportunities
The 3 factors applied
Because, one very dear friend told me that in a blog I must come up with more of my experiences, and not only ideas, advices, todos. Following this observation, I must tell you how I came up with this way of thinking about a job. Some time ago, I realised I wasn't happy at the job I had, so like any conscius employee I started to look for the reasons of why this happens. I didn't leave instantly, but only after realising that maybe there was nothing that could be done to improve my, and my colleagues, situations.
Was this courage or cowerdness? Do I feel better now? Do they feel better now? For the last two questions the answers are yes.
What do others say?
Recently, I read a very interesting small article called "Keeping your employees happy"
. The most interesting fact about this article is that is written by an employer. They have a list of things that an employer must do that I tried to divide from my "3 factors" point of view:
- Give your employees autonomy. - working environement - motivation
- Involve your employees in decisions. - working environement - motivation
- Help your employees to grow - career opportunities
- Actively support long term career growth. - career opportunities
- Promote your best employees. - all three
- Get out of your office. - working environement
- Recognize and reward the behavior you want to see repeated. -
working environement - motivation
- Say no when you mean no. - working environement - honesty
- Pay well - material benefits
I must congratulate her for encouriging employees to honestly tell their employers about the problems they have early and honestly. About encouriging feedback. About encouraging win-win situations between employee and employer.
Two way, honest and close relationships applied
Going back to my situation I must congratulate my employer for being the way he is. Should I congratulate myself and my colleagues also for contributing to maintaining this way of relationship, of working environement? Should we rest now, that everythiing is ok. By no means, no. A good relasionship is earned hard and is it based on trust. Maintaining it requires a big effort but it is deffinately worth it.
What to do?
When you are working in a company, the company has different means of showing you what their expetations are from you, what you need to do in order for them to be happy with you. So, if your company constantly tells you or hints you what to do to make them happy, maybe it is time to remind them how to make you happy. Show them honestly your grades. Show them at least the article mentioned above, and where you feel something could be done. Don't demand, speak openly and honestly,incourage a better two way relationship with your employer.
If communication is the main factor in a project's success or failure, and it must constanly be improved. Not in quantity but in quality. One aspect of this is your relationship with your employer. Most time, you need the courage to go forward and improve this communication, not just wait for the other side to make the first step.
Help your employer have a win-win situation with you. It is not always possible, but try first, keep trying , then maybe it is time to say goodbye, if the "3 factors" test fails. Courage is a great tool, just use it right.
Dan Bunea
I am one of the believers in close and honest two way relationships. This are in my view the best relations even when it comes to work and being professional. This kind of relationships must be kept between you, the employee and the employer - the company.
What is a good job in my opinion?
My opinion is that a good job is a good balance between 3 factors: material benefits,
working environement, career opportunities. I believe that to be able to evaluate how good your job is, means from time to time to give a grade for each of these factors, then sum them and divide by three. You can subdivide the three factors and make the same for each of them to obtain that factor's grade:
- material benefits - money and other material benefits
- working environement - conditions of work, relationships with
colleagues, management, your team, company policy etc -
- career opportunities
The 3 factors applied
Because, one very dear friend told me that in a blog I must come up with more of my experiences, and not only ideas, advices, todos. Following this observation, I must tell you how I came up with this way of thinking about a job. Some time ago, I realised I wasn't happy at the job I had, so like any conscius employee I started to look for the reasons of why this happens. I didn't leave instantly, but only after realising that maybe there was nothing that could be done to improve my, and my colleagues, situations.
Was this courage or cowerdness? Do I feel better now? Do they feel better now? For the last two questions the answers are yes.
What do others say?
Recently, I read a very interesting small article called "Keeping your employees happy"
. The most interesting fact about this article is that is written by an employer. They have a list of things that an employer must do that I tried to divide from my "3 factors" point of view:
- Give your employees autonomy. - working environement - motivation
- Involve your employees in decisions. - working environement - motivation
- Help your employees to grow - career opportunities
- Actively support long term career growth. - career opportunities
- Promote your best employees. - all three
- Get out of your office. - working environement
- Recognize and reward the behavior you want to see repeated. -
working environement - motivation
- Say no when you mean no. - working environement - honesty
- Pay well - material benefits
I must congratulate her for encouriging employees to honestly tell their employers about the problems they have early and honestly. About encouriging feedback. About encouraging win-win situations between employee and employer.
Two way, honest and close relationships applied
Going back to my situation I must congratulate my employer for being the way he is. Should I congratulate myself and my colleagues also for contributing to maintaining this way of relationship, of working environement? Should we rest now, that everythiing is ok. By no means, no. A good relasionship is earned hard and is it based on trust. Maintaining it requires a big effort but it is deffinately worth it.
What to do?
When you are working in a company, the company has different means of showing you what their expetations are from you, what you need to do in order for them to be happy with you. So, if your company constantly tells you or hints you what to do to make them happy, maybe it is time to remind them how to make you happy. Show them honestly your grades. Show them at least the article mentioned above, and where you feel something could be done. Don't demand, speak openly and honestly,incourage a better two way relationship with your employer.
If communication is the main factor in a project's success or failure, and it must constanly be improved. Not in quantity but in quality. One aspect of this is your relationship with your employer. Most time, you need the courage to go forward and improve this communication, not just wait for the other side to make the first step.
Help your employer have a win-win situation with you. It is not always possible, but try first, keep trying , then maybe it is time to say goodbye, if the "3 factors" test fails. Courage is a great tool, just use it right.
Dan Bunea
Wednesday, December 22, 2004
Estimating - an art that everyone should know?
Fortunately, I am one of those lucky enough to be able to give estimates for my work. My company is mostly based on programmers estimating the technical work, which probably is one of the best things a business can do (just like leaving business people estimating business stuff). But do we really know how to estimate how much work a particular feature will take to implement? Maybe yes in some cases and no in others, but as agilists and perfectionists I think that we must constantly look back and improve.
Ok, so how is estimating done?
The best method of estimating is explained in K.Beck’s and M.Fowler’s book: Planning Extreme Programming: “Say you’ll do as much tomorrow as you actually got done today” meaning that the best method to estimate is to use your own previous experience. If personal experience is not good enough maybe you can use a colleague’s experience or be able to find a thing in the past that was twice as big as what you need to estimate, or twice as small. But be careful , because the further you get from your own experience when it comes to estimating, the lower the precision.
What happens if the work is new? Kent Beck said in the same book mentioned above that when you do not have experience is to fake it. Make a small prototype and estimate based on that prototype.
But why it still fails?
Ok now that I have emphasized how simple is to estimate, is this enough? Why there are still very many people, very good programmers that have big differences in estimates compared to actual time. What influences us when we are estimating? One cause might be that mostly nobody looks back and cares to take a note on how much a feature took to implement and how big was the error in estimate vs actual. The second thing would be in my opinion, either people are too relaxed or too pressured to give better estimates. The third in my list of reasons is that programmers who take pride in their own work usually give estimates in ideal time considering the best possible efficiency they might have. Is this something very wrong? No, I think that in many cases, it only shows the programmers need to outdo themselves, to test their own limits. This is very beneficial in some aspects, but applied for a long time might lead to demotivation and stress as the estimates are far from the actual time, stress that is at all levels, from the customer to the other teammates and even to the one that gave the estimate, who starts losing confidence in himself.
So what should we do?
My opinion is that first people must become aware of the importance of giving not perfect but better estimates, then start doing it, just as the Chinese said that the thousand miles walk begins with the first step. Then the most important thing, like in all agile methods is to look back and improve in time.
What do you think?
Dan Bunea
Ok, so how is estimating done?
The best method of estimating is explained in K.Beck’s and M.Fowler’s book: Planning Extreme Programming: “Say you’ll do as much tomorrow as you actually got done today” meaning that the best method to estimate is to use your own previous experience. If personal experience is not good enough maybe you can use a colleague’s experience or be able to find a thing in the past that was twice as big as what you need to estimate, or twice as small. But be careful , because the further you get from your own experience when it comes to estimating, the lower the precision.
What happens if the work is new? Kent Beck said in the same book mentioned above that when you do not have experience is to fake it. Make a small prototype and estimate based on that prototype.
But why it still fails?
Ok now that I have emphasized how simple is to estimate, is this enough? Why there are still very many people, very good programmers that have big differences in estimates compared to actual time. What influences us when we are estimating? One cause might be that mostly nobody looks back and cares to take a note on how much a feature took to implement and how big was the error in estimate vs actual. The second thing would be in my opinion, either people are too relaxed or too pressured to give better estimates. The third in my list of reasons is that programmers who take pride in their own work usually give estimates in ideal time considering the best possible efficiency they might have. Is this something very wrong? No, I think that in many cases, it only shows the programmers need to outdo themselves, to test their own limits. This is very beneficial in some aspects, but applied for a long time might lead to demotivation and stress as the estimates are far from the actual time, stress that is at all levels, from the customer to the other teammates and even to the one that gave the estimate, who starts losing confidence in himself.
So what should we do?
My opinion is that first people must become aware of the importance of giving not perfect but better estimates, then start doing it, just as the Chinese said that the thousand miles walk begins with the first step. Then the most important thing, like in all agile methods is to look back and improve in time.
What do you think?
Dan Bunea
Thursday, December 16, 2004
hello world!
I decided to start a blog and log my adventures into the world of software development. I would like to focus my attention especially on my experiences on working methods, on good and bad practices I encountered and on ideas I got either directly then saw they were invented much earlier but I didn't know about them or on practices I read about in the great world of books, then applied them more or less sucessfully.
Dan
Dan
Subscribe to:
Posts (Atom)