It’s very simple: if you can not do work and still gain the same value as you would doing it, then don’t do the work.
I don't like this sentence. That word "Value". This stupid word is used all over AGILE/SCRUM but cause more problems that it fixes.
This very word "Value" as in "Business Value" is the primary cause why you now need 10 more people to do the exact same thing as developers could single handed 5 years ago.
Modern software developers are scared to change code, they keep on playing it all safe. Only small incremental changes are allowed otherwise it is a big no-no.
Don't get me wrong, I don't gable with the code or take any risks. I aim for maximum productive results with zero bugs.
This very word "Value" as in "Business Value" is the primary cause why you now need 10 more people to do the exact same thing as developers could single handed 5 years ago.
I tried many times to come up with a good explanation, but I can't without giving too much details in my projects.
I see deterioration of many teams in my company because they choose the lazy ways and the business value only. It is only short term thinking quick and easy gain. The standards are getting lower and lower but they don't realize it and neither the managers. The reason is because they play it safe, small incremental changes too afraid to change something dramatic because the code sucks.
Why don't I develop because it has business value? Because that way I will explore new code paths and solutions that does not have immediate quick values.
Why will I not be lazy? Because I will go off the safe path to explore different paths and may find news solutions that are more compact in code, more elegant and way easier to deploy.
Why don't I work in pair? Because it always end up onto debate, debate debate and pointless discussions because the other developer lacks the coding skills to see what I am doing.
I do think it is wrong to experiment just for one's own learning and generally costing the company both time, money and resources as well as giving the company long-term problems, but that is not what you are writing about. I think however that such a fear of being seen as someone that experiments against the company may help justify the fear, laziness and constant firefighting that you describe (from what I understand from your comment).
I wonder what a good approach to this might be. Document and explain the worst issue that would give the greatest benefit if solved and with a fairly low risk, present it to decision makers and others, and if a go-ahead is given, succeed with the project and document the benefits? And thus build up trust and show the merit of this approach?
One question is how to ensure that benign experimentation and boldness happens without malign experimentation happening. Maybe explain this challenge to decision makers? Though that may also touch on internal politics, cunning and the like.
Experimenting for the sake of experimenting, should not be done.
I actually learned this multiple code paths exploration back then when I needed to develop software for massive amounts of data processing in as short of time with limited hardware. I created multiple different solutions and measured the speed. The most effective one got continued and the rest removed.
Doing this will temporary create a more complex solutions but the complexity will be cleaned up and in the end you will have a deceivingly simple and effective code. But it can be done only when one developer modifies this part, without interfering by others.
Nowadays, my aim is not for speed but in ways where testing becomes way simpler, and once deployed the user does not get blocked when a bug shows up. The code will become more complex but the log files will be more readable for none-developers.
That reminds of an approach I have used a few times: The setting is that you have a problem which can be solved by a new component you would create, but you suspect or know that at least for naive implementations, its performance will not be good enough. And it would be useful to have some implementation of the component that works soon and that can be used in the rest of the system.
The approach is that you then create an interface which you seek to design in such a way that it allows for later implementations that are sufficiently fast for your current or maybe future needs. You then quickly implement a naive solution that is correct and can be used elsewhere. If or when it turns out that you do need greater performance, you then implement the faster solution, and if the interface does not need to be changed, switching between or comparing different implementations might then be easy and quick.
8 comments
0 u/roznak 20 Sep 2018 20:19
I don't like this sentence. That word "Value". This stupid word is used all over AGILE/SCRUM but cause more problems that it fixes. This very word "Value" as in "Business Value" is the primary cause why you now need 10 more people to do the exact same thing as developers could single handed 5 years ago.
Modern software developers are scared to change code, they keep on playing it all safe. Only small incremental changes are allowed otherwise it is a big no-no.
Don't get me wrong, I don't gable with the code or take any risks. I aim for maximum productive results with zero bugs.
0 u/notenoughstuff [OP] 20 Sep 2018 21:22
Is that really the case?
0 u/roznak 21 Sep 2018 18:28
Yes
0 u/notenoughstuff [OP] 21 Sep 2018 22:48
Could you explain further?
0 u/roznak 22 Sep 2018 02:21
I tried many times to come up with a good explanation, but I can't without giving too much details in my projects.
I see deterioration of many teams in my company because they choose the lazy ways and the business value only. It is only short term thinking quick and easy gain. The standards are getting lower and lower but they don't realize it and neither the managers. The reason is because they play it safe, small incremental changes too afraid to change something dramatic because the code sucks.
Why don't I develop because it has business value? Because that way I will explore new code paths and solutions that does not have immediate quick values.
Why will I not be lazy? Because I will go off the safe path to explore different paths and may find news solutions that are more compact in code, more elegant and way easier to deploy.
Why don't I work in pair? Because it always end up onto debate, debate debate and pointless discussions because the other developer lacks the coding skills to see what I am doing.
0 u/notenoughstuff [OP] 22 Sep 2018 07:18
I see, that is an excellent point.
I do think it is wrong to experiment just for one's own learning and generally costing the company both time, money and resources as well as giving the company long-term problems, but that is not what you are writing about. I think however that such a fear of being seen as someone that experiments against the company may help justify the fear, laziness and constant firefighting that you describe (from what I understand from your comment).
I wonder what a good approach to this might be. Document and explain the worst issue that would give the greatest benefit if solved and with a fairly low risk, present it to decision makers and others, and if a go-ahead is given, succeed with the project and document the benefits? And thus build up trust and show the merit of this approach?
One question is how to ensure that benign experimentation and boldness happens without malign experimentation happening. Maybe explain this challenge to decision makers? Though that may also touch on internal politics, cunning and the like.
0 u/roznak 22 Sep 2018 11:32
Experimenting for the sake of experimenting, should not be done.
I actually learned this multiple code paths exploration back then when I needed to develop software for massive amounts of data processing in as short of time with limited hardware. I created multiple different solutions and measured the speed. The most effective one got continued and the rest removed.
Doing this will temporary create a more complex solutions but the complexity will be cleaned up and in the end you will have a deceivingly simple and effective code. But it can be done only when one developer modifies this part, without interfering by others.
Nowadays, my aim is not for speed but in ways where testing becomes way simpler, and once deployed the user does not get blocked when a bug shows up. The code will become more complex but the log files will be more readable for none-developers.
0 u/notenoughstuff [OP] 22 Sep 2018 11:55
That reminds of an approach I have used a few times: The setting is that you have a problem which can be solved by a new component you would create, but you suspect or know that at least for naive implementations, its performance will not be good enough. And it would be useful to have some implementation of the component that works soon and that can be used in the rest of the system.
The approach is that you then create an interface which you seek to design in such a way that it allows for later implementations that are sufficiently fast for your current or maybe future needs. You then quickly implement a naive solution that is correct and can be used elsewhere. If or when it turns out that you do need greater performance, you then implement the faster solution, and if the interface does not need to be changed, switching between or comparing different implementations might then be easy and quick.