# Dan Maksimovich

Published articles for Dan Maksimovich.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Don't DRY Your Code Prematurely

DevFeed: [Don't DRY Your Code Prematurely](<https://devfeed.tech/articles/don-t-dry-your-code-prematurely-23856.md>)

Original publisher: [Read original article](<http://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html>)

Author: Google Testing Bloggers (noreply@blogger.com)

Published: 2024-05-28T14:20:00Z

Content type: opinion

Language: en

Sources: [Google Testing Blog](<https://devfeed.tech/sources/google-testing-blog.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Testing](<https://devfeed.tech/topics/testing.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [code-health](<https://devfeed.tech/tags/code-health.md>), [dan-maksimovich](<https://devfeed.tech/tags/dan-maksimovich.md>), [series](<https://devfeed.tech/tags/series.md>), [tott](<https://devfeed.tech/tags/tott.md>)

### AI overview

The article explains why applying DRY principles too rigidly can create premature abstractions. It recommends distinguishing truly redundant code from superficially similar code whose behavior may need to evolve independently.

### Source excerpt

This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Testing on the Toilet episode. You can download a printer-friendly version to display in your office. By Dan Maksimovich Many of us have been told the virtues of "Don't Repeat Yourself" or DRY. Pause and consider: Is the duplication truly redundant or will the functionality need to evolve independently over time? Applying DRY principles too rigidly leads to premature abstractions that make future changes more complex than necessary. Consider carefully if code is truly redundant or just superficially similar. While functions or classes may look the same, they may also serve different contexts and business requirements that evolve differently over time. Think about how the functions' purpose holds with time, not just about making the code shorter. When designing abstractions, do not prematurely couple behaviors that may evolve separately in the longer term. When does introducing an abstraction harm our code? Let's consider the following code: # Premature DRY abstraction assuming # uniform rules, limiting entity- # specific changes. class DeadlineSetter: def __init__(self, entity_type): self.entity_type = entity_type def set_deadline(self, deadline): if deadline <= datetime.now(): raise ValueError( "Date must be in the future") task = DeadlineSetter("task") task.set_deadline( datetime(2024, 3, 12)) payment = DeadlineSetter("payment") payment.set_deadline( datetime(2024, 3, 18)) # Repetitive but allows for clear, # entity-specific logic and future # changes. def set_task_deadline(task_deadline): if task_deadline <= datetime.now(): raise ValueError( "Date must be in the future") def set_payment_deadline( payment_deadline): if payment_deadline <= datetime.now(): raise ValueError( "Date must be in the future") set_task_deadline( datetime(2024, 3, 12)) set_payment_deadline( datetime(2024, 3, 18)) The approach on the right seems to violate the