Tag Archives: Software 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.

5 Keys for Successful Software Application

2 Apr

Last week, Brian Anderson, our  Application Development practice principal was featured on the Technology section of Corp magazine. Here he gives 5 helpful tips on how to maintain successful business practices when developing software applications.

Software applications are powerful business drivers of productivity. It always amazes me how far companies that get this insight can automate, optimize and fine tune their businesses. It is fun to observe and be a part of. I have been a software development consultant for 15 years and would like to share with you five keys that great companies and software development firms do to increase their odds of success.

1. Don’t get hung up on billable rates. Focus on the people who are going to work on your project. Vet their experiences and references.
We all like a great value and no one likes to pay more for something than they have to.  In the world of software development services there are a wide range of capabilities and experiences. If you find someone with the right set of skills, experiences, and references, that person can be at least three times more productive than a junior level that is just getting started. People like this know how to lay the framework for everyone else to be successful. When hiring a firm make sure to ask who are the senior people on their team that will be working on your project and vet those people. It is OK to have juniors who cost less but don’t assume that they will be as productive or capable of doing the work without some senior leadership.

Continue reading