> That's a bit harsh. Maybe the developer simply has > _learned_ to develop > and troubleshoot in this way: > > - if it happens on platform X but not on platform > m Y, > what's the conclusion ? > "platform X has a problem"
Error. This first thing that I would think of is: "I haven't covered all the edge cases. The program isn't robust enough. I haven't built in enough intelligence into the program." And further: "can the program be simplified further, to rule out as many edge cases as possible"? An incompetent "developer" will not think in this way. An incompetent developer will think and even say "oh great, they messed up their system and now I have to deal with it; more work." I see, am told and experience this every single day. I can't even describe how rotten, wrong and depressing that feels. > Sounds strange to act like this ? Well - check, for > example: > > http://www.itsmsolutions.com/newsletters/DITYvol2iss > 4.htm > > It's being taught that way. Particularly if people > don't understand all of > the methodology, but focus on the 'single steps', > i.e. rip the questions > out of context. Which, as the above shows, is all too > common. What I read in that article is a management that obviously never had his hands "dirty" with trying to put the bread on the table as a sysadmin in the trenches. Troubleshooting is not a "team activity", because that would fall under the "too many cooks spoil the broth" category. Effective troubleshooting is a matter for at most three people; anything over that becomes philosophy and a waste of time (and generates more cost). That however does not exclude making use of specialized knowledge of a guru in the problem domain. A good troubleshooter will know with whom to speak and where to get the required information, or even find out which information is required. > Why does that happen ? > > Personality profiling often ends up categorizing > people into "procedural" > and "optional" behaviour patterns wrt. to how they > work. > The former will follow checklists, such as the > example just shown, and are > very prone to strongly believe argumentation as just > shown is actually > "technical". > The latter will be horrified by that and say "need > more info / looking > into before asserting any blame". *Chuckle* I'm not sure if you're alluding at me. You formed the paragraph very ambigously, perhaps on purpose? Were you trying to tell me I should have gathered more information "before asserting any blame"? > Who makes a better programmer ? Good question. I know > many "procedural" > people who churn out code at 20x as fast as I > could... ...and to round the selection out, I know many people (I'm surrounded by them) that take 20x as long as I would to produce code that is 100x worse than anything I've ever seen... and get paid high salaries for it. Awesome, isn't it? > > Vendors like finger pointing, but all that does is > make them lose business... > > Not necessarily. This sort of behaviour is normal. You dear company did that to me once. I explained and explained. The responsible people continued with their version of "not our problem, will not fix", even though it was the Solaris kernel that had been complaining violently. That was strike one. Strike two was when I had support working on a different problem and they weren't getting anywhere, so finally they figured I'd become too expensive to support and wanted to give me "not a Sun system, unsupported hardware, can't support", until I sent them a screenshot where marketing proudly proclaimed "don't get caught in the middle", and "will support 3rd party systems". The fix turned out to be a single line that turned on DMA, a non-documented entry in /kernel/drv/ecpp.conf, and lo and behold, everything started working. The cause was the fact Solaris 10 didn't support ACPI particularly well, (read: wouldn't work), so ACPI had to be shut off. This caused lockups during printing because DMA for the parallel port was shut off. This whole action lasted about six months of back and forth. For one undocumented line in ecpp.conf. The net effect was that I didn't renew my support contract, and your dear firm increased the price of support about 3x. Tja, that's life. The point is this: finger pointing days are over. When the customer says "jump", the company must ask "how high", or else risk being devastated by the Wall-Street and the analysts. Something to wrap one's brain around. > That's why I gave an > extensive answer. All shown so far points towards an > application bug, but > then if more information surfaces that'd show Solaris > did something wrong > which "surprised" the application - fine, I'll > investigate then. Just so > far, no such information has been forthcoming. They > might already have > found their bug :-) If the application was "surprised", then it wasn't built robust enough. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
