Being an expert isn't telling other people what you know. It's understanding what questions to ask, and flexibly applying your knowledge to the specific situation at hand. Being an expert means providing sensible, highly contextual direction.
Showing posts with label culture. Show all posts
Showing posts with label culture. Show all posts
Wednesday, February 18, 2009
Quote Of The Day
From Coding Horror: Are You An Expert?:
Tuesday, February 17, 2009
Best Practices: Totally Useless
Favorite quotation from this article:
I was leading a project being executed by a team of cargo cult followers with copy'n'paste being the favorite technique. I've tried to nudge the developers gently into not doing certain things that were making my hair stand on end. Then, I was confronted with the statement saying that I'm being nitpicky, and need to make up my mind and "set expectations" (another beautiful corporatese term). Grudgingly, I put together the list, trimmed it down to a couple of dozen items, and passed it up. Lo and behold, it's been declared that they understand the futility of trimming down (because the "best practices" get lost in the process), and that they will take care of collecting "the words of wisdom".
Next thing I knew, the Holy Writ expanded to over two hundred commandments, and it was declared that the mental capacity of one can never be sufficient to hold that much knowledge.
And indeed, the behavior demonstrated by participants was alike to the way a sponge reacts when it is saturated: all extra water simply drips off, never penetrating the surface.
Well...
In this particular case, the only technique that actually worked was - vigilant activity monitoring (post commit, hence, post factum, unfortunately), combined with vigilant followup and correction enforcement (using terms of originally referenced article, "making sure you reach the unreachable"). After several months of this, the developers either finally started to comprehend what was required, or, possibly, got tired of redoing the same stuff fifty times and decided that it would be simpler for them to just follow the directions from the beginning rather than to try to be lazy and cut all corners possible.
The downside is that such an approach is bogging you down and forces to shift the attention to mundane things ("Never wrestle with a pig. You get dirty, and the pig enjoys it"). However, given the situation when "you have to work with the team that you're given" (which is often the case in enterprise, especially now that extreme cost savings are in effect), this may be the only option left.
UPDATE: Fixed typo.
Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise on their head where the book bounced off.This is exactly what happened to me recently.
I was leading a project being executed by a team of cargo cult followers with copy'n'paste being the favorite technique. I've tried to nudge the developers gently into not doing certain things that were making my hair stand on end. Then, I was confronted with the statement saying that I'm being nitpicky, and need to make up my mind and "set expectations" (another beautiful corporatese term). Grudgingly, I put together the list, trimmed it down to a couple of dozen items, and passed it up. Lo and behold, it's been declared that they understand the futility of trimming down (because the "best practices" get lost in the process), and that they will take care of collecting "the words of wisdom".
Next thing I knew, the Holy Writ expanded to over two hundred commandments, and it was declared that the mental capacity of one can never be sufficient to hold that much knowledge.
And indeed, the behavior demonstrated by participants was alike to the way a sponge reacts when it is saturated: all extra water simply drips off, never penetrating the surface.
Well...
In this particular case, the only technique that actually worked was - vigilant activity monitoring (post commit, hence, post factum, unfortunately), combined with vigilant followup and correction enforcement (using terms of originally referenced article, "making sure you reach the unreachable"). After several months of this, the developers either finally started to comprehend what was required, or, possibly, got tired of redoing the same stuff fifty times and decided that it would be simpler for them to just follow the directions from the beginning rather than to try to be lazy and cut all corners possible.
The downside is that such an approach is bogging you down and forces to shift the attention to mundane things ("Never wrestle with a pig. You get dirty, and the pig enjoys it"). However, given the situation when "you have to work with the team that you're given" (which is often the case in enterprise, especially now that extreme cost savings are in effect), this may be the only option left.
UPDATE: Fixed typo.
Thursday, December 11, 2008
Handcuff Notes: Writing Fortran In Any Language
More than once I've noticed that working with quality source code is easy and pleasant in any IDE, of which I've seen quite a few, or even without an IDE.
Likewise, working with crappy source is painful no matter what IDE is used. It just falls apart and explodes in your face, leaving scars on your brain as its shards fly by.
Once again, the realization that good software engineering is in perfect accord with Wu Wei, comes with enlightenment.
Likewise, working with crappy source is painful no matter what IDE is used. It just falls apart and explodes in your face, leaving scars on your brain as its shards fly by.
Once again, the realization that good software engineering is in perfect accord with Wu Wei, comes with enlightenment.
Thursday, August 21, 2008
Mark My Words: Google Apps Leasing
There is a major factor limiting the Google Apps acceptance: fear.
Small companies and individuals are able to comprehend the scope, security and privacy implications of Google Apps pretty easily - O horror! Big Brother is watching you! Duh, as if The Holy Triad (Equifax, Experian and Transunion) didn't already sell your intimate financial details to everyone and their uncle.
On the other hand, big corporations are neck deep in quagmires of existing policies - hardware and software procurement and user base, information access and security, legal retention and audit, cost to exit for existing obligations to name a few.
The most important issue in the context of Google Apps is information security and privacy. The very thought of trusting the crown jewels (or, at least, what they perceive them to be) to the outside entity causes a condition close to a heart attack for those that will be held responsible for the decision that's been made. Corporate officials don't like that. They prefer to keep the status quo and, ideally, not change anything at all. Or, at the very least, to deal with known threats.
Consequently, the hell with freeze over before corporations will trust^H^H^H^H^Hturn over their corporate data to Google.
How can Google get out of this predicament? I see two ways.
One, provide the user accessible API that will make sure that the only way to store the corporate data on an outside server is the encrypted way. This, however, introduces the whole issue of key and/or certificate management, which is somewhat familiar (albeit annoying) to IT folks, but which is going to kick the non-IT personnel out of their socks, no matter how simple it seems for the IT enabled. I don't see this happening anytime soon.
Two, allow corporations to physically lease the hardware that hosts Google Apps, like it does it for Google Mini. This will give them the warm and cozy feeling of being in a familiar environment, never mind that the people supervising the installation will probably orders of magnitude less experienced than Google would've dedicated to support tasks. It's BAU (Business As Usual) for them, which gives them an illusion that they can deal with it like they used to, which, in turn, makes them more likely to accept this sort of nuisance.
I've been expecting this to happen since the first time this topic was brought up in a water cooler conversation, about a year ago. Let's see how long it takes Google to deliver.
Small companies and individuals are able to comprehend the scope, security and privacy implications of Google Apps pretty easily - O horror! Big Brother is watching you! Duh, as if The Holy Triad (Equifax, Experian and Transunion) didn't already sell your intimate financial details to everyone and their uncle.
On the other hand, big corporations are neck deep in quagmires of existing policies - hardware and software procurement and user base, information access and security, legal retention and audit, cost to exit for existing obligations to name a few.
The most important issue in the context of Google Apps is information security and privacy. The very thought of trusting the crown jewels (or, at least, what they perceive them to be) to the outside entity causes a condition close to a heart attack for those that will be held responsible for the decision that's been made. Corporate officials don't like that. They prefer to keep the status quo and, ideally, not change anything at all. Or, at the very least, to deal with known threats.
Consequently, the hell with freeze over before corporations will trust^H^H^H^H^Hturn over their corporate data to Google.
How can Google get out of this predicament? I see two ways.
One, provide the user accessible API that will make sure that the only way to store the corporate data on an outside server is the encrypted way. This, however, introduces the whole issue of key and/or certificate management, which is somewhat familiar (albeit annoying) to IT folks, but which is going to kick the non-IT personnel out of their socks, no matter how simple it seems for the IT enabled. I don't see this happening anytime soon.
Two, allow corporations to physically lease the hardware that hosts Google Apps, like it does it for Google Mini. This will give them the warm and cozy feeling of being in a familiar environment, never mind that the people supervising the installation will probably orders of magnitude less experienced than Google would've dedicated to support tasks. It's BAU (Business As Usual) for them, which gives them an illusion that they can deal with it like they used to, which, in turn, makes them more likely to accept this sort of nuisance.
I've been expecting this to happen since the first time this topic was brought up in a water cooler conversation, about a year ago. Let's see how long it takes Google to deliver.
Friday, August 15, 2008
Russian Programmers
This text had been originally found in Russian, and then translated for the sake of my coworkers. For many years, it was hiding in backups until I found it again recently - and I think it hasn't lost its actuality since the time it's been translated (about 2000).
Original author is unknown. Original Russian text is lost (UPDATE: found again). If you are the author, or know the author, the chance to add the reference and give credit to the person who absolutely deserves it would be appreciated.
Here goes.
Any Russian programmer will spend just a couple of minutes to read someone else's code, and then will invariably jump and start shouting to himself: The hell with it! Throw it away! Rewrite it all! Then, a glimpse of a doubt will appear in his mind for a split second, and the rest of the day he will spend convincing himself that it is not that hard of a job to rewrite it all. And if approached right, it'll be piece of cake. But it will be The Right Thing, lean and mean and clean and nice. Next morning, he's adamantly convinced and is reporting to the supervisors that rewriting the code will take a day. No more than a day. All risks included, two days. As a result, he will be granted a week, and six months later it will be successfully finished. Until another Russian programmer sees it.
Meanwhile, in the four adjacent cubicles four Chinese programmers will work hard. In some unimaginable way, these programmers are managing to appear earlier in the office than their Russian colleague, they are managing to go home later, and at the same time they are managing to do three times less together than that one Russian guy. These four haven't produced any new code for a long time, they are just maintaining the code once written by an Indian programmer and then rewritten by two Russians. Bugs don't just live in this code. They have their nest in it. This nest is constantly reproducing itself, viciously using favorite Chinese technology known as "copy'n'paste" in other parts of the world. The bugs are proliferating from this code using static and passed by reference variables (because the Chinese programmers can't stand the inconvenience of not being able to change the value of the variables passed to their modules by the calling modules the Russian programmer is busy rewriting).
When coming across this module, the Russian programmer becomes speechless for a short period of time, then starts rapidly talking a mix of Chinese and Russian. He's long planning to rewrite the Chinese module, but he doesn't have time. The Chinese are responsible for critical bugs, and the management knows about it, and is harassing them constantly. The Chinese programmers keep hastily reassigning the bugs to each other, because they suspect that their attempts to fix the bugs will cause new, even more serious bugs. And they are right in their suspicion.
There's the only person in the office able to figure out how exactly the static variables get their values and in which order - the Indian programmer. But he's meditating. Therefore, when the Chinese Gang Of Four is laid off... Why them? Who else?!?!? Russian guy hasn't finished rewriting yet, and the Indian - the company's main asset - rarely pays any attention whatsoever to the project, but when he does, everybody is suddenly reminded that there's no one else who gets the architecture. So, when Chinese are let go, the code has two possible fates. One, Russian gets it and rewrites it. Two, Canadian gets it.
The Canadian is another thing altogether. Without a slightest hesitation, he will rush forward to fix the cruelest and nastiest Chinese made bug. The Chinese reported it fixed four times (each of them once), but every time it was back, even more intimidating, like Schwarzenegger. So, the Canadian will do what Chinese have not dared to do for the last three years. He will use the debugger to find out where exactly the static variable will become -1 instead of correct 0, and with steady hand, will introduce another static variable next to it, with the correct value. The bug will be defeated.
But the price of the victory will be high.
Everything, including the code that the Russian has just finished rewriting, will cease to work. The Russian will be dumbfounded for a couple of days, after which he will announce that of course, the design was wrong from the very beginning, and everything has to be rewritten. It will take a week. No more than a week. The Canadian will valiantly move to fix the bugs, but everything will become ever worse, though who would have thought... The commotion will kick the Indian out of meditation, and he will offer a brilliant solution - to branch the code. There will be two branches - one with The Bug, but working, and another, without The Bug, but not working either. The Russian, upon hearing of such decision, will break his slide rule in half and call his wife names after he gets home, but will say nothing to the management.
Fortunately, none of it will matter at all, because the product is selling anyway. Therefore the management is generally happy and is constantly reminding the employees that they were selected as creme de la creme. And that they have firmly established their ability to release the product by being able to release it. Once in a long while.
Original author is unknown. Original Russian text is lost (UPDATE: found again). If you are the author, or know the author, the chance to add the reference and give credit to the person who absolutely deserves it would be appreciated.
Here goes.
Any Russian programmer will spend just a couple of minutes to read someone else's code, and then will invariably jump and start shouting to himself: The hell with it! Throw it away! Rewrite it all! Then, a glimpse of a doubt will appear in his mind for a split second, and the rest of the day he will spend convincing himself that it is not that hard of a job to rewrite it all. And if approached right, it'll be piece of cake. But it will be The Right Thing, lean and mean and clean and nice. Next morning, he's adamantly convinced and is reporting to the supervisors that rewriting the code will take a day. No more than a day. All risks included, two days. As a result, he will be granted a week, and six months later it will be successfully finished. Until another Russian programmer sees it.
Meanwhile, in the four adjacent cubicles four Chinese programmers will work hard. In some unimaginable way, these programmers are managing to appear earlier in the office than their Russian colleague, they are managing to go home later, and at the same time they are managing to do three times less together than that one Russian guy. These four haven't produced any new code for a long time, they are just maintaining the code once written by an Indian programmer and then rewritten by two Russians. Bugs don't just live in this code. They have their nest in it. This nest is constantly reproducing itself, viciously using favorite Chinese technology known as "copy'n'paste" in other parts of the world. The bugs are proliferating from this code using static and passed by reference variables (because the Chinese programmers can't stand the inconvenience of not being able to change the value of the variables passed to their modules by the calling modules the Russian programmer is busy rewriting).
When coming across this module, the Russian programmer becomes speechless for a short period of time, then starts rapidly talking a mix of Chinese and Russian. He's long planning to rewrite the Chinese module, but he doesn't have time. The Chinese are responsible for critical bugs, and the management knows about it, and is harassing them constantly. The Chinese programmers keep hastily reassigning the bugs to each other, because they suspect that their attempts to fix the bugs will cause new, even more serious bugs. And they are right in their suspicion.
There's the only person in the office able to figure out how exactly the static variables get their values and in which order - the Indian programmer. But he's meditating. Therefore, when the Chinese Gang Of Four is laid off... Why them? Who else?!?!? Russian guy hasn't finished rewriting yet, and the Indian - the company's main asset - rarely pays any attention whatsoever to the project, but when he does, everybody is suddenly reminded that there's no one else who gets the architecture. So, when Chinese are let go, the code has two possible fates. One, Russian gets it and rewrites it. Two, Canadian gets it.
The Canadian is another thing altogether. Without a slightest hesitation, he will rush forward to fix the cruelest and nastiest Chinese made bug. The Chinese reported it fixed four times (each of them once), but every time it was back, even more intimidating, like Schwarzenegger. So, the Canadian will do what Chinese have not dared to do for the last three years. He will use the debugger to find out where exactly the static variable will become -1 instead of correct 0, and with steady hand, will introduce another static variable next to it, with the correct value. The bug will be defeated.
But the price of the victory will be high.
Everything, including the code that the Russian has just finished rewriting, will cease to work. The Russian will be dumbfounded for a couple of days, after which he will announce that of course, the design was wrong from the very beginning, and everything has to be rewritten. It will take a week. No more than a week. The Canadian will valiantly move to fix the bugs, but everything will become ever worse, though who would have thought... The commotion will kick the Indian out of meditation, and he will offer a brilliant solution - to branch the code. There will be two branches - one with The Bug, but working, and another, without The Bug, but not working either. The Russian, upon hearing of such decision, will break his slide rule in half and call his wife names after he gets home, but will say nothing to the management.
Fortunately, none of it will matter at all, because the product is selling anyway. Therefore the management is generally happy and is constantly reminding the employees that they were selected as creme de la creme. And that they have firmly established their ability to release the product by being able to release it. Once in a long while.
Subscribe to:
Posts (Atom)
