Why can't everybody back off?
I am not talking about people leaving me alone, I am talking about people being able to quantify a problem from the right distance. This affects software development but also affects many other decisions we make in life.
If you had a leak in a water pipe and someone offered you a bucket, you would use it temporarily but you would know (hopefully) that the only sensible long-term plan is to fix the leak. That is an example of looking from the right distance - the actual problem is the leaking pipe and not the water dripping onto the carpet.
When we look at other areas of life, however, we note very quickly that people seem unable to look from the correct distance. We get too close to something and then we either miss the bigger issue or otherwise we get too stuck to our particular view and therefore become less and less able to make good long-term decisions.
In the UK, it is NOT unlawful to park on the pavements (sidewalks) unless you are causing an obstruction, a definition that is rarely invoked because it is too abstract. As a result, we have many pavements that are broken from vehicles parking on them - particularly heavy vehicles. So what do the Councils do? They look at the symptom of broken pavements and decide, quite rightly, that it is too expensive to try and keep them maintained. What do they do? Either nothing or they make some token repairs knowing full well that the pavement might be broken again within weeks. They argue - from the wrong distance - that it is an unwinnable position.
They are wrong.
When you look from the correct distance, you either decide a) cars should be allowed to park on the pavements, in which case, they need to be designed and built to withstand the weight involved or b) cars should not be allowed on pavments, therefore the law should be changed. (You might also decide to mix a and b in different areas). The idea that pavements are not strong enough but cars are allowed to park on them is neither sensible or logical but is the outcome of an evaluation that is too close to the symptom.
In the software world, many organisations have and continue to have massive cost and time overruns on projects (not quite software but the F-35 project is an obscene example of this). It happens why? Because the people who order these systems foolishly believe that a) They need the system and b) The contractor is competent therefore it will all be fine. Why is this foolish? Because we all know many projects that have failed miserably and many of them were probably run by people much more competent than you and me but yet they failed? The mistake is that the issue is not viewed from a pragmatic view, from a distance that says, "why did these projects actually fail?" I don't think that it is a hard question to answer. If you ask most people, they would tell you what went wrong: Unclear requirements, changing requirements due to long-duration projects, lack of expertise from people in charge of design or requirements, inventing "new tech" that is unknown - sometimes you don't even know if it might work, pricing based on gross estimates.
It happens time and time again and the question is, "How do we act differently so that the outcome is different" I don't know who said that madness is doing the same thing in the same way multiple times and expecting a different outcome.
Maybe the answer is that projects should never last more than 12 months. Maybe if something is larger, it needs to be devloped in stages, each of which is a deliverable in its own right. Why wait for the F-35 to build a new super helmet? Design and build one. If the F-35 dies, we use it on the next plane. New engines? Same. Maybe the answer is that the whole way a project team works needs to be reduced and simplified. Maybe a domain expert needs to be involved in every decision making process rather than assuming they are only needed when we get to design stage.
All of these decisions can be taken if we are able to recognise we are too close and take a step backwards and the same is true in Software Development and other singular job roles. Is what I am producing of a suitable quality? If not, I definitely need to recognise that and I then need to ask what is going on. Am I trying to do too much?, am I lacking process or independent review etc.? If I do it again, will it be better from what I've learned? One of the problems is that we don't teach people this, it is something that some people know instinctively, something that others have learned the hard way and something that some people don't even get - but they still write code!
I don't know what it about humans that we seem to always do it wrong. Are we too egotistical? Perhaps we care too much and want to make something work at all costs - even if it is taking too long and costing too much.
I just wish we would learn how to back off.
If you had a leak in a water pipe and someone offered you a bucket, you would use it temporarily but you would know (hopefully) that the only sensible long-term plan is to fix the leak. That is an example of looking from the right distance - the actual problem is the leaking pipe and not the water dripping onto the carpet.
When we look at other areas of life, however, we note very quickly that people seem unable to look from the correct distance. We get too close to something and then we either miss the bigger issue or otherwise we get too stuck to our particular view and therefore become less and less able to make good long-term decisions.
In the UK, it is NOT unlawful to park on the pavements (sidewalks) unless you are causing an obstruction, a definition that is rarely invoked because it is too abstract. As a result, we have many pavements that are broken from vehicles parking on them - particularly heavy vehicles. So what do the Councils do? They look at the symptom of broken pavements and decide, quite rightly, that it is too expensive to try and keep them maintained. What do they do? Either nothing or they make some token repairs knowing full well that the pavement might be broken again within weeks. They argue - from the wrong distance - that it is an unwinnable position.
They are wrong.
When you look from the correct distance, you either decide a) cars should be allowed to park on the pavements, in which case, they need to be designed and built to withstand the weight involved or b) cars should not be allowed on pavments, therefore the law should be changed. (You might also decide to mix a and b in different areas). The idea that pavements are not strong enough but cars are allowed to park on them is neither sensible or logical but is the outcome of an evaluation that is too close to the symptom.
In the software world, many organisations have and continue to have massive cost and time overruns on projects (not quite software but the F-35 project is an obscene example of this). It happens why? Because the people who order these systems foolishly believe that a) They need the system and b) The contractor is competent therefore it will all be fine. Why is this foolish? Because we all know many projects that have failed miserably and many of them were probably run by people much more competent than you and me but yet they failed? The mistake is that the issue is not viewed from a pragmatic view, from a distance that says, "why did these projects actually fail?" I don't think that it is a hard question to answer. If you ask most people, they would tell you what went wrong: Unclear requirements, changing requirements due to long-duration projects, lack of expertise from people in charge of design or requirements, inventing "new tech" that is unknown - sometimes you don't even know if it might work, pricing based on gross estimates.
It happens time and time again and the question is, "How do we act differently so that the outcome is different" I don't know who said that madness is doing the same thing in the same way multiple times and expecting a different outcome.
Maybe the answer is that projects should never last more than 12 months. Maybe if something is larger, it needs to be devloped in stages, each of which is a deliverable in its own right. Why wait for the F-35 to build a new super helmet? Design and build one. If the F-35 dies, we use it on the next plane. New engines? Same. Maybe the answer is that the whole way a project team works needs to be reduced and simplified. Maybe a domain expert needs to be involved in every decision making process rather than assuming they are only needed when we get to design stage.
All of these decisions can be taken if we are able to recognise we are too close and take a step backwards and the same is true in Software Development and other singular job roles. Is what I am producing of a suitable quality? If not, I definitely need to recognise that and I then need to ask what is going on. Am I trying to do too much?, am I lacking process or independent review etc.? If I do it again, will it be better from what I've learned? One of the problems is that we don't teach people this, it is something that some people know instinctively, something that others have learned the hard way and something that some people don't even get - but they still write code!
I don't know what it about humans that we seem to always do it wrong. Are we too egotistical? Perhaps we care too much and want to make something work at all costs - even if it is taking too long and costing too much.
I just wish we would learn how to back off.