Skip to content

Monthly Archives: February 2018

CircleCI shutting down version 1.0

I’ve been a happy user of CircleCI at multiple companies. Right now we pay them at The Food Corridor and they handle almost all our deployments. (I still deploy to production manually.)

We just got a note that they are shutting down their 1.0 offering and will not support it as of Aug 2018. The 2.0 offering was announced in 2016 and generally available in 2017. So, there will be about one year of overlap. Not too long.

I understand that desire to move forward.Trust me, I do.

I don’t know how much engineering effort it takes to support the two versions, but my guess is that they’ll see some significant customer loss from this. Why? CI is something that you just want to work. You don’t want to think about it. Which is why a SaaS solution makes so much sense. I am happy to just keep paying them month after month for their excellent product.

But, if I have to take some cycles to move from CircleCI 1.0 to CircleCI 2.0, why wouldn’t I take some time and evaluate other solutions too? I assume they’ve run the numbers and the amount of money it takes to support 1.0 must be more than the amount they will lose via churn.

AWS does a good job of this–they never deprecate anything (you can still set up SimpleDB if you want). They just hide it, make other offerings better, and make older offerings more expensive.

In fact, if I were CircleCI, I might offer a ‘legacy’ CircleCI 1.0 plan, where people with significant investments in the older infrastructure can pay more for access to that old codebase. Depending on the amount of support required, that might be some significant free money.

Relatedly, Amy Hoy has a great post on how to get your customers to pay you more money.

Look for the value of the param, not its existence

We are rewriting the front end of the application on which I work. Several of the forms which gather data that drives the application previously had checkboxes, which would set a value to true or false in the database.

Some of the checkboxes were ancillary, however, and didn’t result in a database value. Instead, they were used to calculate a different result depending on whether the checkbox was checked or not. That result would then be saved to the database. This was all tested via rspec controller tests.

In at least one case, the calculation depended on the existence of the parameter. Checkbox parameters are sent when they are checked and omitted when they are not.

Then we changed the forms to radio buttons.

Uh oh.

Instead of sending the parameter if the box was checked yes or not sending the parameter if it was checked no, we sent yes if the radio button was checked and no if it was not.

Uh oh.

The tests continued to pass, because they hadn’t been updated to the new values.

Uh oh.

So the calculation was incorrect. Which meant that the functionality that depended on the calculation was incorrect. Unfortunately, that functionality was related to billing. So I just spent the last few days backing that out, checking with clients to see what they actually intended to do, and in general fixing the issue.

The underlying code was an easy enough fix, but this story just goes to show that software is complicated. Lessons learned:

  • favor a test for an exact parameter value rather than parameter existence
  • when changing forms, consider writing tests with the new input values
  • integration tests that drive a browser would have caught this issue. These are much slower so need to be used judiciously, but are still a valuable automated test

 

Coding tests for interviews

Ahmed Fasih posted his proposed alternative to a HackerRank pre-interview test. This sparked comments in the HN discussion.

I think it is worth approaching these kinds of tests from both sides, as this topic has come up a lot in some email lists of which I am a member.

As an employee, you want to be assured of the best chance of finding a job that is a good fit, and of minimizing the time spent to apply to each job. You also want to maximize the number of jobs you get offered, so you have optionality (“well, I’d love to work for you, company XYZ, but I’m considering other offers and was wondering if you could give me more XXX” where XXX is whatever you desire, money, time off, health care, etc).

As so many employees say in the discussion, if you are a senior person, these kinds of tests can be a bit insulting and disconnected from the actual work. Who is going to transform a 2D array in their regular job? I’d reach for a library or stack overflow answer.

On the other hand, if you are at the point where you need to fill out an online test rather than talking directly to the hiring manager about how you can solve her pain points, maybe that’s a problem? LinkedIn is pretty magical in terms of finding this info out, though of course there may be corporate protocols that make this circumvention impossible.

As an employer you want to find the best person for the price in the shortest amount of time. Where best depends on the position, but is some mix of skills, culture fit, desire for the job, and perceived amount of time they’ll stay. You also want to be fair to all applicants and have some kind of apples to apples means of comparison.

As so many managers say in the discussion, these tests weed out folks who can’t code their way out of a paper bag. If you’re a senior engineer, you’ve probably worked with some folks like that, so you can see the need. They also do so relatively quickly and in a way that scales and is equitable across different candidates.

So, as a senior engineer, I’d:

  • seek employment where I could circumvent these types of tests through my network
  • avoid these types of employers unless it was a great job
  • if I had to take the test, try to have sympathy with the employer and take it as an opportunity to brush up on my algorithms

And if I were the employer, I’d think about these tests are a filter. Just like a GitHub profile, they’ll give you some information. Whether that information is relevant to the current candidate search, and is worth filtering out good candidates who don’t bother filling out tests, is an exercise left for the reader.

Software infrastructure configuration options

I ran across this great article when I was reading up on Terraform.

It does a good job of running through the options (puppet, cloudformation, etc) on how to set up your infrastructure via software. Here’s a great quote on why they chose Terraform:

On the other hand, with the kind of declarative approach used in Terraform, the code always represents the latest state of your infrastructure. At a glance, you can tell what’s currently deployed and how it’s configured, without having to worry about history or timing. This also makes it easy to create reusable code, as you don’t have to manually account for the current state of the world. Instead, you just focus on describing your desired state, and Terraform figures out how to get from one state to the other automatically.

Product Roadmapping For Team Alignment

One of the issues with a startup is that you have so many opportunities and so little time. This is overwhelming, and can lead you to pursue opportunities that fall in your lap, or that your squeaky wheel customers offer up, rather than thinking strategically about where you want to go and how best to get there. This is heightened by the ‘everything is on fire’ feeling that arises occasionally.

At The Food Corridor, we just spent two days roadmapping (we being The Food Corridor team and the OTL Ventures team). Normally I’m not a fan of meetings. I find they often are synchronous status information transfer that could be better handled via email or slack. As an aside, here is a great post on running a meeting.

But this roadmapping meeting was great. The team was all in the same room and spent the first day brainstorming opportunities (with no limits on the feasibility of the suggestions, but some guardrails around focus). The second day we ranked all opportunities according to positive impact and effort required (both in a number of dimensions). As you can imagine, these were two long days. However, the outcome is a list of high impact, low effort opportunities.

However, I feel the real value isn’t in the list, which will be so long that it won’t be accomplished in the next two years, let alone by the next roadmapping session is scheduled. There were two main items that came out that I found really valuable.

First, that were discussions with all relevant parties about real issues in the business. Sometimes we get so busy delivering that we don’t pop our heads up and see the bigger picture. As all imperfect products do, The Food Corridor causing some pain for our customers. (If you work on an imperfect product, please let me know as I’d love to see one.) These pain points were front and center during the discussion, and we had people from multiple different functional areas opine on the problem and possible solutions.

There was also a ton of value in creating shared alignment. As I watch this business be built I am astonished at how much time and effort needs to be spent making sure everyone is pulling in the same direction. When I ran a business on my own (as a solo consultant) or when I am an employee, the focus is usually on what I’m doing “in the business”–the day to day execution of tasks to provide the services the company sells. As a co-founder, I’m seeing how important it is to get everyone agreeing on the highest value opportunities–highest value for the business, not necessarily the most exciting or highest value for each individual. This alignment needs to happen with incentives, meetings and communication. The just completed roadmapping session felt like it really achieved that shared alignment.

By the way, if you are a software product company in the northern front range and feel like you could benefit from more team alignment, I’d highly recommend contacting the folks at OTL and pursuing this. Not affiliated, just a happy customer.

Metabase: An Easy Query Builder For Your RDBMS

If you have a relational database as the primary datastore for your application, and you want to easily allow non technical folks to build reports against data in that database, I highly recommend evaluating metabase. This open source query builder is dead simple to install (takes about one minute on a free heroku dyno). You can create individual users, and they all get access to an easy to use interface so they can look at data in your tables. All the nomenclature is non technical, nary a select, group by or from clause to be seen. It’s written in java, but you don’t have to know java to run it.

We haven’t used this for long, so I can’t talk much about the warts, but I was referred to this by someone else who had great success in using it in their organization. The only downside that I’ve seen so far is that joins are not supported, so you end up having to create views if your database is normalized. More on that decision.

Absence of evidence is not evidence of absence

I am on a mailing list of engineering leaders and someone mentioned that they have found Github to be a very good indicator of whether a candidate is a good choice for them.

Of course, every company will emphasize different aspects of software development–for some technical expertise is more important than communication, while others have that ranking flipped. Some may emphasize ability to work in large teams, while others may prefer folks who are self driven.

But I see a fair bit of emphasis on Github profiles, which makes sense–you can actually look at the code someone has written, and how they developed it.

But here are some reasons why someone might not have a stellar Github profile.  They might:

  • prefer to use bitbucket so their code is private
  • have a restrictive employment contract
  • not want to program when they go home
  • want to learn about software by experimenting on their local computer
  • learn about other aspects of software development by reading rather than doing
  • focus on answering questions on Stackoverflow
  • not have time to have anything on their profile due to other commitments

If someone has a great GH profile, that’s probably an indicator they are a good developer. But if they don’t (full disclosure, mine is kinda weak), that’s no indicator of anything other than that they haven’t made it a priority.

Do you need a mobile app? Probably not

This post from the folks at 18F does a great job of covering why you should default to a responsive web site rather than a native mobile app. While tools like cordova and react native decrease the effort required to build a native application, the ongoing maintenance costs shouldn’t be underestimated.  It is easier to outline the reasons why you should build a mobile application, because there are far more reasons why you should not. From the post I mentioned above:

  • extreme bandwidth constraints or offline operation
  • heavy use of sensors that are not web standards
  • third party interactions

I’d add:

  • branding needs, where you have a compelling application and expect to be be installed on the user’s home screen. Expect to spend $$$ on marketing the app
  • extreme performance. This might be graphics/video, battery or network performance

and, via twitterSara Bates added:

  • push notifications, (if used wisely)

If your application doesn’t meet these criteria, I’d think long and hard about launching with a native mobile application, and think about what you could do for your business with the extra budget.

You can likely prototype your app with a responsive website and then build a native mobile app when you know more and/or have user feedback. This can be a great way to economize, because you can leverage outsourced mobile app teams and point them at the prototype as a living requirements document.

When do you earn your pay?

I was driving today and saw a bus driving in the snow. I’ve never driven a bus, but I imagine that snowy days are some of the most difficult. The roads are bad. People are crabbier. Accidents happen. You are still on the hook for making the schedule. I’m no bus driver, but I bet when the driving is easy, as in the summer during off peak times, the job is easier.

However, when things get hard, that’s when you earn your pay. Since software development is such a sprawling occupation, it’s hard to generalize about the most difficult moments, but I can mention some of mine:

  • When I face a problem that you’ve never faced before and have no idea how to tackle it (like setting up recurring bookings over daylight savings time changes).
  • When I ship a bug that costs your customers money and I have to analyze how much money was lost and a game plan to fix the bug and get them their money. Then I need to contact the customers to apologize as well as let them know what the plan is.
  • When I realize I’ve chosen the wrong implementation for a component.
  • When I realize I’ve made an architectural decision which made sense in the moment but will have maintenance and performance costs down the line.
  • When the system crashes and I know the reason, but I haven’t figured out a way to replicate it or to fix the issue.
  • When a system is slow and I am unsure where to start looking.
  • When someone on my team isn’t working out and I need to let them go.
  • When I watch a user navigate around your system and totally miss features that will make their lives much easier.
  • When I join a new project/company/team and walk into an existing system of software and personalities about which I have very little clue. And yet I want to be effective and move things forward, but need to be patient.
  • When I argue with someone about the best way forward, and then my path isn’t chosen, and I have to support the plan that was chosen.
  • When I argue with someone about the best way forward, and then my path is chosen, and I have to work with people who disagreed and may not fully support the new plan.
  • When I am at the end of a project and I just want the damn thing done, and yet I have to maintain the same level of attention to detail that I had at the beginning when the idea was all new fresh and exciting.

You don’t earn your pay for the easy stuff. It’s when the going gets tough that you really earn your pay.