Do you feel that the urgency with which clients want to see finished products and deadlines can lead to badly written unclean code? If so how do you argue the case for taking time and doing things the right way?
Well, in any business where you are not developing for fun but for money, there is urgency.
However, I don’t think it’s the clients’ fault. It’s our fault.
We as developers often don’t act professional. When a client requests a feature from you, you migt think –
oh that will take 20 days. And saying that, you think in 20 perfect days, and often, you forget about analysis, design, and test –
you just think in 20 perfect development days. To make it worse, often, the average developer would say to him/herself –
uuuuh but 20 days will make me look stupid, lazy. I know I can work hard. If I work really hard, do some extra hours,
I can make it in 10 days, and I will be a hero. So we as developers commit on 10 days, we will work VERY hard,
even at night thinking about the code, and still, 10 days was way to optimistic. We will deliver in 15 days, 50%
longer than we commited on. And the code quality will be BAD! Now what would you as a client think?
They can’t keep up with their own promise, and the quality is very low. => Highly disappointing.
When you estimate, you must estimate for a fully finished product, and that does include proper tests
(unit, component, integration, mutation), as well as clean code and clean simple architecture.
So we might come up with 30 days for that, 30 perfect days. And as you know, we are humans,
sometimes you just can’t focus, sometimes you have personal issues in your head – some things might go different than expected –
we should commit on 35 days for example, with our own personal goal of delivering in 30 days.
Now if everything works out fine, you should be able to deliver a perfect, bug free product, in 30-31 days.
Now what will the client think this time? They commited on 35 days, they delivered in 31 days, and the quality
is just AWESOME! => Happy, happy, happy!!!
We should always try to deliver more / earlier than was expected from us.
Now there is still a problem – competitors – other companies or simply colleagues.
You say it will take you 35 days, and your colleague jumps in and promises to do it in 10 days.
Well, in this case – I step back and let the other company / your colleague proof he can deliever quality in that time.
A developer must also say “no” sometimes and stand to his/her own decisions!
Do you feel that the urgency with which clients want to see finished products and deadlines can lead to badly written unclean code? If so how do you argue the case for taking time and doing things the right way?
Well, in any business where you are not developing for fun but for money, there is urgency.
However, I don’t think it’s the clients’ fault. It’s our fault.
We as developers often don’t act professional. When a client requests a feature from you, you migt think –
oh that will take 20 days. And saying that, you think in 20 perfect days, and often, you forget about analysis, design, and test –
you just think in 20 perfect development days. To make it worse, often, the average developer would say to him/herself –
uuuuh but 20 days will make me look stupid, lazy. I know I can work hard. If I work really hard, do some extra hours,
I can make it in 10 days, and I will be a hero. So we as developers commit on 10 days, we will work VERY hard,
even at night thinking about the code, and still, 10 days was way to optimistic. We will deliver in 15 days, 50%
longer than we commited on. And the code quality will be BAD! Now what would you as a client think?
They can’t keep up with their own promise, and the quality is very low. => Highly disappointing.
When you estimate, you must estimate for a fully finished product, and that does include proper tests
(unit, component, integration, mutation), as well as clean code and clean simple architecture.
So we might come up with 30 days for that, 30 perfect days. And as you know, we are humans,
sometimes you just can’t focus, sometimes you have personal issues in your head – some things might go different than expected –
we should commit on 35 days for example, with our own personal goal of delivering in 30 days.
Now if everything works out fine, you should be able to deliver a perfect, bug free product, in 30-31 days.
Now what will the client think this time? They commited on 35 days, they delivered in 31 days, and the quality
is just AWESOME! => Happy, happy, happy!!!
We should always try to deliver more / earlier than was expected from us.
Now there is still a problem – competitors – other companies or simply colleagues.
You say it will take you 35 days, and your colleague jumps in and promises to do it in 10 days.
Well, in this case – I step back and let the other company / your colleague proof he can deliever quality in that time.
A developer must also say “no” sometimes and stand to his/her own decisions!