The Good, Old Times
or, More Cogs Decrease Efficiency
Just when I thought I fresh ran out of rants, all is great and why the hell did I start a blog, I brushed again against the ugly spectre of bureaucracy. A few years ago, working on a new OOB XP technology, my attributions included a constant dialogue with IHVs (mainly driver developers). We were a bit understaffed on the PM side, the devs were loaned to MCE to hold their devs by hand through the most difficult process of writing working software and so we, the test, were wearing the polymorphic hat we sometimes do: test/dev/PM. (And doing none really well.) Driver devs had questions about the spec, and we'd get them the clarifications (as well as updating the spec with more examples). Then they would need test tools, and we'd give them a bucketful of test cases, along with the reference output. Lastly, we'd help them with debugging/unpublished error codes and code up small fixes that our devs would put in the product. It really was great - fast paced development of both our tests and their drivers, and you could see the quality of the overall experience going up every week. What more could you, as a professional, expect other than the instant gratification of "it's fixed/better"?
Well, too effin bad, 'cause those days are gone and they ain't coming back. We now have almost as many PMs as we have devs, pretty fresh in MS years, high on talk and full of process. To be fair, the process part is not of their conception, and it's by far the most damaging aspect of this "new" life. Need to speak with an IHV? Sure, talk to the PM presenting the problem until they understand it, send him/her an email summarizing the issue, the expected outcome, ping them again in two days and try to maintain composure. Then that email gets to the addressee (hopefully) or to their counterpart in the IHV company (realistically) and, in due time, I'll get back a response. Need a quick and dirty update to the spec being published? Likewise, we have to go through LCA, lest our treasure map is leaked outside and we end up begging for food in high, affluent foot-traffic areas. And you just know those helpful LCA people, as well as your PM, have assigned exactly the same priority to this task as you and your IHV counterpart did. (Speaking of LCA, I'm not accusing them of not working hard during their regular program, but did you ever happen to be in one of those buildings at 4pm? The elevators burst at the seams and they will run you over enroute to the nearest exit. Be warned. I think "long hours" in that building means working till 4:05pm. The offices are deserted and you just know that if you see one of them in during the weekend, they're up to no good. Just kidding.)
Try to circumvent this pointless detour and watch hell emerging; after all, what do you know, it's not as if you participate in all the high level meetings that the PMs do and you lack the clear overview to see that this tiny, 30 min technical issue must follow the rigorous chain of communicators in order to be properly solved, without presenting a risk to the company. That's how it is to be done, so get your issues back in line, Bucky.
I postulate that the number of bugs is the same in any generation of drivers/components. People don't learn from their more obscure mistakes, and when they do, the new version adds complications that compensate, with bugs, for the learned lessons. It's just that, what took in SP2 2 days to identify, solve and fix now takes a week, at best. To that, I add the subjective cost of losing the giddiness stemmed from seeing issues actively resolved. Why? Who decided it'd be a great idea to channel technical issues through non-technical people? Or that specs need to go through a 1 week of LCA brewing before going out to partners already under NDA? What massive losses will the company incur if a simpleton of a test app goes out to its intended audience directly from its source? What, do we risk not being able to file yet another pathetic patent on grounds of disclosure?
We need to step back and look at what we need to accomplish, and not what is the "safest" way to do it. If we'd deliver the software faster, we could make further progress and achieve more over the same time, versus locking up all the doors and making sure nobody is peeking over our shoulders at the laughable contraption we've put together.
Want an example from an extremely fast paced (figuratively and literally) field of economical activity? In Formula 1, there are no patents. The time and expense required to obtain a patent is time and funds taken away from development and/or improving on the last race. The patent would essentially give your competition the blue-prints to your clever finding, and the meager royalties you collect from such a small audience are absolutely nothing in contrast with the possibility of them bettering your form by adding your finding to theirs. And that really is high tech. Who cares about apeing a silly API to dethrone the mighty Windows?
But until the good old days return (or until I find another company that believes in agile development), I'll go back to quarreling with my PM about each one of us not including the other in important discussions.
3 comments:
One subtle problem with your forumula 1 analogy:
Other race teams don't patent generic concepts, sit on them (biding their time) for years while you build a shipping product around those concepts, and then sue for infrigement after you after you've shipped millions of copies of that product.
The involvement of LCA is a direct result of losing TWO anti-trust lawsuits in our two largest markets. Legal has to give EVERYTHING the once over to ensure that nothing done or seen by external customers violates court orders.
This does, indeed, slow things down like crazy. But that's the price of success I suppose.
In the group I work in, I'm fortunate enough to not have that kind of overhead. But, nothing being perfect, the group dynamic has its own set of problems. Like a manager who doesn't manage, leads always fighting with each other, and only 3 team members (including myself [well, most of the time]) willing to take ownership of anything... *sigh*
One subtle problem with your forumula 1 analogy:
Other race teams don't patent generic concepts, sit on them (biding their time) for years while you build a shipping product around those concepts, and then sue for infrigement after you after you've shipped millions of copies of that product.
You are correct, no doubt and I agree there are situations where LCA has a much better view of the ensemble than I have down in my rabbit hole.
However, it seems that most times we're checking our common sense with the receptionist when we come to work. Not everything should go through LCA, and not everyone is after our bank account. (Uhh, am I showing signs of naïveté here?) Most external partners have their own headaches, milestones and fixes left to do - they simply want a timely update/answer from those that create the technology they use. (We, MS, are not trying to take the electric company to the cleaners, we simply need their service (electricity) pure and constant.
The lawsuits we lost not because LCA didn't scrutinize every email, but because we have top mgmt going to off-sites in order to debate how are we going to screw our competition. That's fine, everybody does it (even in F1, if you're following, you may remember the infamous widening Michelins of 2 years ago, BAR's miraculous gas reservoir of last year etc), we've simply been caught. Maybe LCA could have covered it up, but the intention was there, clear and present.
You have a manager and leads for only 3 ICs? :-)
Speaking of non-managing managers, you may find this little story foreboding of darker times. In an earlier life in this group, our PUM was found sleeping at the helm, eyes taken off the ball long before. The group went well, but concerned managers voiced their displeasure at the PUM's blatant slumber. What happened was predictable - the group has been hacked in three, giving the PUM a piece to play on with. The other 2 were thrown to some of his peer fearless leader-wannabes, who complemented their laggard hordes with one of the finer and better clicking groups in Windows. Then, they too gained the much admired PUM epaulettes and started using the inherited talent for their own "to do" list. Disgruntled employees left in worrisome numbers, including one very high level defection. The dev manager of 10+ years, (who also oversaw test, which means he was in line for a PUM position) had to leave and settle for the first acceptable position he found elsewhere in Windows. Why? Because, prior to the hacking part, he was a vocal critic of the (lack of) progress of the parallel group which became the "acquiring" party. This all happened (and still does) somewhere alongside SR520.
Romans said it best, divide et impera.
I presume you are forgetting the recent incident where some employee sent out some sort of contract proposal (bypassing LCA) with terms violating the anti-trust settlement...
While I agree with you in spirit, the number of people out there looking for a quick buck (on the order of hundreds of millions) on a mindless error on our part costs the company far more than a longer development cycle. At least, that's the theory ... I'm not a bean-counter. :)
Post a Comment