Skip to content

Document more reasons this is good #31

Description

@JayBazuzi

I recently presented ACN to an audience that wasn't already fluent in disciplined refactoring, and got resistance of the form "why should I shift how I work and how I think about development + learn this new notation? What's in it for me?"

That may deserve its own article, but perhaps we can identify something pithy to add here.

I started working in this way because it made my life easier: it was easier to make my code changes, to understand what changes I had made, and to roll back when something went wrong.

When trying to understand whether some weirdness in legacy code was deliberate, I find where it was added in commit history. When fixing a bug, I search history to understand whether I am actually undoing a bug fix that I don't understand. Both of these are aided by the incrementality that ACN invites and by the expressions of intent and risk.

When I've tried to explain that last paragraph to people, sometimes they get it immediately, and sometimes they are surprised at the idea that reading commit history could be useful.

What would you add to the list? See anything that could be a pithy soundbite?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions