Tag Archives: Application Development Blog

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.

 

How to embrace the principles of Agile software development

13 Apr

Those who know me well know that I am obsessed with Alexander Hamilton. He’s the founding father you didn’t learn about in US History, mostly because he never became President. You probably know he was killed in a duel with Aaron Burr, you might even recognize him as the dude currently gracing your ten-dollar bill, but you probably don’t know that he was an orphan, an immigrant, and the guy who single-handedly created America’s financial system. (You should also thank him for the Constitution’s ratification – he wrote 51 of the 85 essays that make up the Federalist Papers.)

My obsession with Alexander Hamilton has taught me a number of things – about myself, about my work, and about how to simultaneously serve with humility and fight for what you believe in. More surprising, though, he’s also taught me something about embracing the principles of Agile software development.

 

“A well adjusted person is one who makes the same mistake twice without getting nervous.”

 

Think about that for a minute. It seems to run contrary to everything you were taught in school, doesn’t it? Making a mistake is bad enough, but making the same mistake twice, that’s unforgivable! We think of a mistake as the opposite of a success. We’re wrong.

Our software development delivery process at OST is based on the Agile Manifesto (www.agilemanifesto.org). The Agile Manifesto, and Agile software development in general exposes to us a core concept that iteration is a key to success. Responding to change wins out over following a plan every time.

In software development, this makes sense. Try something. If it doesn’t work, try something else. Do something. If it doesn’t match the user’s expectations, learn from it and do something else. Build something. If it doesn’t satisfy all of your needs, build more. This is how we do what we do. We start somewhere, and then we iterate. We test out ideas and approaches. We validate concepts and database constructs. We build, tear down, and build again. We iterate, iterate, iterate; each generation an improvement on the last.

It’s great! It’s a process that makes great solutions, and a framework that sets projects up to continually improve. At its core, continuous improvement requires that you have room to improve; embraces the notion that there is always opportunity to improve.

In life, though, that’s a hard concept to wrap our heads around. We don’t provide ourselves with a lot of grace to make mistakes. We tend not to look fondly on things that need improvement. And our lexicon is full of really awful words that we toss around at ourselves (and others) when things don’t go as well as we hoped. You failed. You blew it. You screwed up. You made a mess of things. You got it all wrong. You lost sight of the big picture. They’re terrible, soul-crushing words. Defeat. Collapse. Crash. Bomb. Die. They’re all words and phrases we employ to remind ourselves just how awful it is to fail.

Enough already!

Here’s what Alexander Hamilton taught me. It’s not awful to make a mistake. It’s essential. Let me say that again – it’s that important.

Failure is required for success.

It’s a foundational principle in practical Agile software development, and a foundational principle in life.

Fail. Make mistakes.

Then learn from them.

 

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.

Start Somewhere

11 Feb

snow-shovel

Snow Business

Winter is here, at last, and as the primary snow shoveler in my family, let me say I’m none too happy about it. The past week brought me a foot of snow, and it’s not gonna shovel itself.

Staring out my kitchen window at twelve heavy inches of snow burying my driveway, it was daunting to imagine how I’d get the driveway clear, and just thinking about the work involved seemed more than I thought I could take. I’m not as young as I once was, and it sure seems like they’re making heavier snow than they used to. Plus – when did my back start to hurt all the time?

I didn’t do it. I didn’t shovel. I put it off for nearly a week, thinking it wasn’t really winter yet, thinking it would melt on its own, thinking the snow fairy would grant my wish for a clear driveway, thinking – somehow – that, if I just came up with the right plan, I’d be able to eliminate the snow without sloughing through it, one shovelful at a time.

Time to get to shoveling.

No matter what end result you seek, there’s only one way to get there. You’ve got to start. It may sound silly, may sound obvious, may seem like advice not worth giving … but we’re an easily overwhelmed species. Nothing ever got finished that didn’t first get started.

Come to think of it, that’s a foundational step in every project we work on at OST. We help our clients get things started. Our clients aren’t in the IT business – they’re looking to us to HELP them make smart IT decisions. That’s not easy – for them or for us. When you’re working with complex corporate systems, trying to determine where (and how) to begin can be overwhelming, even paralyzing. It can seem impossible to know where to begin, and sometimes it’s easier to maintain the status quo out of fear that anything else seems overwhelming.

My simple advice? Start. Start somewhere. Just start. You don’t have to know where you’re going to end before you start, and accepting that you DON’T know is powerful – it opens you up to opportunities for discovery that’d you’d be blind to if you thought you had to figure out where to end before you started. Start somewhere. Just start.

That driveway’s not going to get clear without a first shovelful. Dig in. Get that shovel down to the pavement and give it a good toss. Put your fear and loathing aside, toss away your anxiety and paralysis, and I bet you’ll discover the same thing I did:

It feels good to get started.

_ _ _

Andrew Powell edited photo

Andrew J. Powell

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.