It’s a Phase
Obsessing with “clean code” and removing duplication is a phase many of us go through. When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.
You can’t automate removing duplication, but it does get easier with practice. You can usually tell whether there’s less or more of it after every change. As a result, removing duplication feels like improving some objective metric about the code. Worse, it messes with people’s sense of identity: “I’m the kind of person who writes clean code”. It’s as powerful as any sort of self-deception.
Once we learn how to create abstractions, it is tempting to get high on that ability, and pull abstractions out of thin air whenever we see repetitive code. After a few years of coding, we see repetition everywhere — and abstracting is our new superpower. If someone tells us that abstraction is a virtue, we’ll eat it. And we’ll start judging other people for not worshipping “cleanliness”.
I see now that my “refactoring” was a disaster in two ways:
Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together.
Secondly, nothing is free. My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and behaviors for different handles on different shapes. My abstraction would have to become several times more convoluted to afford that, whereas with the original “messy” version such changes stayed easy as cake.
Am I saying that you should write “dirty” code? No. I suggest to think deeply about what you mean when you say “clean” or “dirty”. Do you get a feeling of revolt? Righteousness? Beauty? Elegance? How sure are you that you can name the concrete engineering outcomes corresponding to those qualities? How exactly do they affect the way the code is written and modified?
I sure didn’t think deeply about any of those things. I thought a lot about how the code looked — but not about how it evolved with a team of squishy humans.
Coding is a journey. Think how far you came from your first line of code to where you are now. I reckon it was a joy to see for the first time how extracting a function or refactoring a class can make convoluted code simple. If you find pride in your craft, it is tempting to pursue cleanliness in code. Do it for a while.
But don’t stop there. Don’t be a clean code zealot. Clean code is not a goal. It’s an attempt to make some sense out of the immense complexity of systems we’re dealing with. It’s a defense mechanism when you’re not yet sure how a change would affect the codebase but you need guidance in a sea of unknows.
Let clean code guide you. Then let it go.
The Winter Getaway That Turned the Software World Upside Down
How a group of programming rebels started a global movemenT
Ken Schwaber—the cofounder of Scrum and founder of Scrum.org—says Waterfall “literally ruined our profession.” “It made it so people were viewed as resources rather than valuable participants.” With so much planning done upfront, employees became a mere cog in the wheel.
.. Waterfall “has gradually lost favor … because companies usually build better products if they can change specifications and designs, get feedback from customers, and continually test components as the products are evolving.”
.. Bob “Uncle Bob” Martin. Martin, an industry veteran and the founder of Uncle Bob Consulting, runs The Clean Code Blog
.. “When we compared how we did our work, we were just kind of astonished at the things that were the same.”“When we compared how we did our work, we were just kind of astonished at the things that were the same.”
.. Unlike other historical documents, the Agile Manifesto doesn’t declare truths self-evident. Rather, it compares: We value this over that.
.. Schwaber says the group did invite “a whole bunch of really pretty knowledgeable women” but that none showed. “They thought it would just be a carousing and smoking weekend,” Schwaber says. “They didn’t think we were going to do anything intellectual or productive.”
.. But it’s unclear whether women were, in fact, actually invited: A few of the framers tell me they vaguely remember some women being invited. Others don’t.
.. Unlike Waterfall, Agile emphasizes iterative development, or building software in pieces. Agile teams typically work in short cycles—which are called “sprints” in Scrum, today one of the most widely used forms of Agile—that usually last two weeks each.
.. Today’s software isn’t typically burned onto a CD-ROM and stocked on a store shelf; updates can be pushed to your laptop or smartphone remotely. This makes it easier to add features or fix bugs after releasing the product.
.. Despite discussions over whether the Manifesto itself should be amended, many of the original signers see the document as a historical—not a living—document. “It’s like a Declaration of Independence in U.S. history,” says Cockburn. “You don’t go back and rewrite that.”
.. “Now you can go to a conference, and there’s aisle after aisle of people who are selling you computer tools to run your process. And they say it’s Agile,” says Cunningham. He points to the first value of the Agile Manifesto. “It says, ‘Individuals and interactions over processes and tools.’ How did [Agile] become a process-and-tools business?”
.. The monetization of Agile aside ..
.. the “most annoying aspect right now” is that Agile “has been taken over by the project-management people,” leaving “the technical people and the technical ideas” behind.
.. Sutherland says he sees teams in Silicon Valley that claim to be Agile, but are “not delivering working product at the end of a short iteration.”