Monday, October 10, 2011
Three Reasons why enterprises are plagued with bad code...
We all know that IT Outsourcing to India can most certainly result in suboptimal code, I humbly believe there is a bigger reason for why code in large enterprises continues to be fundamentally bad...
I believe the Project Management Institute (PMI) is a terrorist organization that teaches non-technical project managers how to deliver low-quality code and that they are the biggest impediment to creating high quality code. Let's face it, the majority of project managers continue to deliver projects over budget and late. This of course starts with bad estimation techniques but almost always concludes with a call for developers to write code quickly and the decline begins.
How many times have you participated on projects where some assclown makes a call to just get it out the door and to leave perfection to God. This usually is done under the premise that if they don't get it out the door, the project may die quickly. In order words, the people who control developers are telling developers that maintainability of code is a second priority. Some PMs though are at least considerate enough to make cordial statements that they will set aside time after the rollout, but we all know that day never comes.
More importantly, after the successful rollout you can almost count on a diatribe from your friendly neighborhood CIO congratuating the team for speedy delivery followed by a statement that encourages the next release cycle to have an even more tight schedule. After several maintenance cycles, bad code accumulates and everyone has accepted the reality that the code is bad, there is zero opportunity to improve and motivation to do better is destroyed.
With every increasing iteration, developers become even more under the gun and start taking shortcuts. Why spend time understanding convuluted code when it is faster to write duplicate code from scratch. We know that any findings from code reviews won't matter, so just resort to cut-and-paste whenever possible. Now that the PMs have successfully indoctrinated the developers in ways to make quality unimportant, it is now time for the developers to foist this mindset on others downstream in the lifecycle.
Some infrastructure person will sooner or later question the quality of code being released. The developer community will then team up, leverage misdirection techniques and simply blame the infrastructure team for their inability to do proper capacity planning. The infrastructure team over time also gets infected and simply shuts up and adds more servers. Sooner or later your data center has thousands of servers when it only needed several hundred.
You can finish the rest of the story as this is all to familair to anyone who has worked in a large enterprise...
| | View blog reactionsI believe the Project Management Institute (PMI) is a terrorist organization that teaches non-technical project managers how to deliver low-quality code and that they are the biggest impediment to creating high quality code. Let's face it, the majority of project managers continue to deliver projects over budget and late. This of course starts with bad estimation techniques but almost always concludes with a call for developers to write code quickly and the decline begins.
How many times have you participated on projects where some assclown makes a call to just get it out the door and to leave perfection to God. This usually is done under the premise that if they don't get it out the door, the project may die quickly. In order words, the people who control developers are telling developers that maintainability of code is a second priority. Some PMs though are at least considerate enough to make cordial statements that they will set aside time after the rollout, but we all know that day never comes.
More importantly, after the successful rollout you can almost count on a diatribe from your friendly neighborhood CIO congratuating the team for speedy delivery followed by a statement that encourages the next release cycle to have an even more tight schedule. After several maintenance cycles, bad code accumulates and everyone has accepted the reality that the code is bad, there is zero opportunity to improve and motivation to do better is destroyed.
With every increasing iteration, developers become even more under the gun and start taking shortcuts. Why spend time understanding convuluted code when it is faster to write duplicate code from scratch. We know that any findings from code reviews won't matter, so just resort to cut-and-paste whenever possible. Now that the PMs have successfully indoctrinated the developers in ways to make quality unimportant, it is now time for the developers to foist this mindset on others downstream in the lifecycle.
Some infrastructure person will sooner or later question the quality of code being released. The developer community will then team up, leverage misdirection techniques and simply blame the infrastructure team for their inability to do proper capacity planning. The infrastructure team over time also gets infected and simply shuts up and adds more servers. Sooner or later your data center has thousands of servers when it only needed several hundred.
You can finish the rest of the story as this is all to familair to anyone who has worked in a large enterprise...
