Archive | Fun RSS feed for this section

Let’s Talk Ketchup

1 Jun

ketchup

I was in a conversation yesterday about a forecasting tool we use to manage our sales pipeline in Application Development. I’m frustrated about some of the tool’s limitations, and I was ranting to one of my peers, Rob, that I wanted to throw it out and build something new.

Rob tilted his head to me and gave me a narrow gaze. “Or…”, he offered. “You could just find a way to make it better.”

And that’s something, I am embarrassed to say, that hadn’t occurred to me. As a self-proclaimed smart guy who sometimes wears the mantle of leader, I all too often feel like it’s my job to generate new ideas, to create new solutions, to invent my way out of any issue, dilemma or challenge. Because what’s more American than creating things, am I right?

Which makes me think about ketchup.

What’s more American than ketchup? We put it on our burgers, we put it on our fries, on our eggs, our hash browns, and in our macaroni and cheese. We serve it with our breakfast, our lunch, and our dinner. No less than 45 American companies manufacture and distribute their own variations of ketchup to every corner of the globe. The red on the American flag might as well be painted with it – it’s that American. When was the last time you went to a casual restaurant or “American Bistro” and they didn’t have a bottle at the ready, or pre-set at your table?

It’s as American as apple pie. More! As American as freedom! Ketchup is the liquid equivalent of a bald eagle clutching a McDonalds bag as he soars over the Rocky Mountains and into the setting sun. It’s that American! But where did this stuff come from, this American red gold?

Does it matter?

Let’s dig a bit and see. Ketchup came to the Western world in the late 17th century, given to European traders in their travels to the Far East. There are stories dating back to 1690 which describe a vinegary, pickled condiment found in the Fujian region of coastal China reportedly called “ke-chaip”, and similar stories from 1710 and ’11 describing an Indonesian “brined” sauce referred to sometimes as “kecap” and sometimes as “ketjap”.

Nobody knows what it was about this exotic condiment that westerners found so intoxicating, but we sure did love it. We were making catchup in Great Britain as early as 1727 – nearly 50 years before the American Revolution! The condiment was so important and pervasive that it had already found its way into a “new world” cookbook as early as 1801. In America, catsup (apparently it was Americanization that changed catchup to catsup) was made regionally and sold by farmers across much of the 1800’s.

In 1876, the H.J. Heinz company started mass-producing their own unique blend of catsup, and – in the hopes that it would make their product stand out from the farmer’s alternatives – they decided to call their sauce ketchup. Over the next 10 years, every other manufacturer followed Heinz’ lead, and as the manufactured food industry exploded in the new world so did ketchup.

Fast forward a hundred and twenty-five years, your local grocer probably stocks between ten and twenty brands of ketchup (some even spelling it catsup again) – all manufactured in the U.S. and distributed to every country in the world. There are 196 nations on the face of our planet, and the one thing they have in common – all hyperbole aside – is the presence of ketchup.

Weird, right?

Americans didn’t discover or invent ketchup. We weren’t the first to create it, the first to document it, the first to fine-tune it, the first to trade it, or the first to sell it. We just took something good and made it better. We looked at what we had, and – through trial and error, through experimentation and discovery – we turned it into something better.

Which brings me back to my conversation with Rob.

We’re often in the situation that we need to determine whether to make something or to take something that already exists and make it better. In Application Development, we’re probably in this situation more than most; but I think everyone can relate: Fix the deck or build a new one? Steam-clean the couch or buy a new one? Sand and re-stain the table or buy a new one? When we’re in those situations, it almost always seems like the “best” choice is to make something new instead of taking something that already exists and making it better.

The next time you’re in that situation – and the next time I’m in that situation – consider this:

EASIER DOES NOT EQUAL BETTER

Just because it’s easier doesn’t mean it’s better. Just because you want to doesn’t mean you should. Just because you thought of it, that doesn’t make it the right choice. Maybe take a moment, the next time you find yourself facing a make it better moment, to dip your decisions in ketchup, that uniquely American condiment.

Americans didn’t make ketchup, We just made it better.

 

Andrew J. Powell Principal- Application Development

Andrew J. Powell
Principal- Application Development

Andrew Powell serves the Application Development practice at OST , providing guidance, strategic support, and candy to more than fifty developers and consultants. Andrew has been a technology consultant for more than twenty years. In addition to consulting, Andrew is a frequent public speaker in technology circles, and loves to talk about the coming Robot Apocalypse and how application developers are positioned to defend the world against our future robot overlords. When not cowering in fear, Andrew makes his home in Grand Rapids, Michigan.

 

The Data Doesn’t Lie

5 May

Data is funny.

We use it to tell us all sorts of things. We call it empirical. We talk about how the data doesn’t lie. We look at numbers, look at trends, and we draw conclusions – not just the data scientists in the crowd, but everybody. How much money did you make last year? How profitable is the latest Captain America movie? Who is the most successful batter of all time? The data will tell us.

 

But … will it?

 

Let’s look at a couple of baseball players and examine their batting averages. This is real data I’m using here, and the math is pretty easy. For the sake of conversation, let’s try to determine who was a better batter – Derek Jeter or David Justice. To make things simple let’s examine a data set of just two years, 1995 and 1996, and let’s talk about each player’s batting average – that’s the percentage of time, when a batter is at bat, he gets a hit.

Derek Jeter’s batting average for 1995 was .250 and for 1996 was .314

David Justice’s batting average for 1995 was .253 and for 1996 was .321

What does the data tell us? It’s pretty clear, right? If you’re gonna pick a better batter for 1995 and 1996, you’d choose David Justice. He was a more successful batter that Derek Jeter was. He hit the ball with more reliability. That’s not my opinion – The data says so!

Not so fast. Let’s combine the two years:

For the two-year period combined, Derek Jeter’s batting average was .310

For the same period, David Justice’s batting average was .270

Wait, what?

That’s not a typo, that’s Simpson’s Paradox in action. Edward Simpson first described his statistical finding this way: “Trends which appear in groups of data may disappear or reverse when the groups are combined.” Seem unbelievable, right? It’s not. It’s just math.

Let’s look at the raw data. I put the “winner” in bold in each data set.

 

1995:                           Hits                 At Bats            Average

Derek Jeter                 12                    48                    .250

David Justice              104                  411                  .253

 

1996:                           Hits                 At Bats            Average

Derek Jeter                 183                  582                  .314

David Justice              45                    140                  .321

 

Combined:                  Hits                 At Bats            Average

Derek Jeter                 195                  630                  .310

David Justice               149                  551                  .270

 

The data doesn’t lie. David Justice had a more successful percentage of at-bats in 1995 and a more successful percentage of at-bats in 1996 … and when you combine the two years, Derek Jeter is the better batter. Sorry, David; when you aggregate data, sometimes there’s just no justice.

I’m not saying data can’t be trusted – that’s not the point at all. Data can always be trusted. It’s empirical, remember. Data doesn’t lie. The paradox is that both cases are true. David Justice had a higher batting average than Derek Jeter in both 1995 and 1996. This is a fact. Derek Jeter’s 1995/1996 Combined batting average is higher. This is also true. It seems like these things can’t both be true, but they are.

And that’s the point.

The world isn’t binary. We think if A is true then B must be false, and that’s almost never the case. We think, if we’re right about something, then others must be wrong. We think if what the data tells us is true, then what the data doesn’t tell us is surely false.

All too often, we’re wrong.

Let’s talk about movies for a second. Which movie was more successful, The Avengers, or The Fast and Furious 7? Let me give you some data to help you figure this out:

 

Movie                          Worldwide Gross

The Avengers              $1,517,557,910

Furious 7                     $1,516,045,991

 

The answer is obvious. The Avengers was more successful, right? The data says so. The math is clear. The Avengers made $1.5 million more than Furious 7. Box office numbers don’t lie! But there’s more to the data than that. Dig a bit deeper and look at the movie’s cost:

 

Movie                          Budget

The Avengers              $220,000,000

Furious 7                     $85,000,000

 

So The Avengers cost $135 million more to make than Furious 7 did, and only made $1.5 million more than Furious 7 did. Doesn’t that mean Furious 7 was more successful?

I guess it depends on how you define successful. And that brings us closer to something you can take away and think about. If you define a movie’s success to be a measure of tickets sold (and dollars earned) at the box office, you are correct in asserting that The Avengers is more successful. If you define a movie’s success as the function of the movie’s box office receipts less the movie’s budget, you are correct in asserting that Furious 7 is more successful.

Despite your binary instincts, telling you only one or the other is true, the data confirms for us that both scenarios are true.

It’s all about how you look at it.

Consider this the next time you find yourself in a disagreement with someone about something. What if the fact that you’re right doesn’t mean the other person is also wrong? What if you’re facing Simpson’s Paradox? What if you’re both right?

It’s not always about who is right. Sometimes, everybody is.

Andrew J. Powell Principal- Application Development

Andrew J. Powell
Principal- Application Development

Andrew Powell serves the Application Development practice at OST , providing guidance, strategic support, and candy to more than fifty developers and consultants. Andrew has been a technology consultant for more than twenty years. In addition to consulting, Andrew is a frequent public speaker in technology circles, and loves to talk about the coming Robot Apocalypse and how application developers are positioned to defend the world against our future robot overlords. When not cowering in fear, Andrew makes his home in Grand Rapids, Michigan.

 

How Software Developers Learned from the Food Service Industry

2 Mar

We had a kind of odd Leap Day celebration this year at OST – we ran a one-day-only pop-up restaurant from within our headquarters in Grand Rapids. I know what you’re thinking: “Wait, what?” I’ll say it again. We served breakfast and lunch to nearly 80 customers, including a Rice Krispy-crusted French toast, an eggplant, squash and zucchini tower, and perhaps the fanciest lasagna roulades I’ve ever seen.

Why would a technology firm – a company that prides itself in our Design to Datacenter delivery framework – spend the last Monday of the month running a restaurant? It’s a fair question, and something I spent a lot of time thinking about as I stood in our lobby, decked out in my Café OST t-shirt and seating guests and clearing tables.

Here, then, are the three most obvious lessons learned:

We succeed and fail together. Whether you’re taking orders, plating lunches, running food, or clearing tables, you can’t run a restaurant without counting on the rest of the team to support you. What would happen if, every time a customer gave an order to the waiter, your waiter said, “I can’t cook that, so I don’t know what you’re going to get.”

It’s true, though. Your waiter isn’t going to cook your lunch, but they are trusting that the kitchen staff will, and that trust is so strong that they make recommendations, take our orders, and never hint that there is any chance that things won’t go exactly as planned.

Is that dishonest? Is it wrong that I’m confirming details that are outside of my control? Absolutely not. It’s essential to our success. As a team, each of us has unique abilities and responsibilities, and we’re trusting on each member of the team to fulfill their role. The sales team can’t write code, and the delivery team isn’t responsible for selling; but without the two working together, trusting that they can do their jobs, we’d all be out of work. Whether your work is in a restaurant or you’re part of a complex software delivery team, whether you realize it or not, we succeed and fail together.

Details matter. One of our customers today had a silverware roll that was missing a fork. Something as simple as a fork has the ability to define or deny a customer an enjoyable experience. How can I eat a salad – even the best salad in the world – without a fork? I can’t. Paying attention to those details, working to ensure that no detail is overlooked that nothing is taken for granted – that’s the most-basic building block of successful service.

I don’t make forks. I wasn’t even responsible for forks today. I’m not even sure that I know where the forks were kept – but I know that forks matter. And I was on the look-out, every time we reset a table for the rest of the day – to ensure everyone had a fork. We each have our individual roles and responsibilities, but we’re all responsible for quality control. They say the devil is in the details – the details matter, and it’s everyone’s job to keep them in focus if our goal is to deliver quality.

Service is service. Whether you’re waiting tables, baking quiches, or plating lunches, you’re in service. Whether we’re writing code, configuring RAID arrays, updating a virtual environment or providing strategic assessments, you’re in service. Whether we think of it that way or not, we’re a service provider, and our (unspoken) commitment to all of our clients is the exact same in our real lives as it was in Café OST today – to deliver exceptional service.

We have the luxury as consultants to define our customers’ expectations. Then we get the pleasure of delivering on those expectations. That contract defines what we do, and defines everything we do in the service industry. I am proud to have dedicated my life to the service industry, and thankful that I got to spend the day reminding myself of this.

I’m thankful that I work for a company where we’re granted that luxury to learn. There is so much to do, and only so many hours in a month – how great is it to have been given the grace to spend a whole day of that time focusing my energy on the core of what we do?

Here’s my call to action for you: Find the time. Every moment you spend learning is a moment that will reward you tenfold. Every minute you spend exploring why you do what you do is a minute that will color all the minutes that follow it.

Your order is in the window.

Eat up, while the plate’s still hot.

_ _ _

Andrew Powell edited photo

Andrew J Powell, Application Development Principal, OST

Andrew Powell serves the Application Development practice at OST , providing guidance, strategic support, and candy to more than fifty developers and consultants. Andrew has been a technology consultant for more than twenty years. In addition to consulting, Andrew is a frequent public speaker in technology circles, and loves to talk about the coming Robot Apocalypse and how application developers are positioned to defend the world against our future robot overlords. When not cowering in fear, Andrew makes his home in Grand Rapids, Michigan.

The Smartphone as the Personal Health Assistant: The Breathing Chapter

4 Nov

1
It’s a beautiful day in West Michigan and I am taking the time to get some work done around the house and in the garage.  I decided to take the opportunity while working to monitor my breathing using the MyBreath app from Breath Research.  It’s a startup company that is working with academic and medical researchers to find ways to monitor breathing using the sound capture from the iPhone microphone on the earbuds (http://www.breathresearch.com/).

I am a bit of a healthcare and technology geek as those that know me well can attest to.  I am a follower of the quantified self movement.  But not to create a data-driven life, but rather to instill within myself a sense of mindfulness.

I sing in choir, so I know how I should breath while singing, but this app had me thinking about the kind of breathing I was doing with simple activity and it was interesting to watch how my breathing changed through the course of my afternoon.  As I became mindful of my breathing, I realized how there was a link between my conscious thoughts, physical labor and my body’s adaptation through breathing.

I am not advocating moving autonomic functions into the level of conscious thought, but I could see how this could apply nicely to an asthmatic patient, COPD sufferer, or a person with chronic emphysema.  That ability to understand the linkage in normal activity to the stress factors that might cause a flare-up would be useful.

I will try this again when I workout.  Just to see how I can optimize my breathing to my physical exertion.

And oh yeah, when I thought a spider was crawling up my leg.  That made a difference too…

Originally posted on LinkedIn.

Jim VanderMey, Chief Innovation Officer, OST

Jim VanderMey, Chief Innovation Officer, OST

Jim VanderMey has served as VP of Technical Operations, CTO and now Chief Innovation Officer for OST. Jim has provided the technical leadership and product strategic planning for the organization since the very beginning. Jim is a technology visionary who sets the long and short-term direction for OST. He specializes in seeing the “big picture” of technology, industry trends and the business objectives supported by IT. As OST has gained an international reputation, Jim has taught and spoken at conferences in Europe, Japan, and throughout the US. Lastly, we must confess that some of OST’s peculiar culture is a direct derivation of Jim’s unorthodox style.