Pages

Showing posts with label FUD. Show all posts
Showing posts with label FUD. Show all posts

Thursday, November 1, 2012

A Tale of Two Realities


I have just begun a new job. No hiatus between this new one and the old. One day I am in hell, the next in paradise.

The one I left was as a software manager in a large organization, and the current one is as a software lead in a very small organization.

Other objective differences: the previous job was bureaucratic, there were many processes and constraints and a network of communication and decision paths, and the systems my team built had to reflect the complex interrelated and often historically constrained requirements.

The current one is technical, working within a small team and with very precise mostly self-defined scientific requirements, adjusted to meet specific customer requests. The software has to run precision equipment to capture and calculate results within extremely tight tolerances, both in time and numerical accuracy. The only measure of quality is repeatable precision. The culture is one of technology and science.

In the new job, I report to people who have the same engineering training as I do, who have more experience in the R&D business than I do, who I can ask questions of without risk of offending or destabilizing them emotionally. Peers and superiors in all senses.

In my previous job, I reported to people who asked me to explain what I did "in simple terms" and who liked to hear themselves talk so that they could pretend to make sense of their lumbering thoughts in public forums, often referred to as "meetings" but which felt like beatings. Dissent could be career limiting.

The analogy I would like to give to dispel any conclusion that I may be a pretentious ass is as follows:

Suppose you are a medical practitioner, a physician, and you see patients in a clinical context. You have to diagnose and prescribe treatment as part of your day to day routine.

Also, suppose that you are "managed" by someone who had not undergone the same level of training as you, say a registered nurse, who knew the lingo, understood the context, but did not feel confident enough to make life or death decisions affecting patient health, but felt competent enough or was somehow appointed to tell you, the physician, how to run your practice.

For example, "please use language that is easier to understand in your charts". Or  "make sure your handwriting is legible for the pharmacist", or " you have not seen your quota of patients today, why did you spend 6 minutes more than average with Mrs. Smith today?".

Could you practice under such circumstances? How long would you last?

I lasted 5 years in the analogous IT context. My manager was a technologist, previously a school teacher who joined th IT boom of the nineties and hung on. She did a bit of COBOL programming, hated it and went into management because she could talk better than she could listen or understand.

She is proud to claim that she does not understand the need for system architecture versus program design, her eyes glaze over when there is talk of latency, language choice, servers, data flow analysis, code profiling, and factoring and she had no patience for options analysis or proof-of-concepts. She will not deign to read code. She has trouble with email client software and spreadsheets.

She wants simple, clear explanations and plans, and wants to set deadlines before beginning design, because iterative work can only lead to grief. She always used waterfall approaches in COBOL, and they worked fine for her.

Her weakness and fear prevent her from adding value, from making decisions. She was a pass-through for her manager's decisions to me and my peers. No value added, but lots of aggravation and delay. Never understood or wanted the concept of situational management, which is probably the most effective way of managing people, so effective that there have been lawsuits about who has a right to claim authorship and teach it. She is a scared rabbit, hanging on until she can retire and cash in.

Others in that environment have said that we, the technical folk who did the work, should not "speak Neanderthal" when in the presence of senior executives, by which it was meant that we should use non-IT terms of less than 3 syllables. The executives in question were the CIO and her direct reports.

But all this is now in my past, one-day-old stuff. I am now in another world, where the conversations around me centre on measurement tolerances, ADC resolutions, real-time interrupt-driven code, clock speed and sampling rates, hierarchical state machine approaches, language selection and compiler efficiencies. I have scope probes and micro-controllers on benches beside me, no fuzzy walled grey cubicle partitions in sight, and a project to deliver with people I can talk to who want me to talk dirty.

I am in heaven.

Friday, October 5, 2012

Another rant about software



Software does not really rot, despite what developers experience every day.

What decays is its environment.

Software embodies perfectly adapted machines that cease to function as everything around them evolves. Software has no friction to wear it out. The claimed obsolescence occurs because it gets old compared to the world around it. At least that is the hype. Clients are missing out on upgrades, security fixes, whatever. The Internet helps of course because it is a true wilderness with predation.

The smart boys in the IT marketing departments of big companies learned this probably by accident and have been helping the phenomenon along ever since.

This is the upgrade cycle.

The lucrative business model is based on what I think is a partly artificial problem, or at least one that has been blown out of proportion.

Here is a fantasy based on a moral, ethical and unrealistic world:

A program is written to meet a requirement, is tested, goes through a few iterations with the user community and becomes stable and useful and productive and everyone is happy for a long time.
The underlying hardware also gets faster and better but remains consistent with the older platforms so that the software can continue to run, or be upgraded in an incremental way, but stays in support essentially as long as nothing fundamentally better comes along.

This is not impossible, Windows and IBM both provided this kind of upgrade path for their OS's and systems  for a long time, but then realized that there was much more money to be made by setting deadlines on support so as to convince client IT managers that their stuff may break and cost too much to fix if they did not pay protection upgrade.

FUD is easy when knowledge and complexity do not keep up with each other, and a company certainly can create and control complexity, which has the added bonus of thwarting compatibility, integration and competition. IT companies that have survived have defied the inexorable race to zero cost of most consumer technology, especially something as perfectly light, reproducible and useful as software, by bucking all the good practices of design while giving them marketing lip service. HP, and other engineering companies, like DEC may have misunderstood this twisted logic. Sun certainly did.

Open source is a defense and a mitigation to this pathology and has the potential  to reduce the crazy costs associated with IT change by distributing the cycle of maintenance it across IT shops, using common knowledge. It is an extension of the Unix ideals of clarity and modularity and community. Heresy of course. Communism some have called it.

So we continue to have big companies and governments paying huge sums for essentially very little, a sort of insurance. Let's call it that then, software insurance. That is heresy too, especially if you read the disclaimers that are standard with all commercial software. No guarantees.

Any suggestions on how to shine some light here?