How Things Really Work- Minding One's P's and Q's
Well, as I listen to the closing strains of Estimated Prophet [7/4 reggae, smoothly executed] followed by a rousing New Minglewood Blues (but my day began with Yoko Kanno's Adieu, just to show I retain some balance), I've decided to post some thoughts I've deliberately held back on.
A month or so ago, this thread on NTDEV took place. At the time I began thinking about some of the reasons why my initial posts about KMDF installation issues didn't clearly identify the problem Dan reported. The whole thing does revolve around one Q (question everything) and five P's:
- Persistence- repeating something, becoming annoying if one must, risking subtle and unsubtle forms of retaliation, all to accomplish some goal.
- Persuasion- that soft skill you have to acquire and /or exercise for the persistence to pay off. Convincing someone else you're not an idiot, if you will.
- Patience- because of necessity all of the above take time- and often to an outsider the amount of time it can take seems ridiculous.
- Pragmatism- pick your battles, take the lesser of the evils, realize you can't win them all, try to determine where an effort is best spent. To me, the heart of true engineering.
- Passion- it is going to be the emotional fuel for the engine making all those other p's work.
So, what am I getting at? Well in the post I referenced, I made two "suggestions" about the KMDF coinstaller based upon what I saw:
- When we got any error invoking the update package, we said it was a checked/free build mismatch. But that wasn't true, in this case, and as a a result, a developer wasted his time on an issue that didn't even exist. I said we should provide more accurate information when these things fail.
- That if the files were present, we decided the framework was installed, but in fact it wasn't unless the service entry for the framework runtime was present. I said we should check for both.
What I have never mentioned until now was that both suggestions were shot down, rather vehemently and determinedly, and in no uncertain terms. At first, I tried to turn up the persuasion- unfortunately, I'd also had time to think further, and tried to float the idea that we could even attempt repair when we encountered these situations- that prompted a response from Doron that it had been considered, but there were too many potential side effects. Now my initial reaction is that a 90% solution is better than a 0% solution, and maybe I'll even try to fight that battle someday. But pragmatism intervened- don't fight a two front war. I tried to steer back to the core of that second idea, providing essentially arguments like those I mentioned in the thread, and adding that these issues constituted an added expense for teams adopting KMDF. Going back to my entrepreneurial days, I tried to point out that we could go from having an annoying situation for our customers to one that would delight them, or at least make them happier [having fewer problems is always a good thing].
I still remember Peter's response- that he felt I had phrased things so strongly that he felt I was saying that if you didn't do as I said, you didn't care at all about customers. A little too much passion, probably. But my persuasiveness wasn't going to win the day, so I did the pragmatic thing: I dropped the issue but continued to seek more input on installation issues.
Months go by, and occasionally installation issues are a topic of conversation in meetings. I persist in stating, but in lower key terms, that these two issues seems to be two of the most common threads in installation issues that aren't just plain errors on a developer's part. Some progress occurs (in 1.7, service entries are created by the update process, which closes the door on the issue I first reported here, but if one accepts that there are other ways one can end up without the service existing, that problem remained), but only partial.
Then there are the shakeups- teams are restructured, task assignments change, heck, I even got promoted to a more senior position [in spite of being largely ineffective as a customer advocate, which is one of the essential roles of QA]. Ilias now owns the coinstaller, and is more receptive to the ideas- but I still had to exercise persistence and persuasion in trotting out my discredited notions yet again, and getting him to understand and comprehend what the issue was and why it was a problem.
The end result: both suggestions are adopted in the 1.7 and later coinstallers, but for a better payoff, Ilias has several times told me that the service fix in particular is proving to be one of the most useful improvements (as in it has increasingly turned up as a cause of installation problems with the earlier coinstallers, and we can now resolutely state it got fixed).
Why is it like this?
I believe it is a built-in problem, tied to the underlying psychology of a human computer programmer. Breaking problems into smaller pieces, and getting all the pieces exactly right is a demanding task that inevitably taxes the mental and ideational capacity of the programmer. The developer's persistence and passion are essential in getting things done- the program becomes an extension of themselves and a part of them. Once things are being implemented, resistance to change is natural. There is an inbuilt tendency, in my opinion, to resist outside influences or even to perceive them as personal attacks. Since shipping usually leads to just a brief break, there isn't always an opportunity to flush the buffers, put some distance and regain perspective.
That may be too abstract, but "not invented here" is an easily observed phenomenon that is and always will be in existence, as is denial of bug reports, constant rewriting and refactoring of product code, "reinventing the wheel", resistance to recommendations, the "flipping of the bozo bit" and any of dozens of other obstacles between someone wanting a change in a piece of software or even getting a real problem recognized.
Maybe not the best explanation, to fall back to what I would have said in an earlier day, "It's all part of the job, man- that's just how things really work".
Why not say so earlier?
A few reasons:
- Some of what I've said could be taken quite negatively regarding colleagues past and present. On the one hand, it might help to understand that things aren't as simple as they ought to be. On the other hand, I don't want people who in reality aren't any different from other people in the same roles to be seen as the villains in this drama- they're not, they're good engineers and they're good people. But we're all human and have our rough edges.
- That was an image concern- another thing guiding my earliest posts was information disclosure- I never named the end users [privacy rights]. I don't think I've ever identified the company that produced the faulty software [privacy again, or professional courtesy, see it as you will]. As I've said elsewhere- it could have been our software- that time it wasn't. But yes, if it's ours, and the owner of it doesn't want me to tell you about it, I'm not going to even tell the story. It's a fine line that's kept me from discussing much of what I'd prefer to in this blog [I often find bugs in other products, and sometimes those are the most interesting to talk about]. But disclosing previously unknown bugs raises issues from security to image to perhaps even liability. At any rate, at this point, pragmatism rules- I want to get more paychecks, and if I just blurt out everything, I not only lose this job, but any next one, as well.
So, if that makes me "not credible" as a "source", hey, so be it. Where did I ever indicate I had any desire to fill that role? I talk about what I know and think (or at least think I know and think I think).
Well, I seem to have progressed from trying to explain myself, to arguing with myself, or at least resurrecting phantoms of old arguments and fighting them again. time to go and do something useful. But perhaps this quatrain from Robert Hunter (from Terrapin Station (Lady With a Fan)) makes for an appropriate ending:
The storyteller makes no choice
Soon you will not hear his voice
His job is to shed light
And not to master.
