All posts by Tute Costa

Paperclip IS vulnerable to ImageTragick

- Tute Costa
- May 6, 2016
- Uncategorized

Paperclip is affected by CVE-2016–3714 if used with ImageMagick 7.0.1-0 or earlier.

Read more at the source

ImageMagick vulnerability does not affect Paperclip

- Tute Costa
- May 4, 2016
- Uncategorized

There is no need to upgrade Paperclip in light of CVE-2016–3714. You may choose to upgrade ImageMagick regardless.

Read more at the source

Running Acceptance with Heroku Review Apps

- Tute Costa
- April 22, 2016
- Uncategorized

Generate staging environments automatically for each pull request.

Read more at the source

Email confirmation with Clearance

Leverage Clearance’s guards to add email confirmation to your Rails app.

Read more at the source

Refactor Until You Feel Almost Comfortable

Duplication is cheaper than the wrong abstraction.

Read more at the source

Paperclip Security Release

- Tute Costa
- June 5, 2015
- Uncategorized

We released Paperclip v4.2.2 with a security fix.

Read more at the source

Splitting an open source project in two with Git submodules

- Tute Costa
- June 2, 2015
- Uncategorized

How and why we split the doorkeeper project into different rubygems.

Read more at the source

Maintaining Open Source Projects: Licenses

- Tute Costa
- May 1, 2015
- Uncategorized

We’re pleased to announce a new chapter on Licenses in our Maintaining Open Source Projects book.

Read more at the source

Maintaining Open Source Projects: Documentation

- Tute Costa
- April 24, 2015
- Uncategorized

We’re pleased to announce a new chapter on documentation in our Maintaining Open Source Projects book.

Read more at the source

Announcing Maintaining Open Source Projects

- Tute Costa
- March 2, 2015
- Uncategorized

Learn how to create, grow and maintain a successful open source project.

Read more at the source

Are you experiencing technical drift?

December 19, 2013

David Byrne, in the seminal Talking Heads song “Once in a Lifetime”, sings “How did I get here?” The meaning of those lyrics have been fodder for some great discussion, but I think there’s one interpretation which has been sorely missing from that discourse — that the narrator is a software developer. The software developer, reflecting back on his work, is wondering how he accumulated so much technical debt.

“Letting the days go by, let the water hold me down.”

The water which holds him down is an obvious reference to what can happen to a software developer over time, caught under the weight of their own codebase. But what Byrne is singing about here isn’t strictly technical debt. Technical debt is the outcome. He’s singing about something else, about “letting the days go by”, about letting your codebase slip away from you.

Byrne, although he did not know it at the time (after all, even the phrase technical debt hadn’t been invented yet) was singing about “technical drift”. Technical drift is a phenomenon that impacts a lot of well-meaning software development teams. It’s a phenomenon that occurs when a development team continuously fails to recognize and adapt to change, causing the concepts in the software’s domain and the concepts in code to start to slowly “drift” apart from one another, creating dissonance which ultimately leads to technical debt.

One of the goals of software development is to write software that most closely reflects the the domain in which we’re working. This creates more understandable code that is easy reason and discuss, both within the tech team and with the rest of the organization. But it’s important to remember that the domain is continually shifting. We’re receiving new requirements based on new information.

If we don’t adapt to these changes, a gap will appear between our domain and software, and the gap becomes our friend, technical debt.

While the signs of technical drift may be hard to spot, technical debt, the result, starts to become readily apparent.

In some cases, a software development team, or a team leader, recognizing that the gap has become too large, comes together and decides “enough is enough”. What is needed is Design —Big Design. The team stops feature development, buckles down, and refactors their code and architecture to more cleanly map to their domain.

The problem with Big Design is that it’s a “stop the world” operation. Feature development stops, and an anxious queue begins to build up waiting for the development team to free up. Furthermore, it grants false hope that such a thing might not be necessary again, but if the pattern continues, it often becomes inevitable.

How do we prevent technical drift?

If you’re not taking an active role in refactoring your application every week chances are you’re experiencing “technical drift”. Having a problem space that is continually changing necessitates continuous reworking of how your application is designed — what Agile practitioners call “iterative design”. When you’re able to do this effectively, you can round off the peaks and avoid some of the pitfalls of Big Design.

Note that the “Code” and “Domain” lines never intersect. We must accept that we do not yet have enough information to make some kinds of design decisions. But we can get close.

Understanding technical drift is more of a mindset than a particular practice, but it can help put into context why it’s important to remain vigilant, to call attention to code and domain mismatches, and to advocate for accurate and precise names wherever possible. Gaps which you’re creating may be well understood today, but as your team changes, and time progresses, that understandability suffers. Make the investment now, double down and pay attention.

Years later you don’t want to look back in horror on your code and say to yourself “my god, what have I done”.