Many times I find myself trying to explain something saying that I believe that is very simple and often it is viewed as more complex. I was in a conversation with Graham last night as we were reviewing some stored procedures created a couple of years ago and he said "Jim is right this really is very complex".
One of the things I get out of this comment is that often if I only see something as simple, it does not give the right perspective to the nature of the issue that is at hand. When we do this with technology, we often overlook the complexity and this will often cause us to use the wrong approaches in development, management, testing or support.
To take it in a slightly different than technical direction, think about the difference between a project or a program. I once was involved in a project audit and the banking customer and one of the biggest observations was had was that when the project started it was small and manageable as a project. Somewhere in the project there was a change in the nature of the project (system, scope, interfaces, business model) and the project managed these with changes through a CR process, but there was no ability to realize that this project had really morphed into a program that needed multiple releases. The findings really showed that if the perspective had changed there would have been a better chance to generate a successful conclusion.
These examples really drive home the idea of the difference in how you view or discuss the problem can have in this case a negative effect. The same is true that if we can find a way to always be challenging our viewpoints and basis of understanding, we have a great chance to help ourselves and others be able to grasp the scope or nature of the issue at hand.
Ohh the power of words.
I got it now, I think. The concept may be simple which is good but the implementation or realization may be complex. By doing it in steps it may be simpler.
I also think we are so keen to to get to D we do not see the merit in getting to B.
I think if we made A, B, C, and D all projects in the Program we might be able to focus on A before leaping to the end result.
I think we may be on to something here.
I think we often are not ready for iteration or steps so we can learn and modify.
Am I understanding the point a little better?
You are right Jim. The reason I often wanted to call things simple which was where it stopped to often was to describe the top level concept. Move from Point A to B to C to D and in each step we are doing x,y and z.
This is often how the conversation should start to show how the problem is being addressed. All of the items may be more or less complex and this is where you drive through things.
The challenge with the example I just gave is that it often marginalizes the influences outside of A to D that can have a significant effect. As well you are right if I keep hounding on how simple it is, it makes it difficult to keep asking questions and that is wrong.
Just because we say there is no stupid question, does not mean people wont stop from asking them. This breaks down communication and stops the level of teamwork required.
I think I am right about the complexity. But the next question is “So what?” I expect we need to explain things in different ways. Maybe saying or thinking “this is simple” does not help the dialog. It also discourages one from asking questions because if it is simple why can’t I understand it.
Admitting that I do not understand something takes a lot of humility. Something I need more off.
Makes me think of “Difficult Conversations” and how much we assume others see things the way we do. If I understand it, it must be simple.