Boulder Startup Week

If you are into the tech scene in Boulder, Boulder Startup Week is a great set of events–it’s coming up May 15-19 this year.  This is a totally volunteer run set of events which highlight various aspects of startup and technology in the Boulder area.  You can learn more at the website.  It’s a great place to network and to learn about new things.

I’m lucky enough to be participating in two events this startup week.  I’ll be hanging out at the Engineering Leadership dinner.  And I’ll be presenting on bootstrapping a startup as a developer with a few other bootstrappers.  Most of my short presentation will cover lessons I’ve learned from joining The Food Corridor.  I’m especially looking forward to hearing about Brian and Inversoft that day, because I’ve been friends with him for a number of years and have followed along with some of his trials and triumphs.

Hope to see you there!


The Four Types of Slacks

I have been using slack for a few years now, but have really noticed an uptick in the last year or so.  (If you aren’t familiar with slack, here’s an intro to slack usage, and if you are, here’s a great code of conduct for public slacks.)
It seems to me that there are four main types of slack groups.

The first is the company/department slack.  This slack is long lived, contains many channels, and is multi purpose.  There are channels for ops, marketing, etc.  This slack is typically limited to the employees of a company, though contractors are also given access.  The main purposes of this slack are an ad-hoc knowledge base and to reduce email.  Depending on IT, this slack may be under the radar and compete with other solutions like hipchat, wikis or internal mailing lists.

The next type is a project slack. This is related to the company slack, but is less long lived, and has fewer members and channels.  It is used for coordination amongst disparate people, often a set of contractors.  May be maintained by the client or prime contractor, also serves as an ad-hoc knowledge base, but is primarily a means for coordination of effort.

Both of the above slacks may have other integrations with systems (CI/CD, monitoring, etc).  These integrations with external systems can make the slack a one stop shop for corporate knowledge and memory, especially if the members are on paid accounts.

The above types are obviously limited in membership.  The next two types of slacks are more public.

Another type of slack is the event slack.  This slack replaces or augments Twitter as a way for people at a conference to communicate.  May exist between events, but is quiescent while events are not happening.  Here channels may be related to aspects of the event or tracks, and the slack is typically owned by the event coordinator and provided as a service to the conference attendees.

Slack can also be an email list replacement.  I have been a member of several email lists for user groups/meetups in the front range, and it serms much of the activity on some of them have been driven to slack (the BDNT meetup is a good example). In addition, I see a lot of new slacks being created that would, a decade ago been email groups.  (Facebook groups are also a replacement for email groups, depending on your audience, but I have found slack to be far superior in searchability.). The number of channels is typically related to member list size and length of existence.  I have found these slacks be on the free slack plan, with its limits. I have also heard of slacks of this type charging for membership.

What has been your slack experience?  What did I miss?


Bare minimum of ops tasks for heroku

Awesome, you are a CTO or founding engineer of a newborn startup.  You have an web app up on Heroku and someone is paying you money for it!  Nice job.

Now, you need to think about supporting it.  Heroku makes things way easier (no racking and stacking, no purchasing hardware, no configuring apache) but you still to set up some operations

Here is the bare minimum you need to do to make sure you can sleep at night.  (Based on a couple of years of heroku projects, and being really really cheap.)

  • Have a staging environment
    • You don’t want to push code direct to prod, do you?
    • This can be a free dyno, depending on the complexity of your app.
    • Pipelines are nice, as is preboot.
    • Cost: free
  • Have a one line deploy.
    • Or, if you like CD/CI, an automatic deploy or a one click deploy.  But make it really easy to deploy.
    • Have a deploy script that goes straight to production for emergencies.
    • Cost: free
  •  Backups
    • User data.  If you aren’t using a shared object store like S3, make sure you are doing a backup.
    • Database.  Both heroku postgresql and amazon RDS have point and click solutions.  All you have to do is set them up.  (Test them, at least once.)
    • Cost: freeish, depending on the solution.  But, user data is worth spending money on.
  • Alerting
    • Heroku has options if you are running professional dynos.
    • Uptimerobot is a great free third party service that will check ports every 5 minutes and has a variety of alert options.  If you want SMS, you have to pay for it, but it’s not outrageous.
    • Cost: free
  • Logging
    • Use a logging framework (like slf4j or the rails logger, and mark error conditions with a string that will be easy to search for.
    • Yes, you can use heroku logs but having a log management solution will make you much happier.  Plus, it’s free for 2 days of logfiles.
    • Set up alerts with papertrail as well.  These can be more granular.
    • Cost: free
  • Create a list of third party dependencies.
    • Sign up for status alerts from these.  If you have pro slack, you can have them push an email to a channel.  If you don’t, create an alias that receives them.  You want to be the person that tells your clients about outages, not the other way around.
    • Cost: free
  • Communication
    • Internal
      • a devops_alert slack channel is my preferred solutions.  All deploys and other alerts go there.
    • External
      • create a mailing list for your clients so you can inform them of issues easily.  Google groups is fine.  Don’t use an alias in your email–you’ll forget to add new clients.
      • do not use this mailing list for marketing purposes.
      • do make sure when you gain or lose clients you keep this up to date
    • Run through a disaster in your mind and make notes on how you would communicate the issue, both internally and externally.  How often do you update your team?  How often do you update your clients?  What about an internal issue (some of your code screwed up) vs an external issue.  This doesn’t need to be exhaustive, but thinking about it ahead of time and making some notes will help you in the crisis.
    • Cost: free

All of this is probably a four hour project, max.

But once this is done, you’ll rest easier at night, knowing you have what you need to troubleshoot and recover from production issues.


Machine sympathy vs human constraint

I had beers with an work acquaintance recently. He’s a developer of a large system that helps contact management. Talk turned, as it so often does in these situations, to the automation of development work. We both were of the opinion that it was far far in the future. This was three whole decades of experience talking, right? And of course, we weren’t talking our book–ha ha. I’m sure that artisan weavers in the 1800s were positive that their bespoke designs and craftmanship would mean full employment no matter what kind of looms were developed.

But seriously, we each had an independent reason for thinking that software development would not be fully automated anytime soon.

My reason:

It’s very hard to fully think through all the edge cases of development. This includes failure states, exceptional conditions, and just plain human idiosyncrasies. Yes, this is what every system must do. That’s right. Anything you want handled by an automated system has two options: plan for every detail or bump exceptional cases up to human beings to make judgements. The former requires a lot of planning and exercising the system, while the latter slows the system down and introduces labor costs into the mix.

This system definition is hard to do and hard to automate. I’ve seen at least five new languages/IDEs/software platforms over the years that claimed to allow a normal human being to build such robust automatic systems, but they all seem to fail in the short term. I believe that is because normal human beings just don’t think through edge cases, but those edge cases are a key part of software.

His reason:

When systems reach a certain size, abstractions fail (I commented about this years and years ago). Different size, different failures. But just as an experienced car mechanic knows what kind of system failures are likely under what conditions, experienced software engineers, especially those who understand first principles, have insight into these failures. This intution (he called it “machine sympathy”) is something that can only be acquired by experience, and, by its very nature, can’t be automated. The systems are so complex and the layers so deep that every failure is likely to be unique in some manner.

So, which one is more likely to remain a relevant issue. It depends on the organization and system size. Moore’s law (and all the corollaries for other pieces of software systems) works both for and against machine sympathy. For, because, as hardware gets better, the chances of system breakdown decrease, and against, because as hardware gets better, larger and larger systems get more affordable. Whereas I believe the human constraint is ever present at all sizes of system (though less present in smaller ones where there is less concern about ‘bumping up’ issues to humans, or even just not handling edge cases at all).

What do you think?


The Trouble with Snapchat

I joined Snapchat a while ago. I found tremendous value in the snapstorms by Mark Suster. And some value in the chats from Justin Kan and Gary Vanyerchuk. I’m no Snapchat expert–never made a snap. Just followed people for their stories. But I was interested and was checking the app a couple times a day for a while.

Yet, now I deleted the app from my phone.

Why?

Because even though I was getting value from the media I was consuming, there were two major issues.

  • I couldn’t share a great snapchat. Other than suggesting “hey, why don’t you get on snapchat and follow this person because they are talking about lots of interesting things”, you can’t share the knowledge. I didn’t think that was very important until the fifth or sixth time I thought “geez, XXX would really enjoy this” and then realized I couldn’t share it with them and felt a twinge of annoyance. I miss having a universal resource locator that I can share as I please.
  • I couldn’t consume a snapchat when I wanted to. I often will email myself an article, or leave a tab open, or even post it to Twitter or Hacker News if I scan it and know I’d like to come back and read it more fully later. Even in my Twitter or Facebook feeds, I can scroll back years if I want to. Snapchat forces you to consume content on their schedule. And that gets frustrating.

I can see why both of these attributes good for content creators–they force the consumer to engage more. More on that here, from msuster. But this consumer is saying goodbye to Snapchat. At least until they give me URLs.


Gluecon 2015 takeaways

Is it too early to write a takeaway post before a conference is over? I hope not!

I’m definitely not trying to write an exhaustive overview of Gluecon 2015–for that, check out the agenda. For a flavor of the conversations, check out the twitter stream:


Here are some of my longer term takeaways:

  • Better not to try to attend every session. Make time to chat with random folks in the hallway, and to integrate other knowledge. I attended a bitcoin talk, then tried out the API. (I failed at it, but hey, it was fun to try.)
  • Talks on microservices were plentiful. Lots of challenges there, and the benefits were most clearly espoused by Adrian Cockroft: they make complexity explicit. But they aren’t a silver bullet and require a certain level of organizational and business model maturity before it makes sense.
  • Developer hiring is hard, and it will get worse before it gets better. Some solutions propose starting at the elementary school level with with tools like Scratch. I talked to a number of folks looking to hire, and at least one presenter mentioned that as well at the end of his talk. It’s not quite as bad as 2000 because the standards are still high, but I didn’t talk to anyone who said “we have all the developers we need”. Anecdata, indeed.
  • The Denver Boulder area is a small tech community–I had beers last night with two folks that were friends of friends, and both of them knew and were working with former colleagues of mine. Mind that when thinking of burning that bridge.

To conclude, I’m starting to see repeat folks at Gluecon and that’s exciting. It’s great to have such a thought provoking conference which looks at both the forest and the trees of large scale software development.



Denver Bootstrappers Lunch

boots photo

Photo by liftarn

My friend and former colleague Corey Snipes has been working to get a Bootstrapper’s meetup off the ground in Denver. This is a small group (limited to 12, I believe) of people who are building products (typically software) and self funding. I believe most of the members are in the solopreneur mode (I know Corey is).

I imagine this kind of support group would be fantastic–certainly I had a similar group when I was a consultant in the past, and bouncing ideas off of others in similar situations made the struggle much easier.

I’ve not made this meetup yet because, a) I’m not sure I’m bootstrapping (and you know what, if you aren’t sure you’re bootstrapping, you aren’t bootstrapping!), b) I live in Boulder and Boulderites have a hard time leaving the Boulder Bubble, and c) Wednesdays in general are tough days for me to do anything outside of the house.

If you are a bootstrapper in the Denver area, take a look.



Handling Bookings with Shopify

calendar photo

Photo by Michael McCarty

I am doing some research for a possible client engagement.  The client has invested in their Shopify storefront, and are extremely reluctant to move away from it.  Updated 8/27: the client is MM Local Foods, and the issue is with their Harvest Share.

However, a significant subset of orders placed through this system have ‘pickups’ associated with the order–these are events where the customer picks up the product.  There are multiple locations and multiple dates, and the customer can switch from one pickup to another at no cost.

Shopify, to put it mildly, doesn’t handle this use case well–it is about at easy to modify an order in Shopify as it is to read that Aztec calendar to your left.

Edit Order is the only Shopify app that I could find which will let anyone modify orders, and it has significant limitations:

  • only staff with access to /admin can modify orders.
  • it doesn’t actually modify an order.  Rather, it deletes an order and replaces it with a modified order (order #204 becomes order #204A).  This means you have to re-run the payment process.

I also looked at BookThatApp, which specifically handles ‘bookings’ within the Shopify framework, for services like tours or piano lessons.  Unfortunately, this service doesn’t let the customer reschedule the booking themselves (I asked BookThatApp support to be sure).

So, I spent a fair bit of time wandering the internet, looking for scheduling and booking SaaS apps that:

  1. had an API that could be integrated with Shopify
  2. would handle events at specific dates, times and places rather than letting the customer pick freely from from a weekly availability calendar (such as for piano lessons or massage appointments)
  3. let the customer modify their pickup without calling customer service
  4. looked professional
  5. wasn’t too expensive
  6. wasn’t too cumbersome to manage from the business side

The bad news is I didn’t find any software that fulfilled all requirements, even after hours of searching and signing up for about ten different applications (at least they all had free trials!).

I was astonished–was I not searching the right keywords?  Is this such a niche need?  A lot of scheduling software failed on criteria #2.  Eventbrite failed criteria #6 and #3.  Most booking software failed #5 and #3–which makes sense as they are aimed at tour companies who don’t want customers changing their tour dates without talking to someone.  I looked at some class scheduling software, but couldn’t figure out how to make it work.

The good news?  I found one solution that does almost everything above–it does fail criteria #1, but I think it is the best of the worst.  The other alternative is to write custom code, and that always worries me.

Why does writing custom code worry me?  One word: maintenance.  Especially for a small, non software focused business, maintenance of custom software is costly.  Instead, it is better to conform your business processes to the SaaS application which best fits them, and let someone else shoulder the burden of maintenance.  This is not always the case–sometimes needs are so precise and static that custom software is the right answer.  But my default is always to look for other solutions.

I’ve outlined some of the pros and cons to the customer and am waiting to hear back on how to move forward.

And if you know of any solutions that might be better options for this customer, I’d love to hear of them.



© Moore Consulting, 2003-2017 +