My job is so secret

So, imagine that you have a development cycle where a two line can take six months to make it into production, assuming diligent developers and savy management. By the time the fix gets into place, everyone involved has forgotten what needed fixing. Devlopers have been working in a devlopment environment, where the fix has been around for ages. Testers have to be reminded that it isn't a new bug, and, by the way, the fix is in the pipeline. End users have forgotten that they needed it fixed.

My job is so secret that not even i know what i'm doing.

Pirate talk

It was Talk Like A Pirate Day today. Arrg, mateys, and you can lay to that!

Dark Energy

I was at the store the other day, and noticed that they now sell disk drives that can hold a terabyte of data. Well, of course they hold more data. The whole Universe is expanding!

Queues

The third Rule of Acquisition clearly states, "Never pay more for an Acquisition than you have to", ST:DS9, The Maquis, Part II.

So, large American, Car companies want to save money while conducting their business. Business is complex, and computers can help keep track of things, etc., so they use them. Over time, the Information Technology department becomes rather large and complicated in and of itself, so they look for ways to save money there, too. All this is natural.

One of the issues with computers is that they themselves are rather complex, and require considerable training to use, program and maintain. Good database administrators, programmers, systems administrators, etc., are highly skilled people and therefore are expensive. In general, companies are drawn to organize these people by skill, putting like people into like groups. For example, there's a systems administration group, or a database administration group. A programmer, attempting to write or maintain some application needs to communicate with such a group to make use of such expertise, but also to get access to relevant systems to make needed changes.

As the organization grows, these groups change from technology enablers, to technology gate keepers. They become responsible for systems security, enforcing corporate policies, and so on. To reduce costs, these groups are reduced in size until each person is fully loaded with work. The result is that when a programmer needs to make changes in a system, their request enters a queue, and weeks go by before any action is taken. When mistakes are made, more weeks go by before corrective action is taken. This can be true even for the most trivial of changes, where the programmer had appropriate expertise to make changes, but did not have authority.

And, an honest analysis shows that the body count isn't reduced. It turns out that both the requesting programmers, and the servicing administrators are required to fill out paperwork, perform extra unneeded steps, and real productivity is minimal. The customer has to wait longer, and everyone ends up with more overhead than actual productive work. Far from ensuring quality, mediocrity is enforced. This is not the fault of the individuals.

This tendency to crowd people together by type has long been recognized in industry. The resulting stovepipes generate communications difficulties and pointless overhead. It is not unusual for the overhead to exceed an average of twenty or thirty times the amount of real work, as measured in hours. Worse, much of the overhead is geared to measure progress. Data from these logs are used by managers to show that the system is becoming more efficient, even as latencies grow ever longer. These statistics are, of course, wrong, not just misleading.

Clearly, it's no fun to work in an environment that is mired in bureaucracy. But how does one fix the system? The key is to point out just how terrible the system has become for the end customer. Further, one needs to point out how the head count has grown while productivity has decreased. The evidence clearly shows that small integrated teams, with all the expertise in a tighter nit group are considerably more effective. One needs systems administration, database administration, developers, business liaisons all in one place. If single individuals have competence in more than one area, they are that much more effective. That suggests that small groups control their hardware, systems software, and applications software. Small groups should develop their own standards for backup, source control, coding style and database naming conventions, application deployment, and so on.

Sure, the larger company should have policies, but the development group should be able to treat these as suggestions. If they decide to deviate from company policy, they should be able to do so without a waiver of any kind. Then, the policies will reflect business needs, rather than reflect blind guesses.

What about external requirements, like SOX? These are business requirements, like any other. Let the development group handle them. If they require reporting, then reports become policy or part of the automation, as makes sense. The key is that things should make sense.

Thumb loading

I talked about thumb drives a while back. And, i'm at it again, downloading huge amounts of stuff and tossing it onto thumb drives.

Not only does it take awhile to fill a 2 GB kingston, but it also sends the load average through the roof. It's typical to take an otherwise unloaded system from a load of zero to a load of 5. And, it stays there for the duration. What's with that? The CPU is 99.7% idle. So, it's not like parallel ports where the CPU needs to do something every few bytes transfered. What are the other 4 tasks waiting to run? And despite the low CPU load, responsiveness during copies to the USB thumb devices is sluggish and jumpy.

This is under Linux.

Anyone have any idea why? Is it different under Windows? Mac? OS/X?

Canoe trip

It's late in the season, but the canoe trip experience has finally taken place. We're not talking about a shakeout run to make sure everything works. We're also not talking about days on the water, or some other big deal. But, a trip with passengers. It's taken nearly a month to get it together.

Since we're, at heart, city folk, the trip takes place in a city. The Huron River runs through Ann Arbor, MI. Since it was otherwise quiet and peaceful, we brought along a couple ten year olds to provide continuous noise. The ducks were unable to compete with this noise, and so, stayed quiet themselves.

Gorgeous day. This is, unfortunately, the best picture taken all day. It had to be modified to look even this good. Mallards, i think.

Internal Discipline

When we last left our hero the large organization was overrun by high latency task groups that were effectively obstacles to progress.

Another feature of large organizations, and by large i mean organizations with more than one person, is externally applied discipline. The problem to be solved is How does one motivate the employee to produce good work?. For the software developer, it's the wrong question.

One of the common management approaches to this problem is characterized by the carrot and stick paradigm. The idea was that to get a horse to pull the buggy, one had a carrot and a stick. The carrot was a reward for good behavior. The stick was punishment for bad behavior. Now, modern management has no experience with horses, or they'd know that the stick was not for punishment. The carrot was suspended by a string from the stick. But that isn't the modern interpretation.

Any parent will note that a promised reward is a much better motivator than punishment for children. In fact, punishment doesn't work very well, and not at all over the long haul.

But managers generally don't think that they have anything to offer an employee (which is false). They also don't think that they can get away with much in the way of punishment (which is also false). So, despite the above very common and widely talked about concept, it often plays almost no actual role in obtaining quality work.

What managers really know how to do is the paper trail. To get the developer to use source control, have a manager sign off that code is in the system. To get the developer to adhere to database standards, have a database administrator approve any database usage or changes. To get the developer to add user level help pages, have someone who only handles installing help pages on the system review the text and install it. To make sure that the customer is satisfied, have the customer sign off on the project before it is placed on the server. Each of these processes adds delays to the project, but do they ensure quality?

No. It turns out that the database administrator doesn't know anything about the application code. So even a simple query that uses only indexed keys might in fact be issued to the database millions of times. Only the developer would know that. The help text manager doesn't really know the application, and can easily miss omissions and outright errors in the text. Worse, help text usually concentrates on the details of how a function works, but never gives the end user any idea why one might want to use the function. That takes context. The customer signs off on the application, but does so at application launch. It may be a month before the customer is familiar enough with the product to be able to really evaluate it.

External discipline is inefficient and ineffective. The solution is to empower the developer to do the right thing. First, the developer should be aware of the kinds of quality that the customer wants. It may be consistency, repeatability, discoverability, ease of use, etc. Second, for those quality issues that only a developer could understand, review should be made by another developer. Code reviews have the side benefit of disseminating knowledge. Even the most senior developers learn something. Involve the database administrators early in the process, not late. The DBA should suggest good ways to do things up front, not stall a project nearing completion. To do that, the developer and the DBA need to work together. For best possible speed, they should be a single person. The customer should be able to give feedback at any time, not just before the launch.

Empowerment

Large organizations have a problem. It's a hard problem to solve. That is, how do you organize the division of labor when you have a large number of people? It's not a new problem. Sun Tzu's The Art of War covers it. The general was asked, "How large an army can you command?". His answer was "the larger the better". Old problem but solved.

People tend to learn new skills fairly slowly, so it is commonly thought that no one knows how to do everything. In any case, the large organization tends to discover, often by luck, that a person knows how to do some specific task, and then uses them for that one task exclusively. As the organization gets larger, groups of people form to perform specific tasks, and the organization tends to treat these the same as individuals, performing one task forever.

The large organization then takes these task groups and establishes processes that let the groups get things done together. When there is a complaint that the process isn't written down, it tends to get written, and becomes less flexible. When problems of quality arise, and let's face it, humans make mistakes, the reaction is to manage quality by requiring that a high level manager signs off on actions. But these people don't know how to do everything, so they don't know how to judge quality. They become a source of latency for projects, with no added value. Management thinks in terms of paper trails, and requires paper documents for everything.

The ebb and flow of work to do means that some task groups feel overloaded from time to time. They set up often elaborate queues where tasks are submitted, and 'customers' are given a minimum wait to get things done. For example, a database administration group may require a minimum of a week for any task - even if the task requires no analysis, no research, no diagnosis, just a simple command sent to the software. Often, these groups require that there is no face to face or even phone contact, and miscommunications are frequent, requiring resubmission of the task, with attendant latency.

So, let's say you're a developer, and the project is to project a web based application. Checking your source into the source tree requires sign off from the source code control group. Placing the application on the server requires sign off from the hardware and web server software groups. The database administrators need to sign off on the way the database is used, even if there are no new tables. The help text for your application is managed by yet another group. The application took a week to write, but takes an additional six weeks to deploy, if you're lucky.

How can this be fixed? Instead of attempting to manage quality by instituting sign offs by management enforced by restricted access to systems, the trend should be to manage quality by automated paper trails, with automated back-out systems for failure mitigation. The emphasis is on automation to reduce latency. Empower the developer to get things done by giving them the tools needed to get the entire job done. Trust that the developer will attempt to do the right thing, but don't be afraid of failure. Fear of failure causes paralysis.

There are a complicated set of issues. For brevity, this is just one of them.

Troll

Kirk vs Janeway

COBOL vs Java

Miata vs Jeep

Spaceship One vs Shuttle

Meede vs Orion

Discuss

Today is National Relaxation Day

End of joke.

Tom Swift

On the way home from Bible Camp, my ten year old son and i listened to a 4 hour book downloaded from Librivox. Tom Swift and the Visitor From Planet X, written by Victor Appleton II. It went over well. There was a cliff hanger every chapter, except the last. This could be serialized on radio easily. 20 Chapters, so they must have only been ten or fifteen minutes each. That's short enough for nearly any attention span.

The reader, Mark Nelson is very good. No memorable mistakes. Maybe there aren't any. He does it with a 1950's style, with gusto, WoWee! But should you want to read it yourself, the full text is available on Gutenberg.

It's science fiction, with an action/adventure feel, but i had difficulty placing just when it might have been written. It has a 1950's style, but seemed to have references to more modern inventions. Fortunately, one doesn't have to guess, since Wikipedia knows it was written in 1961. And, it knows who Victor Appleton II is, and what a busy guy Tom really is. He had something like a hundred such adventures. And those are just the ones that have been written up so far.

The story has it all. Hot sex - well - there was a quick kiss on the cheek. I wasn't paying attention. It might have been Tom's sister. And, it has violence. Well, there was an earthquake, and some property damage. Space aliens, including the Visitor from Planet X. I was hoping the space alien would have something to teach us about global warming or world peace. Not a word. The one named villain turned out to be a spy working for the good guys. In retrospect, it's hard to believe there were 19 cliff hangers.

Canoe

So, the canoe and bike rack was last set up on the previous car. It's a fairly fancy Yakima setup. There are these adapters, and the rack has been on four different cars now. But it had never been on the Saturn, so it was an hour getting it there. There probably is a clip designed for the Saturn, but i was able to make an existing set work. At least it's secure. Well, i didn't do the acid test - drive on the highway. I would have, but the on ramp to i75 south was closed. The primary test wasn't the drive, it was the canoe.

So, the canoe works. You see, there are paddles, and life jackets. A water bottle. Some binoculars. Can't go anywhere without binoculars. And... and that's it. So really, most of the test was getting the canoe onto a car.

With the rack on the car, the next step is to find the key, and unlock the lock which holds the chain. This is easy, since the lock was unlocked just a couple months ago. Except, that the key can't be found anywhere. After a half hour fruitless search, it is decided that one link of the chain can be cut, freeing the lock, and by the way, the canoe. This takes an hour. It's a very good chain (now slightly shorter).

I'd have never designed a canoe rack that has the canoe upright. I mean, when it rains, it fills with water, right? If too much water gets in there, then what do you do? The car could be overloaded, or the canoe might be too heavy to remove. Bail it? So far, though, it just hasn't been a problem. And for some reason, i've never thought to load up the canoe with everything in sight. One can put alot of stuff into a 17 foot canoe.

One nice thing about the rack is that in addition to the canoe, two bicycles can go up there. And, they go up without rubbing against anything. Nothing worse than a bike rack that damages the bikes. Or the car.

The test run for the canoe involves putting it into the water, and paddling around for a couple hours. Elizabeth Park has a nice parking lot, a little channel that goes out to the Detroit River. From there, one gets to deal with wind and waves. My trip took me to the bridge, which swung open to let a large boat through - always exciting.

And, i made it back alive. Mostly. Nothing damaged that can't be cured
with a little wine and a long bath in the hot tub.

Harry Potter Book 7 - no spoilers

I've now read half of the book. The non-spoiler review so far: i like it.
There's not much to say beyond that without giving something away.
So, I'll stop.

Please don't post your spoiler here.
For example, don't flip to the last page and tell me the last word.
Even if that word turns out to be "the" (which is unlikely. I'm not sure
i could construct a sentence that ends with the word "the").

I'm not reading the web until i've finished the book. It could be
a few days. Unfortunately, i have to eat and sleep, too.

iPhone Diet

The new buzz is that one of the women at work got a new iPhone over the weekend. She's been goofing with it, and showing it off, pretty much as one might expect. In fact, lunch got moved back quite a bit. Not just for her, but for many of us.

I'm calling it the iPhone Diet. It can affect those around you, too. And, they don't get to decide if they want to participate. I didn't get to decide, and i don't even want a phone. My angle is more what user interfaces could be adopted for the Palm Pilot.

This isn't a balanced diet. You could get serious malnutrition from it, if prolonged. Fortunately, like most diets, it isn't expected to last.

See also, the Relative Diet, and Zeno's Diet.

Bad Weather

We have a thunderstorm, right now, raging outside. I'm glad i closed my windows.

If you closed your windows, how did you post to your blog?

I mean, the windows in my car.

Coolest new app

Well, it's new to me.

sudo apt-get install dict
sudo apt-get install dictd
sudo apt-get install dict-web1913

This gives you a 1913 English dictionary with definitions, from a local dictionary. That means it continues to work even if you are off line. From the command line, this example gives you a definition:

dict synopsis

How fast is your thumb?

My beloved 128 MB Jump drive is lost. Stolen, actually. One of the things that i really liked about it was that the cap really sealed the stuff inside. It survived being left in a pocket and going through the wash. Twice.

My 512 MB Firefly was lost, so i had no thumb drive at all for several weeks. Well, not exactly. My iPod Shuffle is 512 MB (discontinued), and often has 100 MB free, and can be used to transfer arbitrary files too. But, I finally broke down and went to a store. My Jump drive cost something like $35 way back when, and being somewhat short on cash, i wasn't going to spend more than $20. I'd just have to get a small one. In a bin by checkout at MicroCenter, were 2 GB Kingston drives for $15.95. With tax, that's $16.90. So much for settling for a small one.

The Firefly turned up shortly thereafter. Both drives are in use. And something odd turned up. I downloaded interesting audio books from LibriVox, which turned out to be several gigabytes. The Kingston drive seemed to take quite a while to fill compared to the Firefly. Yet, transfer speed at home was much better.

At first, i thought that perhaps the computer at work had an older USB 1.0 interface. That's absurd, though. It's nearly three years younger than my computer at home. And, why would the FireFly be so much quicker? Well, the firefly is a quarter of the size, so maybe that's it. There's no way to get to the bottom of this without some measurements.

It turns out that i'm only writing data at work, and only reading it at home. And the Kingston is nearly nine times slower writing than reading. The Kingston is about 20% faster at reading than the Firefly. But the Firefly is only half as fast writing than reading. So, the Firefly is four times faster writing than the Kingston. And, since it's a quarter the size, filling it takes a 16th of the time.

OK, so the speed of the device is not listed anywhere. Would it be a deal breaker? No. It's quick enough, cheap, and has large tracks of land.

Carded

They card you for Nyquil. Perhaps it still has alcohol.

I would not give anyone like this any strange ideas. For example, when crossing the border into Canada (or on the way back to the US), and they ask, Do you have any drugs?, it's probably not such a good idea to say, "Damn. I left them at home. I knew I forgot something!

When crossing the border, and they ask, Do you have any fire arms? It's probably not a good idea to reply, I can get you anything you want.

But let me know when you're going. I'd like to go along and see if they strip search you.

Make Mine a Double

Radio Lab on WNYC is available as a podcast. Season three starts out with a discussion of the Placebo Effect. For example, the doctor tells you that this light blue pill will make you better, and it does. Only, there are no active ingredients in the pill. You got better, at least to some extent, because you thought you'd get better.

Now, you might think that a doctor who gave you a sham pill is a quack. He doesn't know what he's doing. He's selling moon shine - that is, something you could have gotten without him. But the deal is, you actually got better.

And even the medical doctors who have real training, and are backed up with real medicine, put on their white coat and talk to their patients in a way that convinces them that they'll get better.

Now i listened to this show while sick. I stayed home from work. I'm not paid when i stay home, so when i stay home, it means i'm on death's door. And when i only feel terrible, i go back to work. After all, if i'd stay home, i'd feel terrible, and if i go to work, i'll feel terrible. I may as well get paid for it.

I'm not a good salesman. I've mentioned the bagel club. For me, giving out bagels and donuts for free is a hard sell. And, i'm very skeptical. That means the story has to be really good for me to have any chance of believing it. Double blind clinical trials are the gold standard. Pray to Jesus just isn't going to do it. I can't be hypnotized because, well, i don't believe in hypnotism.

So, imagine that i'm cheap. I don't want to go to the doctor for antibiotics. I have an idea how long it will take me to get over things, and, for the most part, antibiotics don't make me well any quicker. But, i do want to get something that will help. What do i do?

Here are my cures for the common cold. Drink lots of water. In fact, drink a gallon of water a day. You can drink more water if it's room temperature. A gallon is alot. It's probably twice as much as you think it is. So keep a full glass in front of you all day. Drink it. Linus Pauling advocated high doses of vitamin C. I've not found that mega dose pills help at all. Nor an orange. But a pink grapefruit seems to help. Eat the whole thing, without sugar. Avoid sugar altogether when ill. Get lots of sleep. As much as you can. Use any trick you can to get to sleep. Lie perfectly still and try not to think. Turn on a boring radio program and close your eyes. Whatever works. Shower. Brush your teeth. Sore throat? Gargle with aspirin. Gargle with salt. Gargle with mouthwash. Gargle with chloraseptic.

I'm not sure that any of these things work. That is, i don't know that they have any external helping ability. But they feel like they work. And, if you do them all day long, you should at least get the placebo effect on and off all day long. And the placebo effect is real. It's real chemicals that your body releases. And there are no side effects. And, in double blind clinical trials, it really works.

It's mind over matter, after all.

Steve Martin said it best: "I'd like one of those new double strength placeboes, please".

Astounding Science Fiction

I'm just a bit behind in my podcast listening queue. At the beginning of April, Escapepod ran their 100th episode. They run short science fiction. The stories are typically under and hour. Episode 100 went slightly more than an hour. However, it was written by the legendary Isaac Asimov. Nightfall. And, it's good story. Many say it's the best ever written. It's not really dated. You might expect that from a story written in 1941. What i will say is this: If you're only going to listen to one science fiction short story, this is the one to try. And, you might just get hooked. Fortunately, the archives go back to the beginning.