The Monolith Message

A thoughtful, and Fair and Balanced, view.

But I'm afraid that the Newsweek story in which it is being assaulted for telling the truth is germane here.

We programmers desparately need to know and communicate a set of truths about a set of constructed entities that most people don't know about or care about. However, we are embedded rather deep in organizations which have in the course of the 20th century (under both Communism and the free market) learned to use the worst in people including FUD (fear, uncertainty and doubt).

Therefore Microsoft has to reassure the MIS manager, who knows he is not up to his job that they know the answer. At the same time, Microsoft STILL quietly eliminates things you need such as serial and parallel I/O as "unimportant".

Ultimately it's a moral corruption. I too played the certification game. I had to struggle for VB certification although when I took the test at the independent firm BrainBench I had the top score in Chicago, because I had not mastered the Microsoft Way. And I noticed the omnipresence of corruption in the Microsoft certification arena when I took additional certificates: "instructors" specialized in telling us how to game the test, and the classes had an overall atmosphere completely unlike that of a college classroom and far more like a military barracks, or whorehouse.

At the same time, I was struck at the 2001 Authors Event by the dedication and professionalism of Microsoft developers, which had been reinforced by .Net's overall spirit of openness and transparency.

Unlike one guy in the class (who loudly informed me that George Bush was a great President, that he was a great programmer, but that programming was on the way out all the same), most of the developers and authors were real pros...who like my old coworkers at IBM, and unlike Sun or Linux types, had had the misfortune to attend state schools rather than the Ivy League, and who (in the case of Dave Cutler, the chief architect of NT) had survived rough childhoods.

Microsoft, like Tom Watson's old IBM, had given their lives structure, decency and professionalism and for this reason they were loyal to Gates and excited by .Net.

For them, Microsoft was not just one option in a range of choices, because a Microsoft employee cannot just get an equivalent job at Google. He's viewed as significantly dumber, despite the fact that (as Dave Hansen of Princeton's compsci dept told me) to use an inferior platform is to have in most cases to be smarter and able to build workarounds. He's viewed (in that Star Wars mythos which is also a tool of control) as being from the Dark side of the Force.

Therefore Microsoft employees will be very obedient to Marketing.

And when today's Mickey Marketeers mouth today's computing platitudes, such as "open platforms", they simply do not realize that you cannot have a proprietary interest in a REAL open platform. No, you have to get the mere coders to CHANGE the open platform so that the customer continues to rely on you.

But note that the MIS manager is still free to reduce his dependence on the vendor to the extent that he acknowledges his programmers' skill or allows them to become higher skilled. I show in my book that you can process business rules without overcommit to a "business rules" vendor as long as you are willing to let your programmers write a parser and an interpreter.

But for many MIS managers, this is no solution at all. Recall that we're still embed in a bureaucratic machine that runs not only on fear, uncertainty and doubt but also on the seven deadly sins.

As management guru Peter Drucker has pointed out, there is a basic contradiction in this machine as it exists today (its Communist variety being dead except in China). It proclaims, as a corporation, the virtues of the free market as a decision procedure for sorting out effective versus ineffective performance.

But employees within a corporation, in their relations with each other and even to customers, are NOT in a free market. They can't compete with each other without destroying the corporation's ability to function, and without due reward they instead have to work together and in many cases (especially at the lower rungs) they have to "grin and bear" treatment that the market would not dish out...as in the case where the programmer's extra hours, skill and dedication are unrewarded.

MIS success, we've long been taught to believe, is unrelated to skilled programming although a complete *naif* might believe otherwise, and in my own direct experience, it is indeed the ace programmers who later on became millionaires.

The necessary *mythos* (in the sense of stories, we tell round de campfire, to reconcile ourselves to life-which-sucks) is that there is a mysterious firewall between ace programming and MIS insight, a sort of "big picture" which ace programming obscures.

But, in fact, there seemed to Dijkstra (after honest investigation around the time of the 1968 NATO conference on software engineering) a near-vacuum outside the space of ace programming as long as you include formal systems alongside ace programming.

Upon investigation, Dijkstra found this to be a twittering world, an Alice in Wonderland world, where words like "the User" floated unmoored to referents above the heads of conference attendees.

One would compare it, Dijkstra would compare it, to the world of the philosophers as re-presented in the popular mind but for the fact that one, and Dijkstra, has read Kant and realized the difference between the irresponsible claims of AI and what Kant was dealing with at the level of a philosophical psychology which had, among other things, to "bootstrap" like an operating system, and to make space, like an OS, for itself.

I conclude that ace programming is everything and I conclude that it takes a humanity which owing to the fact that modern organizations have learned as systems to run on fear, uncertainty, doubt and the seven deadly sins is running dry: organizations don't run exclusively on FUD and the Seven Deadlies.

Indeed, ace programming may be exactly what Derrida claims it is:

"If the theory of cybernetics is by itself to oust all metaphysical concepts-including the concepts of the soul, of life, of value, of choice, of memory-which until recently served to separate the machine from man, it must preserve the concepts of writing, trace or grapheme, until its own historico-metaphysical character is also exposed. Even before being human (with all the distinctive characteristics that have always been applied to man and the entire system of significations that they imply) or nonhuman, the written mark-or the grapheme-would thus name the element."

"An element without simplicity."

"An element, whether it is understood as the medium or the irreducible atom, of the arche-synthesis in general, that is to say the origin of MEANING in general."

After reading Daniel's initial post, I wanted to respond how refreshing it was to hear someone echo what I suspected about certifications. I can't say how many classes I've endured where understanding took second place to test preparation. When I see someone print personalized business cards with all their certification logos proudly displayed, I get the sense that it fufills the same purpose as an expensive sports car...as overcompensation for something.

Having made that inflamatory remark, let me quickly add that something has to be said for the initiative and spirit of a person willing to pursue certification...which is to be commended above the more common programmer who never picks up a technical book or reads a professional article on his own time. Also...if the market demands certifications, you certainly can't blame the person who is willing to meet that demand.

Speaking of training and certification, I am appalled at a sense of entitlement that is pervasive in the profession: If you don't send me to a 6-week training track at a plush location so I can be mindlessly read to and spoon-fed, then forget it! Don't expect me to stay current with technology. That doesn't mean the organization doesn't have a responsibility to the programmer to provide the tools-and-training straw needed to make the technology bricks, but the programmer also shouldn't act as if all they have to do is show up for work. And some do.

Now...about the Ace Programmer. Perhaps I am too practically-minded and am reading too much into this. We need to be careful to consider the full picture of what an "ace programmer" means. (Mike Gunderloy has a good book: Coder to Developer: Tools and Strategies for Delivering Your Software.) On the surface, it sounds like a hotshot coder. If that's all we're talking about, clearly a hotshot coder can work some wonderful wizardry, but never follow through on the myriad of details required to complete and implement a project. I realize in a large organization there may be a whole staff of people to take care of all that, but someone consulting or working in an environment where a single developer takes responsibility for most aspects of a project, coding is just one part of the puzzle.

I remember a former manager I had describing one of my coworkers (who was a talented coder) by saying, "He needs one of those jobs where he can play with things all day and then toss them in the COOL or NOT COOL box." He was notorious for writing something, deciding he could do better, and start all over, again and again, so the schedule was sausage. Granted, I think most developers would like to do that...keep striving for perfection...but at some point we have to deliver what we're being paid to deliver. That's execution.

One last comment relating to Mr. Nilges post: competition. Many developers have learned to despise performance evaluations, and some consider them devisive, for many of the reasons mentioned: encouraging individual competition when it should be all about the team. Done right; however, performance evaluations are personal challenges, not challenges against coworkers. While I suspect that most of the bloggers and readers here are so self-motivated and have such a high work ethic that they would be high achievers with or without performance goals, that simply isn't true for all folks in the profession. Do you really want to work alongside dead weight, making you carry more than your share of the load and have your manager do nothing about it? Without objective measures, it is much more difficult for the manager to "prove" poor performance and do anything about it.

I do agree that pitting one developer against another should not be done. However, I think we do ourselves and the profession a disservice if we propagate the victim mentality. While programmers should be treated respectfully and not subjected to unfair work practices (including ridiculous expectations of overtime), we should reserve the "Us against The Man" argument for when it is truly justified, or it will become as tiring as the VB v/s C# debate.