A First Look : Universal Track Manager

Today I’m announcing ‘a first look’ at my new Gem: Universal Track Manager. It’s an ambitious project that’s going to have nearly universal appeal and utility.

Visitors come to your site every day. Along with their visits, 4 key pieces of information come along for the ride:

— IP address
— browser name (which lets you infer operating system)
— UTMs showing if they clicked from another site, or if they came from online advertising (typically you can “auto-tag” your ad campaigns and your UTMs will be magically populated)
— Http referrer, which shows if they clicked directly from another site to your site (Even when no UTMs are set)

Universal Track Manager, a play-on-words that shares an acronym with “UTM Parameters,” is your one-stop shop to automatically pick up this information and stash it into your database. You can think of it like a built-in Google Analytics (without the fancy dashboard).

As if that weren’t ambitious enough, with a tiny bit of trickery I’m planning support for optional Viewport size (width X height), which can let you determine if the user is on a desktop or mobile browser. (coming soon)

I’m pleased to announce Version 0.0.3, the first version I’m dubbing as ‘public beta.’ Although this is production-quality code, it should be used with caution until it is no longer in BETA status. You are welcome to give it a whirl on your Rails projects today. With an easy 3-step installation into any Rails 4+ app and you can sit back and sweep up tracking info on your visitors.

*MOST* of the core functionality now works! This version 0.0.3 implements fully support for timestamping your visits, the user’s IP address and browser. Support for UTMs & HTTP referrer and more coming soon! If you are curious now’s a great time to try it out, please submit feedback via Github.


Github Repo

Rubygems page


Announcing Nonschema Migrations — NOW FOR RAILS 6!

Nonschema migrations version 5.0.0: RubyGems Page, GitHub page

Now compatible with Rails 6, nonschema_migrations is the best way to separate your schema changes from your data changes.

Want to run no-downtime deploys with data-only migrations? No problem.

Install it in your Rails app today to see what a difference data migrations can make.

Shout out to Mikls Fazekas who hails all the way from Gyenesdis, Hungary for the pull request for this release!


Jason FB’s 10 Magical Ruby Developer Tools

1. deivid-rodriguez/byebug
Byebug is a fantastic debugger available for Ruby 2 (and presumably above). Drop

gem ‘byebug’

into your Rails app Gemfile and bundle install. In either your test run or your development run, write


on a single line of your app and voila. When you hit that line, you will drop into the debugger.

If you’re not developing a Rails app, you can include ‘byebug’ at the top of your Ruby file.

Full docs here.

2. pretty print (pp)

Pretty print is one of my favorite introspection weapons to help see variables more clearly.

pretty print, which you write as pp, prints out your object with each attribute on its own line. Take for example this Spree::Country object, shown here on the Rails console without pretty print

2.4.6 :010 > x
=> #<Spree::Country id: 232, iso_name: “UNITED STATES”, iso: “US”, iso3: “USA”, name: “United States”, numcode: 840, states_required: true, updated_at: “2019-05-19 17:16:07”, zipcode_required: true>

Now, with pretty print, the same object is conveniently displayed with each attribute as its own line. This is invaluably helpful when you have deep nesting of objects.

2.4.6 :009 > pp x
id: 232,
iso_name: “UNITED STATES”,
iso: “US”,
iso3: “USA”,
name: “United States”,
numcode: 840,
states_required: true,
updated_at: Sun, 19 May 2019 17:16:07 UTC +00:00,
zipcode_required: true>

3. puts, .to_s, and inspect

OK, so we get a 3-in-1 here: When you call puts on an object, .to_s will be called and then output to your screen. So you should make your objects have a .to_s that is human readable, possibly even for use in, say, a drop-down menu or label. 

def class Person
 attr_accessor :first_name, :last_name

 def to_s
   “#{first_name} #{last_name}”

inspect, on the other hand, is specifically for developers. In this method, you would write out as much information as you the developer (or next developer) want to see, including the keys (ids) of your objects if those will be helpful:

def class Person
 attr_accessor :first_name, :last_name

 def inspect
   “Person id: #{id} – first: #{first_name}; last: #{last_name}”

Your objects should have both .to_s and .inspect on them, and you can try these universally named Ruby methods on other people’s objects to examine them. A well-formed codebase implements them or has helpful output for both of these.

4. .to_yaml
Pretty print’s cousin is the .to_yaml method, which will take your object and convert it into yaml. Take for example this arbitrary object, which you will notice contains a :ghi key that has a nested object as its value:

2.4.6 :023 > x= {abc: 1, def: 4, ghi: {ye: 6, nm: 3}}
=> {:abc=>1, :def=>4, :ghi=>{:ye=>6, :nm=>3}}
2.4.6 :024 > x
=> {:abc=>1, :def=>4, :ghi=>{:ye=>6, :nm=>3}}

.to_yaml on its own will produce a string that will output with newline characters, like so:

2.4.6 :025 > x.to_yaml
=> “-\n:abc: 1\n:def: 4\n:ghi:\n :ye: 6\n :nm: 3\n”

To make this more useful, try puts along with .to_yaml

2.4.6 :026 > puts x.to_yaml

:abc: 1
:def: 4
 :ye: 6
 :nm: 3

5. x.method(:_____).source_location

(where :_____ is name of the method — as a symbol — you are trying to search for)

OK, so the ultimate secret weapon of Ruby debugging is this little-known method that will magically — and I mean magically — tell you where a method was defined. That’s right, I mean the actual line number itself.

2.2.5 :002 > a.method(:hello)
=> #<Method: Apple(Thingy)#hello>
2.2.5 :003 > a.method(:hello).source_location
=> [“/Users/jason/Projects/nokogiri-playground/app/models/thingy.rb”, 2]

Look, ma, take a peek into my hard drive and you would find that the hello method is actually defined on the file at the full path /Users/jason/Projects/nokogiri-playground/app/models/thingy.rb on line 2.

Like magic it works for Rails and Gem code too, and is invaluable when you are ready to dive into the APIs you are working with.

6. x.methods
By default this method will return a list of all of the methods on an object. Watch out because you’ll get all the methods on the ancestor chain too.

In older versions of Ruby, you could use this method to examine the instance methods that were defined on this class only (excluding the ancestors), but unfortunately this no longer works.

If you pass this method false, like so:


…things get more interesting: then you get only the class methods defined on this object’s class itself. (Remember in Ruby class methods are defined with self.)

7. brunofacca/active-record-query-trace

An excellent gem that’s still a non-optional workhorse in my development practice – especially when debugging a legacy codebase. This gem will display for ALL of your SQL queries where in your Ruby or Gem code the active record update commands are coming from.

Follow the instructions in the Gem to create an initialize file and set it up. My only tip here that adds to the docs is that you’ll want to set the number of lines:

ActiveRecordQueryTrace.lines = 10

I find that when debugging a problem in my own Rails app I want this set to a lower number (like 5 or 10) and when debugging a problem in Gem code or in Rails I need this at a much higher number (like 50 or 100).

8. flyerhzm/bullet

Understanding N+1 queries is a significant litmus test that sets amateurs from the professionals. Bullet is like a magic bullet – literally named so – for finding your N+1 queries.

Bullet is a great gem that you should install in either development or test, not in production. Often because it does add overhead to your speed, I install it but leave it configured so that it is turned off by default and any developer on the team who needs it can turn it on.

You CAN and SHOULD turn it on periodically too, to examine where your app is producing N+1 queries.

Here’s the catch with Bullet: Remember that Active Relation objects are created as chains of conditions before they get translated and executed as SQL. That’s why when you do this you must carefully consider

query = Country.where(name: “United States”)

When you do this in your Rails console, you will see it run the SQL right away.

2.4.6 :039 > Spree::Country.where(name: “United States”)
 Spree::Country Load (0.7ms) SELECT `spree_countries`.* FROM `spree_countries` WHERE `spree_countries`.`name` = ‘United States’ LIMIT 11

It only does this because of the ‘print’ effect the Rails console has on your objects. If you string another .where onto this object, when translated into SQL, ActiveRecord will combine the queries:

query = Spree::Country.where(name: “United States”); query.where(iso: “US”);
 Spree::Country Load (1.0ms) SELECT `spree_countries`.* FROM `spree_countries` WHERE `spree_countries`.`name` = ‘United States’ AND `spree_countries`.`iso` = ‘US’ LIMIT 11

The reason this is important is that to understand where your N+1 queries are coming from you need to understand when you are creating your Active Relation objects and when they are invoked. They are not the same place, although on the Rails console it makes you think it is one and the same. When you grok this, you will see why Active Record’s side loading (which loads a related set of objects in a single optimized query, taking the number of queries from N+1 to 1+1=2) is both efficient and can be tricky to work with, especially with objects that have many relationships.

Don’t be fooled: Side-loading is nearly always more efficient than N+1 queries. 

Bullet tells you where those pesky N+1 queries are invoked, but not where you are creating them. What you then need to do is trace your code (manually) to figure out where the queries are being created, which hopefully should be near in the code to where they are being invoked ( but in the case of complex filtering logic might not be).

Here you need to add the appropriate .joins(:____) to your code anywhere between when the objects are set up and when they are invoked by Active Record. Note that you’ll only want to join in those additional tables if they are actually used. If not, you don’t need the over head.

You’ll know you’ve solved your N+1 queries because you won’t see them output in your Rails log, and they’ll disappear from the Bullet code.

9. better_errors

Since Rails 4 adopted a near identical default, this used to be more interesting. For a Rails 3 app it can bring your error crash console up to Rails 4 standards.

10. Introspect, Introspect, Introspect but remember Ruby’s last-line quirk

Always look at what you’re doing. Drop into your debugger, look at your variables, clone & freeze them, look for race conditions, look for flip-floppers, watch out for your own confirmation bias. Remember that when in the debugger or on the Rails console and you type a SINGLE VARIABLE and HIT RETURN, the console will interpret that action as-if you had called .inspect

2.2.5 :007 > a
=> #<Apple id: nil, created_at: nil, updated_at: nil>
2.2.5 :008 > a.inspect
=> “#<Apple id: nil, created_at: nil, updated_at: nil>”

In some cases, the act of inspection actually changes the object (like in the case of an Active Relation, in which case it invokes the query), so keep that in mind (we might call this the “observer effect” in software development.)


Disable Same Origin Policy in Chrome

For macOS

open -a Google\ Chrome -args -disable-web-security -user-data-dir


chromium-browser -disable-web-security -user-data-dir=”[some directory here]”

For Windows

chrome.exe -disable-web-security

See this SO post


Announcing Nonschema Migrations

After many years, I decided that my gem nondestructive migrations needed a facelift. It had some cruft I didn’t want, was packaged in the wrong way, and Alex Chaffee brought up a legitimate objection to the nuance of its name: the discriminating factor that differentiates these migrations is not destruction, he argued, and so the gem is likewise misnamed.

For all of these reasons, and to fix a problem with bundler’s ability to smoothly upgrade, I am renaming and replacing nondestructive migrations with nonschema migrations.

As well, this approach implements different versions of this gem for each different version of Rails, which became necessary when


was renamed to


where X.X is the Rails version number. This strategy will allow bundler to easily pick up the new version of this gem when you upgrade Rails, and in the future I will release this along with Rails’ own release schedule.


Heroku with a SSL/TLS purchased from SSLRenewals – BYO Instructions

Buy yourself a “RapidSSL Certificate” at SSL Renewals. After you place your order, they may not send you an email, so log in and go to “Orders” and look for the “Generate” button

You must have access to admin@ your domain to proceed. They will send an email to verify your domain.

Generate a private key and CSR on your computer. (see instructions for mac OS or Windows)

Submit the .crt file, or certificate signing request, to SSL Nenewals. select for Web Server “Apache + MOD SSL”. Copy & paste the crt file into text box.

Use DNS authentication. It is easiest. You will need to set a TXT record on your domain name.

For “Please select the Secure Hashing Algorithm (SHA) you would like to use.” choose “SHA2-FULL-CHAIN”

Follow the instructions to create a TXT file. For the apex (root) domain, it should have no subdomain (leave blank). For a subdomain, it will instruct you to create a “domain” for a special content string.

The string is provided in what SSLRenewals calls “Alias Name”. Copy & paste this into into the “content” setting of your new TXT record (do this in your DNS manager)

At the end of the process, go to the SSL Renewals tab, find your order, and find the “Download Certificates” button. You will receive a folder called Certs-12345678

In it there will be several files:


You want to open in a text editor these three files: CACertificate-INTERMEDIATE.cer, CACertificate-ROOT.cer, ServerCertificate.cer

create a new file that contains the concatenated version of these three files, in this order:


Name your new file “-CHAINED” to distinguish it from the others.

Log into the Heroku web interface. Make sure you have deployed at least once.

On the command line, remove the automatically added Heroku SSL using

heroku certs:remove -a your-app-name

Verify with
heroku certs -a your-app-name

Back in the Heroku web interface, go to Settings > Configure SSL.

On the first screen, the “public certificate” is the new concatenated file you created. On the second screen the “private key” is the key you generated when you created the key & CSR.

(Reminder: never share your private key except with your web server provider.)


Amazon RDS on Heroku Still Works

Although Heroku has put a lot of attention into their own Postgres-based datbase architecture, Heroku Data, this article still works for rebels who want to use Amazon RDS on Heroku:

Note that I can’t seem to get “sslca” to work as a config option in my database.yml file (in Rails), I get this I get an error after deploying, upon connection

SSL_CTX_set_default_verify_paths failed

This happens when configuring by database.yml, which I shouldn’t be doing anyway.

Nonetheless, the configuration by DATABASE_URL (which is preferred for security anyway), does actually work.

Although it continues to work in 2018, this may not be good long-term strategy as my last conversations with Heroku support led me to conclude that their failover policies for catastrophic failures aren’t set up for an RDS- backed solution unless you go into Heroku Private Spaces, which you need to be an enterprise client for.


How to Install an Older Version of Rails

My post from four years ago with this same title is Google’s #2 result for a search for “How to Install an Older Version of Rails,” so I thought I’d make a repost with some updates.

You can install an older version of rails using this syntax:

rails _5.1.6_ new my-test-app

(Where “5.1.6” is the version you want and “my-test-app” is the name of your new rails app.)

Yes, you actually type those underscores around the version number.

If you get …

can’t find gem railties (>= 0.a) (Gem::GemNotFoundException)

You probably don’t have the right version of Rails itself installed as a gem; try this:

rails install -v=5.1.6


gem install rails -v 5.1.6

Then try again with…

rails _5.1.6_ new my-test-app

How to Be a Great Software Project Manager or Product Owner for Scrum

I think of scrum and agile as always a work in progress.

That’s because different teams can practice it to different levels of strictness. That’s ok. The naysayers to scrum or agile will call it a top-heavy process, where a “Certified Scrum Master” dictates strict processes.

Sometimes I hear of teams rejecting the ideas of agile wholesale on these grounds (“we don’t need it” / “it doesn’t work for us”). “Agile” is a buzzword, which fundamentally once meant “changing as you go” but now seems less and less relevant, at least to me, since so many people use that word so poorly.

“Scrum” is a funny word. It comes from a sports play in England—you see Rugby played to this day across parks in England.

I’m not sure what it is about this particular word, or this particular software development practice —or the lineage between the two, but “scrum” as a practice, is the practice that resonates most with me in my years as a developer, and it is the one that I’ve seen worked the best on the teams I’ve been on and run.

I’m all in support of most of core concepts of “agile,” but I think the word has been watered-down. As many of my peers in the industry have pointed out to me, lots of people think they are practicing “agile development” when in fact they are still plagued by all the same mismanagement pitfalls of other options (that is, “waterfall”).

“Scrum” is a software development practice that has a lineage to some of the best minds in software development and is a set of practices that work. While “agile” has more of a value system involved in it, scrum is a little more focused on the nuts and bolts of the SDLC (“software development lifecycle”).

Scrum, also, is not a buzzword.

Sure, the heart of it is to work in short iterations, but I want to list out a few key elements, for Product managers, which often get easily missed. This post is aimed at Product managers (or “Product Owner” in scrum’s more formal terminology.)

If I could highlight one thesis, it would be this: Scrum is about optimizing the operational efficiency of your team. If you don’t get that, or you aren’t getting that from your practice of Scrum, you aren’t doing it right.

Here the three most significant anti-patterns, or problems, I see on software development teams. These are like red flags you aren’t practicing scrum.

1. Single queued developers. (DON’T) Developers should focus on one story at a time. Period. If you are queuing up a single developer you are doing it wrong. Each dev should finish their assignment and then come back to the team and take the next highest-priority item off the list. Ok, so I know lots of teams and devs work with a ‘back burner’ story in case you get ‘blocked’ on your first story. I get it, and I concede for your team this may not be an absolute. Nonetheless, what this principle gets at is efficiency mechanics, and the blocker for the dev on the first story represents a cog in your wheel. (This is where the Kanban principle of pulling the ‘STOP’ chain on the assembly line comes in.)

2. Unclear definition of done (DOD). (BAD!) Ok, so I didn’t make up “definition of done,” but I like to emphasize it. Traditionally, “definition of done” means the definition by which the team considers the story done. On teams I’ve been on and managed the concept of “definition of done” expands to each step of the SDLC (software development lifecycle), in this order:

Design/Wireframe or Spec
QA or UAT (user acceptance)
Delivery to production

This is a specific order. I didn’t make it up. I did combine some steps so your team’s process might look a little different. But the concept is the same: You work on each little piece until you’re done, and then your start again. Wash-rinse-repeat, as they say.

However your team does it is fine: Scrum is not about rigid dictation of process. Scrum is about the concept that each player will hold themselves accountable (or be held accountable) to getting the ball (the story, in software development) to the next step. That’s why DOD (“definition of done”) can and should happen at each and every step. The business owner or CEO signs off on the concept; marketing and design sign off on Design; you (the product manager) sign off Wireframe or Spec (with the developers involvement to make sure they can actually build what you want them to build). The developer writes the code, and the QA person confirms the feature works and you confirm it is acceptable to the customer, client, or will work for the end user. Finally, it is deployed to production. Get it? That’s the SDLC. That’s the whole thing. (Agile/scrum secret: scrum looks just like waterfall but you do this whole 5-step process in short, quick, iterations. More on that in another blog post)

Too much formal process? Ok, fine. Then invent an informal process. You can change the rules of scrum! That’s fine. Nobody every said scrum dictated a formal process and whoever said that shouldn’t be speaking about it. But, please, understand this process works for a reason. If you’re going to make your process more informal, know why the five steps are important and make sure your informal process at each of the steps actually works.

Get everyone to agree to this, including the stakeholder, the designers and of course the developers. Sometimes a designer or a stakeholder might say “nothing’s ever done” or “everything is a moving target.” Maybe it feels that way to you on your team. I can sympathize. But if the stakeholder or designer doesn’t want a clear “sign-off” or “thump-up” or “it’s ready now” step then that’s a sign they haven’t bought into the very heart of scrum. Go back to the beginning and start again.

(It’s rare that you have to deal with a developer not wanting a clear definition of done— good devs I’ve worked with are goal and completion-oriented by our nature. Sometimes jr. developers can drag their feet, let projects slip, and not finish things. As the PO, disciplining this kind of developer isn’t your responsibility, but be on the lookout for it and understand the DOD applies all across the whole pipeline, at each and every step. That’s why the two steps—both of which really you can and should be involved with—are so important.)

“Definition of done” (DOD) is such an important thing to scrum. Really, I didn’t make it up. Look it up; it’s a thing. Lack of discipline around “done” is the single most significant team anti-pattern I see.

3. Developers complain about lack of prioritization (BAD!) Ok, so this is a very common thing on many software teams. You have lots and lots of ideas and stories. New ones come up all the time. You have meetings or stand-up and developers say, “I’m looking at list of unprioritized stories.” If developers say this in your meetings, especially if they say it a lot, you’re doing something wrong.

It is the Product owner/manager’s job to represent the business’s interests, or the customer’s interest, in prioritizing the worklog, or in formal scrum known as “backlog.” This is really, really important. Yes, developers do lots of things related to prioritization of code and code debt that you (the product manager) may not understand. And yes, sometimes developers can be welcoming to prioritization (or, as is often the case, re-prioritization), and other times, developers can be very unwelcoming of re-prioritization. That’s software development. If you want to work with the best dev teams, these are the kinds of nuances you need to navigate as a successful Product manager.

Some other tips

Six more tips for Product managers. Keep in mind these are written from a developer to a Product manager, so take with a grain of salt. These are opinionated and based on my several years of working on scrum teams.

4. Don’t skip user stories. This one seems obvious but I’m amazed how many Product people are so quick to skip formal User Stories. They’re so easy! I’m pretty formal about them, preferring the exact style:

As a ___
When I ___
And ___
I should ___

There are a few variations on this style and any of them is OK.

Learn how to write User Stories and use them. In strict scrum, you have only 1 user story per ticket or “story.” This often doesn’t work. If you have a ‘ticket’ or ‘story’ system. I’ll give you permission now: It’s ok to have more than one User story in a single ticket.

When I write them, I just string them together, right after the other, sometimes lettering or numbering them.

As a User,
When I type the right username & password,
And click “Login”,
I should be successfully logged in

As a User,
When I type the wrong username & password,
And click “Login”,
I should see a message tell me my username & password are incorrect

That’s fine! So there’s a little repetition. For QA people, repetition is A-OK. By writing the stories up front you are setting up the QA step for success (more on that later).

Don’t skip the user stories. Write them, get stakeholder buy-in on them, and believe in them.

(The most common pattern is “As a ___, I want to ___, so that I can ___”. Notice here it’s just like the one I use above except for the “I want to” / “so that I can” part. I have nothing against this pattern but I find it to be one step removed from product specifications—almost as though this pattern is written from the perspective of a business owner rather than the technical product owner, but in many ways and on many teams this is a distinction without a difference so I typically don’t dwell on it. Either “When I ___” or “I want to ___” is ok, the former is slightly more product-centric and the latter slightly more business-objective centric; both are preferable to no stories at all or stories written with implicit assumptions that aren’t clearly written out.)

Forcing yourself (the product owner) to go through this discipline forces you to methodically put yourself in the end user (or customer’s) perspective, and it forces out all of the little extra edge cases which need to be explicitly dealt with by the programmers. This kind of explicitness is nearly universally welcomed by developers, and more work up-front in this area typically makes the development faster and more efficient.

5. Don’t skip wireframes. It’s amazing to me how many Product people try to just have ‘meetings’ with developers. I know some people are better verbal communicators, but your job as Product owner is to document, document, document those meetings.

Like User Stories, wireframes drive the conversation about the software — which is most of the work! It’s the thing you didn’t think of when you just had the verbal conversation that you did think of when you put pen to paper (literally or metaphorically).

It’s that thing that your boss or other colleague thinks of after you show them the wireframe. You didn’t think of it before because some people are visual thinkers, and the feedback loop of translating the verbal conversation to the wireframe is itself the process of refining and improving the requirements themselves.

By getting all those little tidbits out up-front, you are reducing waste in the development process and speeding up the developers.

6. Do QA yourself. The best product people do QA themselves, even if there’s a separate “QA specialist” on the team. Yes, Product & QA are distinct skillsets. Yes, on some small teams, they are the same person. Don’t be one of those Product people who eschews doing QA yourself. If you’re not the best at it, learn to get better at it and QA the projects you are managing. It’ll be better for the team and it’ll make you a better Product manager.

7. Get stakeholder (or ‘exec’, as is commonly heard in startupland) buy-in early and before the devs write a line of code. Really, don’t skip this step. This is your primary job. If you are going back to the devs for revisions after revision, you aren’t doing your job right.

8. Think like a dev but don’t think like a dev. This one is hard. Know some things about what you think is possible with the technology you have and separate that from the technology you think you could have. Understand there’s a constant pay-it-now-or-pay-it-later tension in software development. Give just enough technical prowess without stepping on developers’ toes.

9. Ask for what you need. Don’t be afraid to ask the devs, but try to do so politely and without making any assumptions you know anything. Just report the facts, ask for what you need, and offer any helpful information.

10. Don’t ever say “but it worked before” or “but it used to work” or anything sounding like that. This is never something a developer wants to hear. If you are in a position of software development management, don’t lean on this trope.

Yes, developers are responsible for regressions that happen on their code deploys, sure. And yes, sometimes, when a developer deploys some code, it introduces a regression. But 95% I hear these words coming from non-technical people it is in fact not related whatsoever to anything any developer did. I also happen to think it is an unfortunate trope used by nontechnical people who fundamentally do not understand a concept we call in software development called software entropy. (Really I’m not making this up!).

If you really think it “used to work” just before a code change, it’s OK to report that in an evidence-based way when you report the bug to the developer. (As in, “Last successful one was at before the deploy may or may not be related.”) That’s totally cool. In fact, developers WANT you give them as much information as possible. Just do it an nice way and evidence-based fashion. Use your words, use your screenshots, and throw in “may or may not be related.” Go ahead, it’ll work like magic. I promise.

(Some really passive-aggressive version I’ve seen of this is to NOT tell the developer the key piece of information the Product manager has related to the regression thinking they will ‘test’ or ‘challenge’ the dev to find the bug. This, too, is not cool.)

As a nontechnical person, let me tell you something that the developers you work with really want to scream at you: You understand a fraction of what’s actually going on under the hood. You already know this. I don’t need to tell you this and the developers don’t need to either.

Leaning on “it used to work” consistently is an accusatory sign of an amateur manager who just doesn’t get it. If you find yourself doing this, put yourself in check and ask if this career is right for you.


Being a great Product manager, like all things in life, takes compassion. As a boss and mentor of mine (Rob Rubin) once told me I think smartly: the Product owner is the most leveraged individual on a Scrum team. That is, if you’re in a company and not on the Product team (like you’re the stakeholder), to get what you want out of the Engineers you should make friends with the Product people. (Thanks Rob!)

You have a great road ahead of you should you heed the discipline’s core principles. Fight them, and you may have a rocky time, especially in the areas of code debt, incorrect estimation process, missed deliverables, and mismatches between what the developers are doing and what the client or company needs.

Wherever you are at today is fine. But think about the discipline’s various approaches and think about how to take each piece of your process once small step in the direction of scrum. You might wavier, you might run into various problems, but each of them can be solved by coming back to the disciplines at each step of the chain, always bringing your team closer and closer to its most efficient state. This is why I think of it as “always a work in progress.” Teams typically don’t get it right on the first try, and have to do it inefficient ways before they can move towards scrum.


Announcing Nondestructive Migrations Version 1.3 for Rails 5.1

I am pleased to announce Version 1.3 of my gem nondestructive_migrations. With this update, nondestructive_migrations is ready for Rails 5.1.

The Gem’s Github page can be found here: and you’ll find a sample app for Rails 5.1 here.

Version 1.3 is officially pushed to Rubygems as of this morning.

I know I’m slightly behind the Rails release schedule itself. (We just had Rails 5.2 officially released last month.) Thanks to some help from Mikls Fazekas from Hungary hopefully this gem should be ready for Rails 5.2 soon. Watch this space for updates!