Do you remember the last time when you had to clean someone else’s
CRAPPY code? I am sure at least once in our lifetime we had to deal
with a mess so grave that it took weeks to do what should have taken
hours? Have you seen what should have been a one-line change, made
instead in hundreds of different modules? These symptoms are all too
common in the life of a coder.
Wonder, why does this happen to code? Why good code turns into bad code? We have lots of explanations for it.
Obvious as it may sound, we complain that the requirements changed so quickly that the original design did not comply. We blame the schedules that were too tight to do things right.
We blather about stupid managers and intolerant customers and useless marketing people. But the fault, my dear friends, is not in our stars, but in us.
“We are unprofessional!!”
This may be a bitter pill to swallow. How could this mess be our fault? What about the requirements? What about the schedule? What about the stupid managers and the useless marketing peoples? Don’t they share some of the blame?
NO. The managers and marketing people look to us for the information which they can use to make promises and commitments to the clients; and even when they don’t look to us, we should not be shy about telling them what we think. The end users/clients look to us to validate the requirements and the way it will fit into the system. The project managers look to us to help work out the schedule/project plan. We are deeply associated in the planning of the project and in sharing a great deal of the responsibility for any failures; especially if those failures have to do with bad code!
“But wait!” you say. “If I don’t do what my manager says, I’ll be fired.” Probably not.
Most managers want the truth, even when they don’t act like it. Most managers want good code, even when they are obsessing about the schedule.
They may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.
To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.
So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.
Wonder, why does this happen to code? Why good code turns into bad code? We have lots of explanations for it.
Obvious as it may sound, we complain that the requirements changed so quickly that the original design did not comply. We blame the schedules that were too tight to do things right.
We blather about stupid managers and intolerant customers and useless marketing people. But the fault, my dear friends, is not in our stars, but in us.
“We are unprofessional!!”
This may be a bitter pill to swallow. How could this mess be our fault? What about the requirements? What about the schedule? What about the stupid managers and the useless marketing peoples? Don’t they share some of the blame?
NO. The managers and marketing people look to us for the information which they can use to make promises and commitments to the clients; and even when they don’t look to us, we should not be shy about telling them what we think. The end users/clients look to us to validate the requirements and the way it will fit into the system. The project managers look to us to help work out the schedule/project plan. We are deeply associated in the planning of the project and in sharing a great deal of the responsibility for any failures; especially if those failures have to do with bad code!
“But wait!” you say. “If I don’t do what my manager says, I’ll be fired.” Probably not.
Most managers want the truth, even when they don’t act like it. Most managers want good code, even when they are obsessing about the schedule.
They may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.
To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.
So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.
