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.)
Monday, June 7, 2010
Damn You Snow Leopard...
We recently finished our upgrade to Exchange 2010, which set off a chain reaction of events that destroyed my development environment. I had been using IMAP to connect Apple's mail client to our Exchange 2003 server. IMAP is turned off by default in Exchange 2010, and Snow Leopard supports natively connecting to Exchange. As such, I thought it was a perfectly good excuse to upgrade from Leopard. This was not a great idea.
Apple bundles an update version of Ruby (1.8.7) with Snow Leopard, which clobbered the rather messy development stack I'd been running on my laptop. (Having started really working with Ruby and Rails back when you had to run everything in Webrick, moving to nginx, mongrel clusters, and finally settling on passenger over a span of at least a few ruby and rails versions, it was rather fragile.
I spent somewhere on the order of 8-10 solid hours trying to fix it. (Installed RVM in the hopes that I'd get some help from a clean version of Ruby. Nope. Rebuilt almost everything. Nope.) Ultimately I decided it would likely be easier to start over with a fresh install of Snow Leopard on a blank drive and rebuild a clean stack from scratch.
So here's what I ultimately ended up doing. (Note that this would be what you need to do in order to get started with Rails on Snow Leopard. I'll add command line snippets shortly, but most of this is pretty straightforward stuff.)
- Back up everything to a time machine drive
- Insert the Snow Leopard DVD
- Boot up for an installation
- Use disk utility to wipe my hard drive (scary.)
- Reinstall a clean version of Snow Leopard
- Install XCode from the "Optional Installs" on the Snow Leopard DVD
- Update Rubygems
- Download and install MySQL binary
- Create .profile and add /usr/local/bin to my path
- Install the mysql gem with 64 bit archflags directive
- Install rails 2.3.
- Install the passenger gem
- Configure passenger [sudo passenger install-apache2-module]
- Install the passenger preference pane
- Success!!
Monday, May 3, 2010
Rework
I got my copy of "Rework" by the 37signals guys today - just in time to take it on the plane with me to Buenos Aires! I'm exited to read the latest by David + Jason.
Thursday, April 29, 2010
Setting User Expectations
We are currently nearing the end of a few day process to transition our email server from Exchange 2003 to Exchange 2010 and it's gone relatively well from an end-user upset perspective. (The rationale behind staying with on-site Exchange instead of moving to the cloud will follow in a separate post.)
I have it easier than many because my "customers" are generally the employees of our company, so it's easier to set and manage their expectations. Regardless, it still needs to be handled delicately to minimize their upset and resistance to change.
I think a few key factors really helped in the process
- (Self evident) Let everyone know what to expect out of their experience during the transition
- (Self evident) Work around the customer's schedule. In practice this meant scheduling downtime for our 9 to 5 employees from 8pm to 6am and scheduling downtime for restaurant managers from about 2am until 8am
- Be honest about the fact that you'll run in to problems and fix them immediately
Finally, I have to give Microsoft props for ensuring that Outlook 2007 will automatically recognize the new 2010 server without any user action. For our office users, this should make the transition go essentially unnoticed.
Sunday, February 28, 2010
Schedules
I used to go by the mantra that schedules were bullshit. I wouldn't give people deadlines or commit to them unless I knew we could deliver something on time.
However, I've revised my stance: schedules are just a guess. We can learn a bit about how long it takes us to write a given type of app and make slightly better guesses in the future.
So why make a schedule at all? Communication. If the other department heads who rely on my team for both day to day and project support don't have a clue what I'm working on, it's hard for them to understand why I'm not working on whatever they need. A schedule helps to explain why everything can't be done for everyone all at one.
Tuesday, October 27, 2009
Scaling Rails
One of the guys on my team (our staff developer) and I went to an event this morning put on by EngineYard and a few of their partners this morning. The content was pretty informative, albeit a little on the salesy side. The content mostly focused on EngineYard's new cloud product and how easy it is to provision servers.
EngineYard's CTO said something which seemed rather poignant: The demo environment they were using during the presentation (which consisted of three Amazon EC2 instances: two app servers and a database server) should be sufficient to host about 99% of all rails applications on the internet at this point.
That's absolutely insane. The hard costs for the infrastructure of a web-based startup are crazy cheap.
EngineYard's CTO said something which seemed rather poignant: The demo environment they were using during the presentation (which consisted of three Amazon EC2 instances: two app servers and a database server) should be sufficient to host about 99% of all rails applications on the internet at this point.
That's absolutely insane. The hard costs for the infrastructure of a web-based startup are crazy cheap.
Thursday, July 16, 2009
Friday, July 10, 2009
Why oh why Microsoft?
Seriously. WTF?
We just set up a Windows Server 2008 virtual machine for deployment of our Catering management application. It wasn't responding when I tried to use Remote Desktop to manage it, so my first inclination was to ping the machine to see if it was up. That didn't work, so I opened up the VMWare Infrastructure console, booted it up and tried pinging it again.
Still no dice.
So, I logged in through VMWare and checked that the IP address of the machine was configured correctly. Check.
Still no ping.
Next, I made sure I could ping out and connect to the rest of the network from that machine. Check.
So I'm now thinking it's that pesky Windows firewall again. However, the imcp / ping settings aren't there either, but there is a little link to windows help. I'm on the right track. Yaaay.
However, the little article isn't horribly descriptive and points me to the "Windows Firewall with Advanced Security" Microsoft Management Console snap-in. Great.
Open that up, look around, still can't find anything about imcp under "Core Network" section.
Hello Google. I am angry. Please help me.
I find this helpful article : http://www.petri.co.il/enable-ping-windows-2008-server.htm
The instructions prove helpful and I now have a server which will respond to a ping, but really? Why the f*** is the ping setting buried in a "File and Print Services" heading? Who thinks to themselves "I want to make a server respond to pings. That means I should think about print services!"
We just set up a Windows Server 2008 virtual machine for deployment of our Catering management application. It wasn't responding when I tried to use Remote Desktop to manage it, so my first inclination was to ping the machine to see if it was up. That didn't work, so I opened up the VMWare Infrastructure console, booted it up and tried pinging it again.
Still no dice.
So, I logged in through VMWare and checked that the IP address of the machine was configured correctly. Check.
Still no ping.
Next, I made sure I could ping out and connect to the rest of the network from that machine. Check.
So I'm now thinking it's that pesky Windows firewall again. However, the imcp / ping settings aren't there either, but there is a little link to windows help. I'm on the right track. Yaaay.
However, the little article isn't horribly descriptive and points me to the "Windows Firewall with Advanced Security" Microsoft Management Console snap-in. Great.
Open that up, look around, still can't find anything about imcp under "Core Network" section.
Hello Google. I am angry. Please help me.
I find this helpful article : http://www.petri.co.il/enable-ping-windows-2008-server.htm
The instructions prove helpful and I now have a server which will respond to a ping, but really? Why the f*** is the ping setting buried in a "File and Print Services" heading? Who thinks to themselves "I want to make a server respond to pings. That means I should think about print services!"
Tuesday, June 9, 2009
Business Email Style Guide (pt 1)
I am a huge fan of using email to get things done. However, the way in which some people use it bugs the crap out of me. It's entirely possible that I'm just more anal than most, but there are some simple rules which I think bear restating:
- I don't care that you're not writing a formal letter. Using bad grammar, stupid abbreviations (such as "thanx") or incomplete sentences all make you sound like an idiot. I don't want to read your email and will probably discount whatever you have to say in it if I think you sound stupid.
- Email is a wonderful mode of communication for a few things: quick thoughts or requests, formal communication where it's important to be able to refer back to what was said at a later date and asynchronous communication amongst others.
- Email is not a good tool when a discussion about something simple drags on for more than two emails in either direction. Did everyone forget about their phones with the advent of crackberries?
- Make whatever point you're trying to make clearly and quickly. You're not writing a novel. (Or even a short story.)
- Before you carbon copy anyone, seriously consider whether they need to get whatever it is that you're about to send them. It's one of my pet peeves to get an email which I don't really care to read just because someone thinks they need to "keep me in the loop," or to receive an email with other people cc'd for the same reason.
- Contrary to what some other folks preach, courtesy thank you and you're welcome emails are just fine.
- Lastly, please don't ever send anyone an email from your smartphone which serves little to no purpose. My very informal observation is that people tend use such devices to communicate more frequently and faster, but with far less valuable thoughts than they would otherwise.
Friday, April 3, 2009
Databases
So I'm sitting here, having spent more time than I'd like to admit trying to get at some data in the application we use to manage our catering service sporadically over the course of the past two days. My plan was to simply install an odbc driver, fire up a data transformation services package and to dump everything into a mysql database. However, this has proved not to be quite the trivial task I anticipated.
This brings me back to a question I ask myself fairly regularly: Why oh why on earth does anybody use databases other than the big boys or something open source?
I know that some apps are tied to bad legacy choices, but I still don't get it. This particular application "upgraded" to Sybase's Advantage database server. I say "upgraded" because it seems like a very bad choice to me. Here's why:
This brings me back to a question I ask myself fairly regularly: Why oh why on earth does anybody use databases other than the big boys or something open source?
I know that some apps are tied to bad legacy choices, but I still don't get it. This particular application "upgraded" to Sybase's Advantage database server. I say "upgraded" because it seems like a very bad choice to me. Here's why:
- It probably cost them some money to buy the developer's license and it definitely cost me money as the customer. Mysql is free. Across the board.
- Although Sybase has odbc drivers, mysql does too. And they work better with everything I screwed with today. (SQL server dts, access - eww, crystal reports - eww.)
- What's up with this "data dictionary" nonsense? Can't you just give me a host name and credentials to connect to? I don't get that one either.
Friday, October 26, 2007
Overzealous Windows Security
Here's a great one from Microsoft...
I was just trying to install an application onto a server running Windows 2003 R2 which I haven't installed anything onto in a while. The installer is on a share on another machine and I kept getting an error that said "Windows cannot access the specified device, path, or file"... when I tried to run it.
After poking around and noticing that I could in fact open up a plain text file on the same share I realized it was probably the newer security settings in i.e. 7. So just adding the share to the "Trusted Sites" list in file:// protocol took care of the problem.
But why couldn't Server 2003 have just given me a more informative error message?
I was just trying to install an application onto a server running Windows 2003 R2 which I haven't installed anything onto in a while. The installer is on a share on another machine and I kept getting an error that said "Windows cannot access the specified device, path, or file"... when I tried to run it.
After poking around and noticing that I could in fact open up a plain text file on the same share I realized it was probably the newer security settings in i.e. 7. So just adding the share to the "Trusted Sites" list in file:// protocol took care of the problem.
But why couldn't Server 2003 have just given me a more informative error message?
Subscribe to:
Posts (Atom)