another (possible) nonsense correlation

I was reading news stories on Reuter's this morning and came across a new study. Researchers have determined that men who work in unchallenging jobs with little control over their future tend to be less active off the job as well.

Now, I don't doubt that there is a relationship between a passive work role and the amount of activity someone engages in off the job. However there are a few quotes from the researchers in the article that raise the specter of a nonsense correlation.

Here's a summary of the findings:

Job passivity didn't influence how active women were outside work. But men who were in passive jobs at all three time points were 16 percent more likely to have low levels of leisure time physical activity than men who had never worked in a passive job.

And here's the conclusions that I think cross the line:

"We need to consider what type of jobs we are creating,"


"upstream interventions that reduce dull, demotivating and unchallenging jobs may be worthy of consideration."

Just my opinion of course, but I think they've got this one backwards. Suggesting that changing the job role will make passive men more active in their leisure time seems to be a bit of a stretch. Suggesting that the job role made the men become couch potatoes is an even bigger one. I wonder if the researchers took into account how active the study participants had been as children or in college before entering the work world. A more logical conclusion might be that passive men are drawn to passive work roles. Or perhaps, passive men are less likely to take the initiative to get out of an unchallenging work role. Looking at it from the opposite direction, it seems unlikely that active men would remain in a job role that gave them no control over their destiny.

Perhaps there is more behind the study, or maybe it's the news story that has created the nonsense correlation. We don't have the information to determine the validity of the research, but that was the point of the last post. News articles tend to add the cause and effect relationship to the published research, leaving the public with little insight into the validity of the research or the announced conclusions.

I'm staying in the context of the study by focusing on the men, but the same would be true of the women I know. I've had a few friends who have chosen more passive roles at work because it gave them more time to focus on family, but if someone makes that choice the 'lack of control' factor is negated.

---

A very lightweight post on a Saturday morning, but it's nice to be posting again at all. I have much admiration for those who returned from Oracle Open World with many very informative posts. I returned with a list of topics I hoped to write about, and a backlog of work that pulled me completely out of that line of thought. But OOW 2009 was a very different sort of conference for me anyway. Most of my conference related activity was partner/business strategy related this time around and if it hadn't been for Oracle Closed World, I wouldn't have gotten any technical content at all.

Fortunately, UKOUG is coming soon and there are always exceptionally good technical sessions in Birmingham.

nonsense correlation

I was doing a little light reading on my Saturday night in my Oxford Dictionary of Statistics by Graham Upton and Ian Cook and came across this definition:


nonsense correlation: A term used to describe a situation where two variables (X and Y, say) are correlated without being causally related to one another. The usual explanation is that they are both related to a third variable, Z. Often the third variable is time. For example, if we compare the price of a detached house in Edinburgh in 1920, 1930, ... with the size of the population of India at those dates, a 'significant' positive correlation will be found, since both variables have increased markedly with time. The first comprehensive study of nonsense correlation was undertaken in 1926 by Yule, who considered the apparent connection between the fall in Church of England marriages and the concurrent increase in life expectancy. See also GOOSEBERRY BUSHES; RUM CONSUMPTION

---

I had no idea there was an actual statistical term for this - one that I could look up in a real statistics dictionary written by a professor at the University of Essex, no less. Or that there might be funded comprehensive studies for such things.

My favorite example of the confusion between correlation and causation is the Pirate Effect, i.e. There are fewer pirates on the oceans. Global average temperatures are increasing. Global warming is therefore caused by lack of pirates.

And what about the studies that suggest lack of dental health is a causal factor in heart disease? Did they consider that Z = the individual's attention to general health maintenance?

And here's a professor who keeps a list of the headlines that suggest causal relationships when the research was correlative to teach his students that correlation != causation.

But what I really want to know is how do I get funding for a nonsense correlation study? I could come up with an endless supply of possibilities.

I think my first study shall be evaluating the increase in the number of colors in the Oracle installation screens with the parallel increase in the number of poorly configured databases. Clearly, multiple colors combined with pictures must affect the installers ability to make appropriate database configuration choices. Perhaps we could isolate the specific colors that cause this issue, remove them from the tool and improve the condition of databases everywhere.

Or maybe not ...

(sorry - I get cranky when I read statistics on Saturday night. Think I'll read about rum consumption next and start a self funded study of nonsense correlation)

mock-ups, prototypes and production builds

(I can't talk about planes going off on tangents but I've moved them all to the end this time. Read them in whatever order works for your brain - or skip 'em. They're not crucial to the post.)

While I didn't get to work on the SR-71 or the F-117, I had the opportunity to work with men who did. One particular man, Walt Paskowietz, became something of a mentor/champion for me and taught me about a whole different (dark) side of manufacturing. He ran the Mock-Up team, aka Production Development, and they worked by an entirely different set of rules than the rest of production. The F-117 was Walt's baby, his pride and joy.* I worked with him on the F-22, the C130J and the never-built P-7 and I consider myself very fortunate to have done so. Much of what I learned from his methods (which occasionally bordered on chaos) transcended the building of planes and live on in the way I view software development.

As you might expect, the process of aircraft assembly is something like a car assembly line, except that planes don't move nearly as often. Instead, the sub assemblies come to the plane. A certain stage is achieved and the aircraft is moved to a new position on the line. The assembly process is intended to crank out plane after plane, each one like the other. But it has to start somewhere and that's where things are a little tricky. The plane has to be designed and engineered. Good engineering should take in account the manufacturing process and optimize the design for producibility. But think about designing a plane for a manufacturing process that doesn't exist yet. Or setting up the manufacturing process for a plane that hasn't been designed, using tools that don't yet exist. (and some of those tools are huge with a 2 year design process of their own) How do you go from paper designs to a production system that is capable of producing a consistent product at consistent intervals? This is where Mock-Up fit into the picture - they were the bridge between engineering and manufacturing. The end goal is always a consistent, reproducible build process but getting there was an experience full of creative solutions.

My first job at Lockheed was in the Industrial Engineering department at Burbank. We built the production schedules based on learning curves which estimated the rate in which you could expect production to ramp up the tools, equipment and knowledge needed for steady state production. Using French curves, algorithms and logarithmic scaled paper, we'd determine an achievable rate that fit within the plane key milestones (generally based around the 1st, 2nd, 7th, 9th and 11th article delivery) which would then create key position dates, which determined when sub assemblies where needed, and so on. Depending on the learning curve selected and the customer requirements, it could take a decade, maybe more, to reach steady state production.

Schedules in the 'Black World' aka secret projects were noticeably more compressed. This was attributed to the atmosphere created by Kelly Johnson in the Skunk Works that lived on in secret projects. The running joke was that if you asked someone in the 'White World' if you could do something, they'd look it up in the procedure book and say 'Nope, the procedure doesn't say that you can do that so you can't.' Ask someone on the Black side, they'd look it up in the procedure book and say 'Well, it doesn't say we can't do it that way....'

The first article of a plane is essentially hand crafted. Procedures are being defined, engineering is still creating new drawings, changes to the design are coming out fast and furious, and a repeatable build process is just a wet dream. But resulting planes are solid products - they still have to fly. They are also the most expensive of all the articles that will be built of that model, which is all the more reason to make sure they won't burst into flames when a radio is turned on.*

Each plane that follows the first article gets a little closer to following the desired process, but it is an accepted truth that no one will ever decide to build another plane in the exact method that was used to build plane number 3 once you've built plane number 4. Until you hit the steady state article, and for the F-22 I'm thinking it was at article 11, the process is streamlined and changeable. You focus on the information that is needed to move forward with the design and you don't worry about things that will not matter for future iterations. Documentation and data required to support that particular plane in the field is crucial of course, but no one is wasting time on making sure there a repeatable build method at this point in time. There are still changes coming from engineering and premature optimization is the root of all evil. This is not just true for programming: it also applies to process optimization. Wasting resources impacts schedules and hinders the ability to deliver on customers milestones, which is life and death in aerospace.

I find myself following Paskowietz's approach in my current project and it's pretty effective. (except that it annoys a particular coworker who's a stickler for her standards. Bet she's never had a clearance.) All in all, the Oracle database side of our project has had fewer bugs, upgrading has been error free and we've laid the groundwork for the future functionality requested by the customer, minimizing the amount of work needed. I also have the much smaller group of highly skilled people for my team as advocated by Kelly Johnston. I believe is a crucial component in a project: a few good people get far more done with less debate. And less whining.

Although Paskowietz has long ago retired and I doubt he ever touches a computer, (he was never terribly fond of them*) I think he'd be pleased to know that his spirit lives on in a very unexpected place - building software mock-ups and prototypes, and following the Black World creed of always looking for a better way of doing things.

---

*I met Walt when my boss in the I.E. department sent me out to Palmdale to gather data on the mock up process. Supposedly this had never been done before. I was 2 months out of college and Paskowietz was skeptical that I could be of any use to him or his team. In his exact words, in a group meeting no less, he loudly asked 'What's she going to do for me? I got kids older than her.' A few days later, I found a die cast F-117 at a toy store, and put it on my new desk in the office next to his. Walt came into my office, picked it up and almost had tears in his eyes, until he turned it over and read 'Made in China'. This was in 1989 and the first photos had just been permitted and published days earlier. I gave it to him - what else could I do? He kept it on his desk for the rest of his career.

*True story. One plane of an unnamed variety made it to the flight line with this minor quality issue: turning out the lights in one side of the plane would cut off both engines on the other side. Seriously. The wiring modules needed just a bit of rework.

*Walt was my favorite boss for another reason. I could take him any computer hardware purchase request and he'd throw up his hands and say 'I'll sign anything. Just don't make me listen to what your going to do with it.' He trusted me and he gave me free reign in my space. Maybe that's what happened to me - having that kind a boss early in my career may have spoiled me just a bit :)

a public apology

I think I've mentioned this somewhere on my blog before, but last year right before I left for the Miracle Oracle Open World conference, I found myself unexpectedly responsible for a new system. Up until that point, I was working in an 'advisory' role for the project - available to answer questions, offer guidance, etc. I had no authority to direct the work, it was just assumed that the other people involved would actually listen.

About two days prior to my flight, I got my first look at the complete package and it was horrifying. Up until that point, I'd been told everything was fine. The contractor, a self-proclaimed DBA and developer, had written code that address the primary function of the system and it was working. Everyone was happy ... until they realized there was a performance problem. No big deal - they'd have me handle it because they'd 'heard that I was good at that kind of thing.' But this problem went all the way to the foundation: the hardware was wrong, the data model was flat and the code was poorly written. Give me any one of those three issues, and there's something that can be done to make a process faster. It might even be possible to improve the performance enough to meet an easy target in the presence of two of them. But all three? We were doomed and now my name was listed next to this mess as the 'architect'.

This meant I was more than a little bit distracted while at the conference. I didn't know what I would do to fix this situation, but I knew I was going to have to do it with the system up and running and supporting customers. Sure, there would be maintenance windows available but that's not much time when you basically need to change the entire application out from under an existing system. To make matters worse, we'd already been looking for new people and I'd seen no one with the qualifications we needed.

I found myself so distracted, I was having trouble even thinking about the presentations I needed to give. The variance presentation would be fine: I had spent a great deal of time over the past several months testing and measuring results so I practically talked about that one in my sleep. But the root cause presentation - suddenly I wasn't happy with it at all and I knew why. This new application was going to present a whole host of reoccurring problems and I felt powerless to stop it. I hadn't built it but I was going to be on the front line for it, and that ticked me off.

In my angry and somewhat retaliatory mood, I envisioned a new version of my presentation: The Root Cause of ALL Evil. I would detail every last thing that was wrong about the server, the application, the methods, the assumptions and the contractor. I would have just one slide - a picture of the person that had developed it. I'd channel Lewis Black and get all my pent up irritation out and I'd feel better. Except I wouldn't really, because pointing at the mistakes wasn't going to change anything and I still had to fix it when I got home.

In the end, I did change the presentation. All that churning about it gave me some ideas for how I could do it better - but I stuck to the original message of applying fixes that will prevent problems from reoccurring, and that was good thing.

But ... at the end of the week, sitting at The Oak Table with several very good friends, I told all the dreadful details, all the problems and all about this contract DBA/developer that I now referred to as 'The Root Cause of ALL Evil'. It made for a pretty good story and better than that, telling the story led to a real solution.

But back to the title of this post ... Why the public apology? You see, after many, many months, I have learned that this particular person was NOT The Root Cause of ALL Evil. Sure, I still have many issues about how things were done, but TRCoAE is a pretty heavy label. Plus I have since learned that the mistakes that were made are not all that uncommon.

In truth, this person did exactly what someone had told him to do. He was given a spreadsheet style data set and an interface document, and he wrote code to perform the work described. And the database did perform the function. Very, very, very, very slowly, but it did it.

In hindsight, the people responsible for him got exactly what they asked for: they had a database on a big, shiny, expensive machine that performed one function. Ok ... one function and two minor data retrievals, but basically ONE FUNCTION. Months and months of work, lots of money and effort, all to be able to perform one function at the speed of molasses in Iceland.

And the real kicker is that the source data is extremely valuable. There is data that is critical to the customer and very useful, as in core business, money making useful. There was so much more that could be done with it, if only someone had looked at the data for what it was and remembered one simple, basic truth:

Databases exist for the protection and presentation of data

If you don't take the time to recognize the potential within the data, functionality will remain limited and future development will be painful. Most DBAs know that our primary responsibility is the protection of the data, and we associate protecting the data with backups and security. But if you don't think about the value of the data in your trust, you can't optimize the usage of information, and that is part of the job too. In our case, some of those neglected data values were the clues that would have resulted in the database performing it's one function in a reasonable amount of time. Instead, those columns did nothing except take up space and slow the data retrieval down. This wasn't apparent until the details of the data were documented and recorded in a real data model. Not the object model, not an interface document, a good old fashioned data centric view of the data. Most importantly, those ignored data points were the keys to what the customer would need from the system next. Understanding what those values represented and storing them in a third normal form allowed us to respond quickly to requests for the next phases of development.

The data model didn't exist until two months after I returned from Denmark. Once done, it required a great deal of work to transition from the old to the new, but the database is a much better product because it happened. Ten months later, it now performs many, complex functions and it performs them much faster, even though it's still stuck on the old hardware. It also performs the original function 40 times faster.

So I hereby apologize most sincerely for having referred to the former DBA/Developer as the 'The Root Cause of ALL Evil' when he was not solely responsible for the original evil. I'm sorry I imagined the presentation that I never gave and I'm sorry about all those other things I said (even though they were true). To make amends, his name from this point forward shall be 'The Propagator of Small Evils'. I don't know exactly who or what the TRCoAE label belongs to in this particular case, but that's not important anymore. We're focused on the solution and there's more work coming ...