Skip to content
I Know I Can, But Should I? A talk about making choices.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci
app
bin
config
db
lib
log
public
spec
storage
tmp
vendor
.env.development
.env.docker
.env.test
.gitignore
.pronto.yml
.rspec
.rubocop.yml
.ruby-version
.scss-lint.yml
Dockerfile
Gemfile
Gemfile.lock
Gnarboarfinishwhite.jpg
PMBOK.jpg
Procfile
README.md
Rakefile
Ruby_On_Rails_Logo.png
Ruby_On_Rails_Logo.svg
all_tools.jpg
config.ru
docker-compose.yml
gnar_logo__wordmark.png
hammer_brick.jpg
hammer_screw.jpg
i_know_i_can_should_i.key
logo__badge.png
nail_screw.jpg
package.json

README.md

I Know I Can, But Should I?

Abstract

You can use a hammer to drive a screw into wood, but I’d recommend a screwdriver. Why? And when is a hammer the better option? This talk will propose a framework to use when comparing alternative technical choices. I won’t decide for you, but will leave you with a structure to apply in your decision-making process.

The ruby toolbox is vast. While Rails provides a default experience, it leaves plenty of room for alternatives. In learning how to do something, you may uncover different ways to accomplish the same goal. Determine which tool fits best in your situation with these lessons.

Presentation Details

The Rails Doctrine frequently speaks to the breadth of options available at your disposal within the framework. There are many sharp knives in ruby that, when used judiciously, can facilitate a great result for your product, your team, and your code. However, knowing in which situations to reach for one tool, technology, or architecture when the framework supports many paradigms is difficult. Having the option to make substitutions is liberating, but imposing.

Some groups or situations may demand rigorous up-front evaluations prior to determining a solution. While those exercises can inform our choices, a lighter-weight approach is more appropriate in most decisions we make on a daily basis as developers. When presented with multiple options that will solve a problem, the following criteria are helpful to consider:

  • What impact does this have on the code, the product, and the team?
  • What cost and risk will be incurred by introducing this solution?
  • How will this be maintained over time?
  • Has the team encountered something similar to this before? What was the result?

Not all of these questions may be applicable in all situations, and the relative weight of one over the others will also vary, depending on the context of the team or the problem.

Slides

The latest iteration of the slides that accompany this presentation are available here in this repository. The slide deck in this repo is in macOS's Keynote format.

Code Examples

The presentation uses various snippets of code to illustrate how the different criteria proposed for evaluation can be used to determine the relative benefit of one alternative vs. another. All of the code samples in the presentation have been built out as part of a rails app in this repo. Below you can find references to relevant commits that introduced the code used in the presentation.

Impact

Cost

Maintenance

Consistency

  • Warn user about consequences of editing personal information
You can’t perform that action at this time.