Incomplete arguments

Ever have one of these arguments?

Person 1: "We should not do X because despite A and B, C prohibits it"
Person 2: "Yeah, but we'd get A and B!"
Person 1: "Uh dude, C?"
Person 2: "A and B are great!"

Yeah ... jackass, we agree there, but you didn't address C. A specific example comes from a message board on an Arizona Cardinals's news site, in a story explaining that despite the [intentionally unspecified] compensation they'd get for Larry Fitzgerald, due to esoteric regulations the Cardinals would still have to eat $15 million of cap money, thus making moving him a non-starter. One intrepid reader comments "Trading Larry works for all parties! The Cards are clearly in rebuilding mode and get a ton of value for him, and the other team gets a great player!".

Mr. Reader added a new piece of information (the Cards are in rebuilding mode) that has no relevance to the original disputed statement and thus adds no value. He then agrees with 2 of 3 statements made by the original author, but disagrees by simply omitting the author's 3rd point. Try this one on for size:

Person 1: "There's freedom on the other side of that concrete wall, but if we make a run for it we'll definitely get mowed down by about 100 bullets"
Person 2: "Your hair is red. You should do it. There's freedom over there."

If you want to invalidate someone's statement, address the points they've made. You can bring in new information if you tie it to what you're saying. If you act like the dude above, you just look like you haven't been paying attention at all, or like you're comparing a banana to the speed of a cheetah. Huh? Exactly.

Legacy code warts

Our vending machine at work takes all coins and paper money up to (and including) $20. I am fascinated by the change algorithm: if I buy something for $2.25, it returns the following sequence: $5, $5, change dump (combo of $1 and 25c coins), $5. Why does that last 5 dollar bill come out after the small change? Who programmed this thing and was it just some terrible change algorithm, or were they artfully covering up for some other system component, like maybe the paper money feeder is slow and it takes time to load up that third bill?
I've been trying to deduce the logic that's running in the background, and there are several options. In general, the approach seems to be to reduce the amount owed until it reaches zero. However, the order of operations seems odd. How could this output have been constructed? Suppose we're looking at just the function to output money owed.

Algorithm 1 (the simple one):
void ReturnChange(int cents) {
   while(cents >= 500) {
      Return5DollarBill();
      cents -= 500;
   }
   while(cents >= 100) {
      Return1DollarCoin();
      cents -= 100;
   }
   while(cents >= 25) {
      ReturnQuarter();
      cents -= 25;
   }
   while(cents >= 10) {
      ReturnDime();
      cents -= 10;
   }
   while(cents >=5) {
      ReturnNickel();
      cents -=5;
   }

   Assert(cents == 0);
}

This is simple, it works, and returns the fewest number of currency units needed. It will fail, however, if the machine is short on any denomination it needs. This is simple enough to fix up though:

Algorithm 1.1 (with error handling):
bool ReturnChange(int cents) {
   while(cents >= 500 && Return5DollarBill()) { // Return5DollarBill returns true iff it succeeded
      cents -= 500;
   }
   ...
   // and so on
   return cents == 0; // make sure the customer is happy. If not, ring a bell for service ...
}

So why on earth would someone not do it like this? And what might the code look like? I feel like I'm on some horrible conspiracy show. It's likely rather simple and rooted in the history of not this machine, but its ancestors. There was once a time when machines could only take coins or a $1, but for simplicity we just need to go back to when $5 was the cap. ReturnChange probably looked just like what I wrote above, except it didn't have the first while loop. Let's call this version ReturnChangeForUpTo5Dollars. Then some slick business guy realized that a lot of people don't carry small change around anymore because paying with plastic is so much more common. However, it's probably not unrealistic that someone has either a $5 or $10 bill, and the vending machine should support these. He pushed a task through engineering to update the machines with this new capability. Engineering looked at the building blocks they already had and how they could solve the problem:
1. Simply run the same algorithm over the now up-to-10-dollar amount. This gets shot down because if there's one thing worse than not getting a snack, it's getting 9 bucks in change.
2. Add the ability to feed out paper money. The 1 dollar case is already covered (and isn't useful unless a customer is using the vending machine as their strip club money dispenser), so they need to have it shoot out 5 dollar bills. Once they do this, they can simply wrap ReturnChangeForUpTo5Dollars to make ReturnChangeForUpTo10Dollars:

Algorithm 2:
bool ReturnChangeForUpTo10Dollars(int cents) {
   if(cents >= 500) {
      if(!ReturnChangeForUpTo5Dollars(cents - 500)) {
         return false;
      }
      if(!Return5DollarBill()) {
         return ReturnChangeForUpTo5Dollars(500);
      }
   }
   else {
      return ReturnChangeForUpTo5Dollars(cents);
   }
}

Notice the slightly odd code above! It has to account for the possibility of the machine being out of 5s. Thus if we try to dispense the $5 bill first and fail, we have no fallback case and need special case code to dump 5x$1, and if that fails ... in short, the whole fallback sequence has to be re-implemented. Like all good engineers, this guy found a way to re-use code that already existed, was tested, etc. Now of course they could have organized this a bit differently (and recognized that despite its name, ReturnChangeForUpTo5Dollars is general enough to return change for any amount), but the above is quite straightforward and easy to verify.

After the above update ships, they notice that there isn't a big uptick in sales, and specifically the number of 10s and 5s in the machines is about the same as before. Unfortunately Slick Biz guy forgot that most Americans (and counterfeiters) prefer 20 dollar bills ... so here comes Snack Attack 2.0! This time the engineers conclude that they don't need to invent the ability to dispense 10s because they can just use 5s and that's fine. They just need to update the return algorithm, and this time they're just gonna make it general so that they stop getting bothered about this:

Algorithm 3:
bool ReturnAnyAmountOfChange(int cents) {
   // we know how to return 10 bucks, so shave it down to that in $5 increments
   while(cents > 1000) {
      if(!Return5DollarBill()) {
         // if we have no 5s left, just give them a slot machine's worth of change. Sorry customer.
         return ReturnChangeForUpTo5Dollars(cents);
      }
      cents -= 500;
   }

   // and finish this off
   return ReturnChangeForUpTo10Dollars(cents);
}

Again, they could have just as easily updated either of the existing functions, but software engineers tend not to like to touch existing code. We're trained to be paranoid about breaking existing functionality. In this case, we'd need to re-test all less-than-$10 scenarios as well, incurring extra cost before getting to ship.

Of course I have absolutely no clue that this is what happened, but I wouldn't discount this theory!


 

Not the same old Google

Remember when Gmail started and Google told us how they have major architecture in the way of your personal data ever getting out of their deep dark well while they analyze it? They made sure to anonymize you completely before passing your content to their analyzer, etc. This way, nothing personally about you could ever escape.

According to an Australian app developer, he was able to see a list of all the people that bought his app. The list included approximate locations and emails; the developer says it'd be trivial for him to, for example, harass anyone who gave his app a bad review. Assuming his claim is true, this is an interesting failure. It's not just a simple bug, after all. It means that architectural safeguards like what was claimed around Gmail are no longer in place. This suggests that they no longer value our privacy as deeply as they once [claimed they] did.

Update: Apparently the above is a by-design behavior because the apps are not sold by the store, but rather by the developer, through the store. I can accept this as a business decision, though I still find it a little odd. In most other stores I can buy an item anonymously (just walk in and pay with cash). I guess it comes down to if people are actually aware that their info is sent to the app dev. While it is stated in the terms of service, if it's not commonly discovered, I'd argue it's still an iffy model. Given that it made the news, it seems this is not commonly known.

Other incidents such as Street View cars collecting WiFi and device information were swept under the rug as bugs in Street View programming. I think it's pretty hard to accidentally log things you never intended to log ... it could be a bug that they didn't remove it despite intending to, however making the data public suggests otherwise. They at least didn't carefully scrutinize what they collected, and more likely were hoping no one would raise a fuss. Android phones tracking user locations over time were also dismissed due to the data being anonymized. Magnus Eriksson's questions include, rightly, "what internal processes are used to vet any possible privacy concern?"

At a maximum, this is a symptom of "serving ads for dollars, no matter the cost". At a minimum it means that incidents like this will keep happening and we can't treat them as a premier secure partner.

Even regardless of intent, continued sloppy handling of sensitive information should lead us to a single conclusion: they just don't handle your personal information in a way you can trust.

Compromise

Is the key to relationships, I've heard. Says Oprah. Says the person at the dinner party.

Compromise is a funny thing. It's this great concept, but the phrase has no guidelines. What does it really mean? Or in the case of relationships, when is it not even worth pursuing?

I believe that microcompromise is a bad thing: your favorite foods, TV shows, movies, whatever, are different, so each time you find the solution that both of you can agree to... and neither of you are really excited about. Carrying on with this course of action leads to a life filled with mediocre experiences.

Macrocompromise is key. Overall, you should both feel like you're getting to do things you really want to do. Maybe you really care about the interior decor and the other one cares about eating your not-so-favorite food twice a week. If something is important to the other and not of serious consequence to you, let them have it their way. They should respond in kind.

Given two people, it's impossible to have 100% aligned wishes. The key is to get to keep doing things you each love, because that will let you not care about the things you don't. If you instead opt for never doing things you hate (at the expense of getting to do things you love), you'll fall in that rut and either never come out or explode out in some crazy way.

In the case of relationships, the key to building them is to grow together. Opting to take the safe, mediocre compromise each time has the opposite effect. See what your significant other loves about that thing you're not excited about. Maybe you'll end up liking it too. At a  minimum you'll see them through one more lens and learn something new. And you'll have grown. Together.

Scaling to capacity

Remember that time you got a new computer and figured you'd never ever ever be able to fill up that 100gig hard drive? Or back when the internet was slow and you finally got DSL and figured it'd be lightning fast forever? And then again when you got cable internet and now it really should rock?

And then you started storing pictures in ever-growing formats. 10 years ago a typical jpg image was 50 kilobytes, now my wife sends me pics over a megabyte over the phone ... and for the most part, there's no additional information in there. We started storing movies on our hard drives instead of burning them to CD. We bloated websites with more and more visual doodads. News providers upload more and more of their content in video form (rather than the far more convenient and faster-to-download text). In other words, increased capacity opened up the question "how else can I use more of it?", or alternatively, the idea that "who cares!"

Take a look at your Facebook feed. When someone wants to convey an idea, they no longer just post words. They post a picture of the words. Pretty soon we'll have a site that automatically makes a picture with the words (and optionally falsely attributes them to a famous person), then posts that on our behalf. Have we really improved our experience? Or is the world just turning into MySpace?

Startup interview

With an unknown company. Read on!

Hi this is ___ . Let's start with a coding-type question. Suppose I give you N locations on a map and I want to later find out .....
Well, I'm thinking it'd be a lot like ...

We talked through the problem, he was happy with my solution. Moving on.
So now let's talk about being at a startup. We have a great idea, and we're going to be working really hard for the next 6-8 months to get it off the ground; I'm thinking like 80 hours a week. We have 3 guys including me, you'd be the 4th. Compensation is more in the form of company shares than in salary, so probably like $35,000 a year. Since you'd be getting in early, this could work out really well for you.
Wow, well that's certainly a departure from my current job that pays double, with benefits, for working half as much. But if it has great potential, I'm willing to listen. What is the big idea anyways?
Basically, we're going to sort certain data. This data is very hard to sort, but people are willing to pay big money for a good sort. It's a multi-billion dollar industry. We already have partners signed up to consume our sort results.
Ok, that could mean a lot of things. What ... are we talking about here?
I can't tell you more right now, but if you want to fly up [on your own dime] to Seattle [from Tucson, at the time] and sign an NDA, I can tell you more about it.

I never did follow up with them.

Turns out the company (TalentSpring) was focused on sorting the quality of resumes in a database, allowing HR departments to more efficiently filter for the best candidates. I watched a video describing their approach and didn't particularly care for it.

Unfortunately for them it doesn't seem like they made it big, but that helps me sleep easier at night :)

Defense contractor interviews

They all followed the same fluff interview format as my chat with Cerner.
However, I alerted all of them that I am a dual citizen. None of them thought it was an issue. None of them called back.

Much later I found out that being a dual citizen (at least around 2003/2004) precluded a person from getting security clearance. Without that, it's pretty much impossible to be of engineering value to these guys.

Guess we all wasted each other's time.