I had the pretty unique opportunity to sit on a panel at the 2012 National Restaurant Association (NRA, not to be confused with the other NRA) show this past June which focused on online ordering and the potential that technology offers.
Bob Ryals of www.foodserviceradio.net reached out me after the panel appearance to conduct a phone interview. We talked about how we've built out our online ordering solution at Lou's and about how different types of operations would potentially want to take different approaches.
You can listen to the interview here.
Sunday, September 9, 2012
Thursday, July 19, 2012
My Recipe for Agile Development
Software development isn't easy. It never has been. In an effort to tame the beast that it is, development teams and managers seem to come up with new methodologies on a daily basis. There's XP, agile, scrum, yadda yadda.
In the ten years or so I've been out of school, I've gotten to experience a handful of environments and styles. I started on a large development team in a huge organization and did some solo contracting work during that time. Once I transitioned to my current job, I developed solo for a while when the company was about half of the size it is now. As we've grown and I've grown my team, I've moved into managing a small group of developers on which my role is mostly advising and minimally developing.
Through those transitions, I've settled in on a few guiding principles that work for me. They might now work for everyone, but here goes:
Find the right users for beta testing: Anyone who's done software will understand this one. The wrong users will give you vague, generally not very useful feedback. You won't get much insight into how you can make your product better.
If you don't have the right users, design your software to tell you when it breaks: The original Pragmatic Programmer gets credit for this one. It's particularly useful when your portfolio of applications has a significant number of background tasks. Unless you have a reliable way of being notified when a process goes awry or encounters data that causes it to throw an exception, you won't know about it. Nobody I know is diligent enough to review logs everyday. Don't kid yourself.
Painless Documentation: I know plenty of developers who'll tell you that good code negates the need for heavy documentation or that good code is your documentation. In practice, particularly with a language like Ruby, this can be pretty close to the truth. However, it's usually not sufficient. Between tools like RDoc and JavaDoc, adding meaningful, high-level explanations inline with classes and methods is so easy that it's almost seamless. I like to explain the context or the thought process which led to a particular approach here, since that's usually the first thing I forget when moving on to another project. If you write clean code and abstract everything properly, your code can come pretty close to speaking for itself otherwise.
This is such a massive topic that I've only barely scratched the surface. I could probably write another 50 posts on it and still just cover only a fraction of the body of knowledge out there. But it's a start.
In the ten years or so I've been out of school, I've gotten to experience a handful of environments and styles. I started on a large development team in a huge organization and did some solo contracting work during that time. Once I transitioned to my current job, I developed solo for a while when the company was about half of the size it is now. As we've grown and I've grown my team, I've moved into managing a small group of developers on which my role is mostly advising and minimally developing.
Through those transitions, I've settled in on a few guiding principles that work for me. They might now work for everyone, but here goes:
Wiki Requirements: I like a living, breathing collection of requirements which my team and our end user or customer both have read / write access to. I also think it needs to have a single home instead of living in an office file which starts on a network drive and then gets duplicated into twenty different versions. It's best to keep it dead simple and in plain english. If everyone can read and understand it, it serves as an informal contract we can all refer back to. (This doesn't have to live on a wiki, but it's a pretty natural fit.)
Fast Iterations: The agile school definitely did get this one right. The faster we can put functionality in front of an end user and get their feedback on it, the faster we know if we got it right. It's almost impossible to hand over a product that doesn't meet your customers' needs if you work in short development cycles and constantly get feedback along the way.
Find the right users for beta testing: Anyone who's done software will understand this one. The wrong users will give you vague, generally not very useful feedback. You won't get much insight into how you can make your product better.
If you don't have the right users, design your software to tell you when it breaks: The original Pragmatic Programmer gets credit for this one. It's particularly useful when your portfolio of applications has a significant number of background tasks. Unless you have a reliable way of being notified when a process goes awry or encounters data that causes it to throw an exception, you won't know about it. Nobody I know is diligent enough to review logs everyday. Don't kid yourself.
Painless Documentation: I know plenty of developers who'll tell you that good code negates the need for heavy documentation or that good code is your documentation. In practice, particularly with a language like Ruby, this can be pretty close to the truth. However, it's usually not sufficient. Between tools like RDoc and JavaDoc, adding meaningful, high-level explanations inline with classes and methods is so easy that it's almost seamless. I like to explain the context or the thought process which led to a particular approach here, since that's usually the first thing I forget when moving on to another project. If you write clean code and abstract everything properly, your code can come pretty close to speaking for itself otherwise.
This is such a massive topic that I've only barely scratched the surface. I could probably write another 50 posts on it and still just cover only a fraction of the body of knowledge out there. But it's a start.
Friday, July 6, 2012
Great Post by Noah (Resident Data Nerd) of 37 Signals
These guys are on my short list of business idols. (And to boot, they're a Chicago company.) One of their hallmarks is reducing everything to an almost deceptive level of simplicity. Noah continues in this tradition with his latest post on Signals vs. Noise.
Tuesday, June 26, 2012
"Free" isn't really free
... at least when it comes to consuming services online these days. The latest Facebook gaff (changing everyone's primary address to your.name@facebook.com) shouldn't really come as much of a surprise and absolutely shouldn't piss anyone off.
Yes it's boneheaded, but we are in an age we we're willing to trade privacy and personal information about ourselves for a service or convenience. I love and use Google's "free" services (gmail, calendar, tasks) on a daily basis. And I do this with the knowledge that I'm giving Google more and more information about my personal life, who I communicate with, what I do with my time, and even where I am on every day. But I'm ok with it. If I occasionally see an ad that's so targeted it strikes me as almost eery, they're just doing their job.
As consumers, we're not really Google's customers. The advertisers are. We and the data Google, Facebook, and all of their cohorts have about our behavior are. If you don't want to see targeted ads or have Facebook muck with your profile, get yourself offline. Online privacy is quickly becoming a thing of the past.
Yes it's boneheaded, but we are in an age we we're willing to trade privacy and personal information about ourselves for a service or convenience. I love and use Google's "free" services (gmail, calendar, tasks) on a daily basis. And I do this with the knowledge that I'm giving Google more and more information about my personal life, who I communicate with, what I do with my time, and even where I am on every day. But I'm ok with it. If I occasionally see an ad that's so targeted it strikes me as almost eery, they're just doing their job.
As consumers, we're not really Google's customers. The advertisers are. We and the data Google, Facebook, and all of their cohorts have about our behavior are. If you don't want to see targeted ads or have Facebook muck with your profile, get yourself offline. Online privacy is quickly becoming a thing of the past.
Thursday, June 21, 2012
A Reminder That People Are People
There's a phenomenon that has bothered me since early on at my first job out of college. We (I can fall into the trap of being guilty as well) tend to dehumanize people by calling them "users", "customers", "resources" or something other than people. I think that it's particularly pervasive within I.T., but it definitely shows up in other departments as well.
I can't stand it.
Firstly, it just sounds ridiculous. "I've got some resources on my team which would be valuable on this project" is something I heard often during my tenure in a huge, corporate IT department. It's borderline offensive. How about "Steve is a rockstar developer who really understands the framework you're proposing to use. He might be a huge help." It's just so much more human.
Secondly, it puts us in a terrible mindframe. If people are just cogs in a machine, we're biased toward thinking that they'll simply just behave rationally and predictably. This couldn't be further from the truth, particularly when we're talking about building things for end users. Expecting them to intuitively understand the assumptions we made and built into our solutions is crazy. In a very current example for me, customers interacting with an online ordering site do not think about the process of ordering pizza the same way an engineer designing that site does. They don't care how hard it is to map out a delivery zone or to figure out which is the optimal location to pick up from. They just want to type in their address and have it magically appear.
So I'm pleading with you. Don't abstract away the fact that we deal with messy, irrational, and unpredictable people every day. It'll help us make better decisions and besides - it's what keeps things interesting.
I can't stand it.
Firstly, it just sounds ridiculous. "I've got some resources on my team which would be valuable on this project" is something I heard often during my tenure in a huge, corporate IT department. It's borderline offensive. How about "Steve is a rockstar developer who really understands the framework you're proposing to use. He might be a huge help." It's just so much more human.
Secondly, it puts us in a terrible mindframe. If people are just cogs in a machine, we're biased toward thinking that they'll simply just behave rationally and predictably. This couldn't be further from the truth, particularly when we're talking about building things for end users. Expecting them to intuitively understand the assumptions we made and built into our solutions is crazy. In a very current example for me, customers interacting with an online ordering site do not think about the process of ordering pizza the same way an engineer designing that site does. They don't care how hard it is to map out a delivery zone or to figure out which is the optimal location to pick up from. They just want to type in their address and have it magically appear.
So I'm pleading with you. Don't abstract away the fact that we deal with messy, irrational, and unpredictable people every day. It'll help us make better decisions and besides - it's what keeps things interesting.
Monday, March 14, 2011
High Order Goals
In clearing out some of my old documents, I re-discovered something I'd written about a year in to my current job (July of 2005.) The staying power of these goals was pretty solid, so I figured they'd make a good post.
This job is really about just a few things.
Automation
The whole reason that we have computers in the work environment is to do things that we either can do, but are a waste of time or just can't do all that well. One of the focuses of an IT department should be to automate away just about all of those tasks. Over time, things that are a pain in the ass to do should just be delegated down to the computers. Little bits and pieces of everyone's jobs should get easier, bit by bit.
Innovation
It's like automation taken to the next level - instead of re-inventing the wheel, or borrowing the idea of the wheel from someone else, it's inventing the wheel. These ideas and these applications make a competitive difference for the organization. They differentiate us in some way from our competitors.
Education
Technology is great, but it's pretty worthless unless people actually know what to do with it.
Maintenance
This is the not-so glamorous part of IT. It's absolutely got to get done, but it's not where the glory is. Automation can help this get easier, but it won't ever go away entirely. This is where a good portion of the short-term work lies, but it's a hindrance to getting the other work done. So this is where it makes sense to divide an
Tuesday, July 6, 2010
Coupons in Web 2.0
As the "great recession" either lumbers on or quietly gives way to economic recovery, the proliferation of Web 2.0 sites which provide information to their user base about every offer or coupon code in existence on the web has forced us (and presumably other businesses) to rethink some of our marketing strategy. In my opinion, it's safe to assume that any general offer you send out to your email list, or otherwise communicate in a limited fashion will show up on CouponCabin, RetailMeNot, SlickDeals, Deals.Woot or their counterparts for the whole deal-obsessed portion of the consumer market to see in a few hours.
Of course smarter technology can let you limit these offers with unique discount codes or business rules enforced in your ecommerce platform, but generally should you? There are a handful of sites out there with highly dedicated audiences who may be exposed to your brand for the first time through one of your discounts. (Think Groupon without the restrictions and outrageous cut of your sales.)
Subscribe to:
Posts (Atom)