How to Request an Introduction

Use these examples as a template for requesting an introduction.

How Should This Work?

January 16, 2014

Successful software projects are always changing. Every new requirement comes with the responsibility to determine exactly how the new or changed behaviors will be codified into the system, often in the form of objects.

For the longest time, when I had to change a behavior in a codebase I followed these rough steps:

Locate the behavior in the application’s code, usually inside some class (hopefully just one)
Determine how it needed to be adjusted in order to meet the new requirements
Write one or more failing tests that the class must satisfy
Update the class to satisfy the tests

Simple, right? Eventually I realized that this simple workflow leads to messy code.

The temptation when changing an existing system is to implement the desired behavior within the structure of the current abstractions. Repeat this without adjustment, and you’ll quickly end up contorting existing concepts or working around legacy behaviors. Conditionals pile up, and shotgun surgery becomes standard operating procedure.

One day, I had an epiphany. When making a change, rather than surveying the current landscape and asking “How can I make this work like I need?”, take a step back, look at each relevant abstraction and ask, “How should this work?”.

The names of the modules, classes and methods convey meaning. When you change the behavior within them in isolation, the cohesion between those names and the implementation beneath them may begin to fray.

If you are continually ensuring that your classes work exactly as their names imply, you’ll often find that the change in behavior you seek is better represented by adjusting the landscape of types in your system. You may end up introducing a collaborator, or you might simply need to tweak the name of a class to align with it’s new behavior.

This type of conscientiousness is difficult to apply rigorously, but like any habit it can be built up over time. Your reward will be a codebase maintainable years into the future.

[…]

Planet Argon Podcast, Episode 2: The Letter Scotch

October 30, 2009

Earlier this week our new podcast was approved and is now available in the Apple iTunes Store. We’re also soliciting topic ideas for future episodes on brainstormr.

We posted Episode 2, The Letter Scotch, yesterday for your enjoyment. In this episode, we covered a handful of web browser tools that we use (and detest) to debug HTML, CSS, and JavaScript. This included Web Inspector, Firebug, DebugBar, and a handful of other tools. We all have slightly different preferences, depending on the tasks that we’re working on and the team had an open dialogue about the pros/cons of each of these tools.

You can learn more about and listen to our podcast at http://planetargon.com/podcast.

Thanks in advance for listening!

[…]

The Ruby Rails Aggregator