On controlling software projects.

I have a hypothesis: People like to be in control of their software. That is, people like to have the full empowerment to change anything inside their system. The basic reason for this is simple: If you find a piece of the system that is bad, you want the right to redo that part of the system because you can see it will hamper your work later on. Looking back at a particular project made me realize that I weren't in control of it. We simply were too many hackers with a stake in different aspects of the system. Furthermore, since the system was put into production, there was also the army of marketdroids who wanted their stakes in the system. In effect, depending on how much power you had, parts of the system was carved down in stone. The result was utter disaster: Our data model sucked dead moose through bent straws. Yet nobody had the empowerment to change the data model. Hence, you really had no control of your code. About 70% of the code you wrote for any task was workaround code on the bad data model. This meant complexity skyrocketed to the point where no project could complete. At one point, I suddenly realized that I was not in control of the system that made the most problems. Then I realized that no programmer was in control. All the choice was on the marketdroids, and boy, did they make bad decisions. Rather than focusing on building a better system with a vision for how the components should fit together, they just threw in more stuff on top of the garbage pile. In sports psychology, it is all about focusing on the knobs that you are able to turn, and defocussing on the knobs which are turned for you by luck and coincidence. It is interesting how that knowledge applies to the above. In fact, the only knob you control is your sanity. Then, I realized it was time to move on.