Skip to content

Are you working on the business or in the business?

Dog in a suitAs a business owner, it’s important to realize that the engine of the business (the people and processes that allow you to make the product or service, whatever that is) is as important, if not more so, than the product of the business. This changes over time, of course. When you are just starting out, the product needs to be made, otherwise you won’t have anything to sell. But over time, the other aspect, the business structure, will come to the fore. This is because as a business scales, you need to be able to recruit new talent, market your product, and spread knowledge throughout your company.

I was reminded of these facts by this post, “My Biggest Regret”, from Marty Haught, of Haught Codeworks. He’s kind of a big deal in the Ruby community, but reveals that he was a bit … lazy when it came to business development. From the post:

Apparently, I’m not the only one with this impression. You commonly hear that business owners need to work on the business, not in the business. I loved building software so much that I just wanted to stick with that.

That’s the perennial issue with building a business to give you freedom. Be aware that the bigger the business you build (the more successful) the more you’ll be taken away from building the product and the more you’ll be pushed toward building the business. (There are exceptions, but they require a certain scale. I’m aware of a couple of technical founders who stepped away from business management and focused on development/new initiatives, but that’s rare enough that it is worth commenting on and it also requires a team of about double digit size and margins to allow that to happen.)

The business principles of the solo consultant apply to big companies too. Doing the work is only part of building a business. Ignore that fact at your peril.

Business | moore | | Leave a comment

Fun with golang

Prairie Dog
Yes, it’s not a gopher, but they are related.

I’m writing a small piece of work in golang. It’s been fun to learn a new language. Initial thoughts:

  • I love the strict compiler. It saved me from making some dumb mistakes. It’s annoying at times (when you are cleaning up after println debugging you have to remove the log import statement).
  • I love that go fmt is built right into the language. No more formatting wars.
  • The standard library has some testing support but it’s pretty primitive.
  • It was weird that you have way to mark methods as private.
  • I did a small bit of concurrency work and go seems like a great fit for that.
  • The docs are great. I spent a lot of time on the Tour and the API docs.
  • The name is too general, but when googling, I was able to search for ‘golang’ and retrieve good results.

I have a few friends that rave about go. I can see why.

Programming | moore | | Leave a comment

Podcast Pick: A16z

I have been enjoying the A16z podcast for the last couple of years. It’s regular, dense content on a wildly varying set of technical subjects. I love hearing Benedict Evans talk about, well, anything–I find him quite insightful. But the podcast is not so dense I can’t listen to it on 1.4x speed.

I tend to listen to the more software specific episodes on APIs and on B2B2C business models (which seems to have been deleted). But every so often it’s nice to be jarred out of my world and listen to an episode about product or space or investing.

You can listen to past episodes here and get the RSS feed here.

 

Business Podcast | moore | | Leave a comment

AWS documentation now open source and on Github

TypewriterThis was announced recently. The AWS docs are now available on Github for everyone to review and improve. I love documentation (have for years). I think it’s great that AWS is now allowing PRs against their documentation. Some products have not yet uploaded their docs, ahem. It can only improve the speed of change.

I think it will also give a good glimpse into usage stats of AWS services. If a service doesn’t have any PRs or issues opened, it’s unlikely to be widely used (or, alternatively, it could be totally stable, or have users that don’t use Github). It’d be a fun project to pull the number of contributions to these repos via the Github API and publish that data.

I still feel that guides like og-aws have a place in the world of AWS documentation–opinions and real world stories fit better there than they do in official AWS documentation. And this is still too new to know if PRs and fixes will be pulled into the docs in a timely manner. But it’s great to see the AWS teams experimenting with ways to improve their documentation at scale.

AWS | moore | | Leave a comment

Useful Tool: Intercom

Intercom In WallIntercom has been extremely helpful in allowing targeted messages to help users gain knowledge of The Food Corridor application. (Thanks for the recommendation, OTL!) What I’ve found most useful about Intercom is that it allows non technical users to build rulesets to target specific messages. This helps you help your users uncover new functionality, but only at the moment when the functionality is useful.

For example, if someone has signed up but not created a booking in TFC, we can send them a message a week after they sign up with a helpful link. This message can be via email or an in-app message, and if they respond to the in-app message, it notifies customer support just as if a chat was started any other way.

As a developer, all I had to do to get this data (which lives in our database) up to Intercom was to craft a javascript object. I added a method in the application_controller and have it cached for a while, because we ended up sending dozens of attributes up, and they are slow changing. From then on, the message targeting is done entirely within Intercom, where the non technical user can build rules based on this custom data plus any data that Intercom collects by default (last login, etc).

If you do want to target messages specific web pages (only pop up a message on page XXX, but not page YYY) you need an understanding of regular expressions. Depending on how comfortable your non technical users are and how complicated your site is, a developer may need to write the first regular expression and then have the other users extend it.

I’m skipping over other pieces of Intercom, including a knowledge base and in app synchronous chat. I think those are valuable as well, but the real win for me was allowing non technical users to control in app messaging with minimal software development investment.

Useful Tools Web Applications | moore | | Leave a comment

Heroku and SSL

Heroku is a great hosting platform. Using it lets you focus on your application and not worry about operations tasks that might otherwise take developer time. Tasks like updating the operating system, patching the web server, and configuring third party services like monitoring. There are limits of course–once you reach a certain size it can be pricey. And if you have a app that has special requirements (example here), you might have to jump through some hoops. But if you are building a typical web app backed by a relational database, I’d highly recommend Heroku.

SSL is the technology which ensures that data sent over the web is transmitted untampered. Heroku has a number of offerings helping to make SSL easier to install; here’s a page to help you decide between the offerings. Last year Heroku announced support for free, automatically renewable SSL certificates. It does have some limits (no wildcard support, for example).

I just finished updating our system from an older SSL solution to the automated certificate management offering. Other than a slight hiccup around DNS being set up incorrectly by me (quickly fixed after a helpful answer from Heroku support), this update went swimmingly. Now rather than having to deal with SSL updates once a year (reviewing my notes, googling around and paying for a third party certificate), the SSL certificate is updated automatically.

This is just another example of Heroku taking something that is key to operating a web application and making it trivial. What a relief.

Devops | moore | | Leave a comment

Pact Testing

PadlockI attended the Google Developer Group meetup last week and enjoyed many of the talks. It was a lightning session, so there were ten speakers. In particular I really enjoyed “Pact Contract Testing” by Claire Chen. The idea behind Pact Testing, which has been around since 2013 and has had four major specification releases, is to formalize the contract between an API consumer and producer and allow each side of the API conversation to be developed independently. You can record the interactions between each consumer and producer and re-play them during testing to verify that no regressions have occurred. It’s really designed for a situation where you control both the consumer and the producer and want to verify that there are no breaking changes when either of them evolve.

So, this seems like mocks and stubs on steroids with the additional benefit of being cross platform (many languages are supported) and exercising the entire producer or consumer independently. You can also run an external server to maintain all the pacts independently.

If you are running a microservices architecture, I’d strongly recommend taking a look at this. Next time I’m involved in an API consumer/producer project, I’ll definitely be using this, and will report back then.

See also “convince me that Pact Testing is a good idea” and “what is Pact not good for?”.

APIs Testing | moore |

Departing The Food Corridor

Life is full of endings as well as beginnings. It’s easy to celebrate the latter, but the former are just as important. I joined The Food Corridor just about two years ago. This Friday is my last full day with the company. The company is left in very capable hands and has some exciting new plans. I look forward to cheering their success from the sidelines.

I am a firm believer in saying thank you, so I’d like to give some thanks to folks who have helped me out on my TFC journey.

The customers: Like any startup, we had to search to find our niche (“ideas are nice, but execution is a bitch”). But I’m glad to have been able to help shared use kitchens “spend less time in the office and more time in the kitchen”. What great people. They are working every day to help their clients (food businesses) build sustainable economic businesses. I learned so much and have a tremendous appreciation for the economic, regulatory and every day challenges kitchen managers face. Our clients were also forgiving of my mistakes, especially around matters of money and user experience. I appreciate their trust and patience.

The investors: A number of Colorado based angels and funds took a chance on TFC. Thanks for the rigor of your due diligence, the support you gave, and of course for the cash that is helping take TFC to the next level. But thank you most of all for your belief.

The informal advisors: TFC had a tremendous crew of folks helping out in many many ways with advice and connections and cheerleading. You all know who you are, and I appreciate every minute you gave to help TFC get where it is.

The formal advisors: We had a number of advisors who took hours and days out of their busy schedule to help out a newbie company, whether by reviewing documents, spending time at an all hands or investing. Thank you Christine, David and Mick.

The team: Small, nimble and potent. I learned something from each and every one of you. Charlie, thank you for the dashboard concept and your time. Lindsay, thank you for volunteering your time to make TFC better, and to help me see the system in new ways. Stephanie, I appreciated your questions and willingness to try new things and I’m so glad you found the right spot for you. Julie, I appreciated your focus on process and customer support. Chad, thanks for making those cold calls. Ben, thank you for your financial rigor and patience, as well as the ‘bigco’ perspective. Jim, Marcus and Joe, thank you for your early support and enthusiasm. Rachael, thank you for your good humor, food business perspective and constant attention to the TFC public image. Meghan, thanks for your attention to detail, your humor, your endless drive to get it right, and of course for your wicked intercom chops. Nenad, Luka, Michael, Seamus and Luciano, thank you for relentlessly putting the customer exactly where they should be–front and center. (If I failed to mention anyone above, please accept my apologies.)

My co-founder: Ashley, I wish you (aided by the TFC team and support system, of course) all the best in taking TFC to the heights I know it can achieve. Thank you so very much for the opportunity to hike alongside while I was able.

My wife: I can’t imagine pursuing any startup without the support of my spouse. The journey is crushing at times even with enthusiastic help. She’s been a sounding board, supporter, cheerleader and true believer. Thank you so much.

The Food Corridor | moore | | Leave a comment

The joy of removing code

I am working on a project right now where my main task is to remove code. “What? I thought developers were supposed to add code, not remove it?” Well in some cases removing code actually can help a project. Some reasons to remove code: if the code doesn’t serve any purpose, if it isn’t executed, if it is for an edge case that never happens, if it has been superseded.

Removing code is easier with automated tests, but I still find myself using a combination of automated tests, manual testing, and the find command. (This codebase is ruby, if I was using java I’d use the type system.) It’s painstaking work, but will be good in the end.

My steps for removing code:

  • Start with a plan and and end goal in mind. Otherwise it can get overwhelming if you are dealing with a system of any size.
  • Create a feature branch
  • Identify one piece of code you’re going to either remove or keep
  • Make sure you know where it is called. If it isn’t called anywhere, remove it.
  • Remove any tests and associated functionality (views, helpers, etc).
  • Examine any state managed by the code for removal (database tables, etc)
    • Oftentimes I’ll just note that this should be removed in a few months, and focus on hiding the UX. It’s a lot easier to resurrect UX if you make a mistake than it is a dropped database table.
  • Commit the changes with a good commit message.
  • Fan out from there and see if you need to add anything to your list.

Take your time, don’t rush it.

Code that never runs can’t have any bugs, and is super fast. Think about removing some code today.

Dynamic Languages Programming | moore | | Leave a comment

A follow up to “Deeply problematic but practical advice”

I linked to the first article Charity wrote, and wanted to link to her follow on piece/”post mortem”. (In technical terms, a post mortem is an examination of a problem or system failure in hopes of avoiding the situation in the future.) From the post, she encountered some very harsh words from the Internet:

I have never received textual scrutiny of this type before, where every single word was turned over and macerated and peered at for evidence of traitorous views. It sucks.

Lots of good stuff there about the reactions to her original post, her takeaways and how she would do some things differently next time. Worth the read.

Business Technology and Society | moore | | Leave a comment