Facing a Brownfield project, the obvious solution is to start over. As a general rule this does not work. Which does not mean it cannot work in isolated instances.
Consider those Brownfield projects that are so bad you or your client are willing to abandon everything and start over and do it all again. There must be multiple problems in the Brownfield. These problems have probably reached an unworkable state. Working on one problem creates other problems. One problem prevents working on another problem. Perhaps the source code for a COM component has gone missing. (I do not know what it is about COM but since it's widespread use, every company seems to have a COM component with missing source). Or perhaps knowledge of the inner workings of the system is missing. Perhaps the original perpetrators of the code have fled the scene of the crime.
So the motivation for fixing the Brownfield is the ability to fix the multiple problems. This is also why the Greenfield approach will fail. You have a mandate to fix everything in the Brownfield. But this is too much to be attempted at once.
It is not that you can not fix each of the problems in isolation. It is the combination of problems makes it exponentially more difficult. If lack of knowledge (like missing source code or fled perpetrators) is added to the mix, you will be flying blind. You may think you know what the component is supposed to do but there is tribal knowledge embedded in the source code.
But lets suppose you have jumped off and started the Greenfield to fix your Brownfield. As you solve the problems, the solutions will start to compete with each other and to a certain extent some hard trade offs will emerge. Some of these trade offs are what caused the original nest of problems in the original Brownfield. Thus the Greenfield becomes a Brownfield.
So it then becomes a race. Can you get all of the features implemented in the new Brownfield before being overwhelmed by the toxins being created.
No comments:
Post a Comment