Cover image for Advantages(!) of Dirty Code

Advantages(!) of Dirty Code

d4ttatraya profile image Dattatraya Anarase ・4 min read

Originally posted on my blog site.

First and foremost advantage for me is that I don't need to define it; 😊! Almost everyone, who have written any kind of program, knows what dirty code is; whether or not everyone realizes it is another story.

Internet is flooded with principles, rules, techniques, best practices, how-to steps to write code. And now-a-days almost every programmer is also talking about some kind of techniques to follow while writing code in respective programming languages. While using such techniques in writing code we have to follow lots of rules and best practices. Ultimately it puts many constraints to write code freely, slows us down, makes us fail to achieve time-lines of deliveries, and much more pain than any real programmer can imagine.

Here is high-level summary of side-effect of following such practices:

  • Takes lot of time to name things
  • Needs unnecessary separation between modules
  • Makes us write lot of extra code which never will be in product builds
  • Not allowing to add comments
  • Force to make intentional errors first and then solve them Let's get into more details of these side effects and see how painful they are.

Naming Things

Many people around internet talks about giving meaningful names to variables, functions, classes, modules and their necessity. But why it is so necessary? What will happen if you name a variable d instead of numberOfDaysInTrailPeriod?

int d = 10;
int numberOfDaysInTrailPeriod = 10;

No error will be generated by compiler and nothing is going to break runtime either.
Similarly this

int rdsTrail(){//code}
int remainingDaysInTrailPeriod(){//code}

Come on, let's not waste our time thinking appropriate and meaningful names for things.

If we ourselves in future or anyone else is going to work on this code later will debug and understand what int d and what int rdsTrail() stands for.

De-coupling of Modules

This is another most discussed topic under some techniques when writing bigger projects which contains many modules interacting with each other. This is also brought on when writing interfaces for modules. I don't understand what makes them think to hide implementations behind these interfaces? They call it some kind of abstraction.
No one is going to disturb that implementation. Here we are already tired implementing new features and fixing bugs; and why should we go and change others' implementations.
And why should we keep fine separation between modules if they are interacting with each other so intensely and so frequently? We have written modules for our project and our project is useless if we remove any of the modules. Then why think as if we are going to use each module separately and independently.

If in future we need to replace any module then just modify respective code according to new module, or if need to reuse it in any other project just rewrite it.

Unit Tests

Yet another myth of programmers, just to put more and more efforts and time writing simple piece of code which will take no more than a minute. The main purpose of unit testing is to see if our code is working as expected or not, but if there are QAs and testers sitting next to us why should we bother about testing code by ourselves?
Unit testing unnecessarily forces us to split our big good fat functions to smaller chunks. Putting limit to number of lines in functions also puts limit to our speed of writing them. Also why would we always follow the rule of single responsibility and top to bottom flow of functions calls? It's of course going to slow us down.

If anyone wants to test workability of code after making some changes or adding more code then he/she should just have to give program to testers.


People also says that code should written in a way that not only computers but also humans can understand it. Again, if we tried to follow this rule then we need to waste our time writing code which can easily be understood by another programmers just by reading it. But, simply, if we are having such beautiful and powerful IDEs why programmers need to read code instead of run it and watch output direct.
Another constraint they put here is no more comments in code. All the IDEs support adding comments in code. Instead of trying to make it understandable by just reading code, let's put comments wherever needed to explain. In above example, we can add comment like

int d = 10; //number of days in trail period

There is nothing wrong in this, neither compiler throws error nor compiled build will include these comments.

If we are worrying about understandability of our code by reading, let them understand it by debugging it or by reading console logs or simply by reading comments.


Now I can use this word, NIGHTMARE! TDD is nothing but a nightmare to all programmers, particularly to one who actually follows it. Make a mistake, correct it; again make another, correct it... How silly is this? And this flow, believe me, creates another parallel program that is bigger than actual program, also takes more than double time. And what purpose this serves is forces us to follow all above rules.
To make even very small modifications we need to first modify respective tests or to add small code we need to first write test. That is we have to think about test first and then implementation; isn't it time consuming?

Instead of let tests drive our development why can't we go straight forward and start without making any errors.

At the end

I would like to argue you about not fall for what people are saying and just ignore following side-features of our code:

  • Easy to read, understand
  • Easy to replace modules, algos
  • Easy to debug and fix bugs
  • Easy to modify and reuse
  • Easy to add new features We can think of these whenever it's required in future. So just chill and write a code that just works!

You know what do I mean by this blog post...!!!
(Image Courtesy: rathod.milan053@gmail.com)
If you are on either side of coding, dirty side or whatever the other side, please leave comments and give a 👍 !

References: Uncle Bob's Clean Code

Posted on by:

d4ttatraya profile

Dattatraya Anarase


iOS Developer, writing blogs on programming, swift, clean code practitioner


Editor guide

I have almost nothing to say that I could summarize in the time I have for this. I am stunned anyone could actually (seemingly) seriously express these thoughts.

"Why test my own code, when there's an entire department of other people to test it?" - Are you that selfish that you don't care about what garbage you produce to other people, and you're happy to just make it "their problem" as soon as possible? Are you that ashamed of your work that you literally don't care? I just cannot comprehend this. I take pride in the fact that when I finish a task I can say with a reasonable level of confidence "it works as intended", without having to shove the responsibility of figuring out if it does to someone else.

"Takes lot of time to name things" - Do you really not comprehend WHY this is done? Because when you use int d = 10; that might make sense to you right there and then, but it won't make sense, even to YOU, in a year or two after you've not seen that code for a while. Then nobody knows what that code does, or why it does what it does, and most importantly what it's intended to do. Seriously now? Of course you don't have to go to ridiculous lengths as you do with your particularly poor example numberOfDaysInTrailPeriod [sic], just use trialDays or similar and it's MUCH clearer than d.

"Needs unnecessary separation between modules" - What magic book of rules has told you to unnecessarily separate modules? Move code into modules when it makes sense, i.e. when you need the same code somewhere else and want both of those uses to update at the same time. If there is no reason to avoid duplication, don't just deduplicate for the sake of deduplication.

"Not allowing to add comments" - Another mind-blowing statement from a magic book of rules you must have stashed in your shelf. Yes, add comments to places worth comments. However, if your code needs comments, you should probably think about why it's so unclear that it needs comments. There are valid answers that lead to the decision "yes, adding a comment is the right choice".

"The main purpose of unit testing is to see if our code is working as expected or not" - AND much more importantly than to check if what you wrote now works, it is to ensure it also works in the future, and to notice when it breaks due to an unexpected interaction with another change somewhere else possibly by someone else.

"Unit testing unnecessarily forces us to split our big good fat functions to smaller chunks." - Where exactly does it say that in the name "unit testing"? Write your big functions if you want to, just write tests for them as well. I really can't think of a single unit testing framework that enforces a maximum number of lines or your code will fail, but many organizations do enforce that kind of rules for various reasons, mainly readability.

"I don't understand what makes them think to hide implementations behind these interfaces?" - Clearly you don't. One obvious BIG reason is so the implementation can be changed without all the uses being changed. Have a search function? Great, make a clear search interface so when you upgrade from your current search solution to a better system only the code inside the search implementation has to be changed and nothing outside it, assuming you did a good job.

"Force to make intentional errors first and then solve them." - What on earth are you talking about? TDD has nothing to do with INTRODUCING an error first and then solving it, but instead e.g. when you try to solve a bug, you first write a test that reproduces that bug and then you fix it, so you can confirm that you actually fixed the bug. Some people might go to extremes with it by first writing a full set of tests for their code that they haven't written at all, but not even that is as ignorant at what you're proposing, that TDD is "a nightmare". The point of it is to have good unit test coverage so you notice when something breaks and you have good ways to check if you have actually fixed the issue later on.

"So just chill and write a code that just works!" - What an incredibly ignorant statement to make after you've proposed you write code without any tests, and is an unreadable and unmaintainable mess. Good luck with your "just works" when you shove the garbage you produced to your QA department.

In short this post seems like a disastrous tantrum -post by an ignorant non-professional. Take pride in your work, strive to make great code that is maintainable and understandable to other people as well and long after you leave the company. Take everything this post says as something to avoid. The person who wrote this should not be working as a programmer.


I tried my best to put it in sarcastic manner, but may be I fall short to reach clear sarcasm


Glad I read this comment... This article is upsetting


Fair enough. I thought from the title that it must be satire, but the way it is written makes it sound like you are 100% serious.

Thanks for the clarification.


You really should place a "This is supposed to be sarcasm people" disclaimer in the article, because it's blowing up all over and it's going to damage your reputation as a developer at this rate.


Calm down. It's pretty clearly satire.


As an avid satirist, I have to disagree. None of the classic signals of satire are present, and I suspect that you and I have both met people who could write something like this in complete seriousness.

Admittedly, the response is pretty harsh. The article indicates a lack of experience rather than total lack of aptitude for software development.

Nah, assuming lack of satire I don't think it was harsh at all.

It sounds like the person HAS some experience, and that experience has taught him about TDD, Unit Testing, naming, etc. and they decided against all those things as simply slowing them down from doing their thing.

A person following these guidelines would generate more work for others than they would solve with their own work, i.e. they would generate negative effort towards solving problems. Simply having them not be around would make any company do better.

This would highlight a problem with personality rather than lack of experience.


I will try to be respectful, but this post actually upsets me, and I disagree with everything that you have said. In fact, I tend to think that any seasoned developer would take issue with your tenet of "clean code doesn't matter."

Your argument for dirty code is that it reduces the amount of effort required of the developer. Nothing could be further from the truth. Writing code is relatively easy, and writing cohesive, DRY, modular code with well-named methods and variables is only slightly harder than writing spaghetti code with poor variable names (once you know how to do the former). On the other hand, reading clean code is several orders of magnitude easier than reading poor code. And almost every developer spends far more time reading code (a prerequisite for modifying it, building upon it, or fixing it) than writing it.

My counterpoints to each of your statements are as follows:

  • Naming things. You say that a developer can just debug your code and find out what d refers to. What if your app has more than one variable? If you're dealing with a complex feature that uses seven, eight, or a hundred variables, you'll go absolutely nuts if they're all named alphabetically--you'll forget what the first one is for before you've figured out what the sixth one is for. Also, forcing another developer to enter debug mode in order to understand your code is a terrible tax to impose on them. On the other hand, there is no downside to well-named variables, even ones with very long names. The extra characters will have no impact post-compilation. But they will make your code easy to understand on sight, which will save you and others a lot of time and effort. Yes, it takes a few extra seconds or minutes to think of a good variable name. But software developers are expected to think hard about their job.

  • Loose coupling. You say that you don't understand the value of interfaces. Here it is: a good interface prevents you from having to read an entire module in order to use it. Have you ever read the documentation for a third-party library or package? Thank goodness you don't have to read the code itself to figure out how to use it. A good module hides everything that you shouldn't have to know about or think about. That makes your job easier. You say that "no one is going to disturb that implementation." That's a false and dangerous assumption; the nature of code is change. Every popular package on GitHub has been through several versions, and there's even a commonly-accepted versioning system (semver) based on the idea that interfaces should remain mostly stable. This can only happen when those interfaces are as simple and as sensible as possible.

  • Unit tests. The main purpose of unit tests is not to see if our code is working or not, but to allow us to modify and extend it without breaking anything. It is instant almost-proof that your changes are correct. Unit tests also make it easier for other developers to understand your code, by allowing them to see the outputs for a given set of inputs. You may have QA testers on your team, but they are human--this makes them imperfect, inconsistent, and slow. Furthermore, they can tell you when something is wrong, but they can't tell you where the problem is, whereas a unit test can. Unit tests are far superior at their intended use. Additionally, there's no such thing as a "big good fat function". The best functions are clear about their purpose and intent, and usually composed of many smaller functions. This makes their functionality shareable and gives you more confidence when fixing a problem in an isolated area of the function.

  • Readability. Your claim that it's easy to understand code by executing it is superficial at best. Most applications aren't lone functions with well-defined outputs; they're complex and multi-faceted, with incredible amounts of business logic being evaluated under the hood. And at some point, you will have to understand the code itself in order to maintain it. There's no way around that. And no software guru has ever recommended that you stop writing comments--just that you shouldn't use comments as a replacement for good code. I have rarely seen a comment that was as useful as a good variable name.

  • TDD. The purpose of TDD isn't to intentionally make mistakes. It's to prove that our software does what we originally intended it to do. You write a unit test for the code that you're about to write (it fails, but this is not a mistake). You implement code that satisfies the test. And you're done. It's literally two steps. Yes, this takes time. Yes, unit tests can be bulky. But this gives you confidence in your code, piece-by-piece, that you cannot achieve any other way, and prevents you from making little mistakes that may someday break production code.

Writing dirty code doesn't just waste a lot of time (for you and other developers). It results in a project that cannot scale or be maintained. If you walk into a project with multi-thousand-line functions, no shared code, overcomplicated interfaces, and no unit tests, you will be constantly frustrated until you rewrite it or move on to a different project. Dirty code is never dependable and you can never be sure that it's working right.

If we were perfect developers, perhaps we could just "go straight forward and start without making any errors." But we're not; we all write bugs. Writing clean code is an invaluable mark of humility in a developer, because it signals that they recognize their imperfections, and are willing to put a little more effort into their work product so that it can be understood by others, fixed when it is broken, modified when it's no longer sufficient, and deleted when it's no longer needed.

I wish you luck in your programming career and fully expect that you'll discover the value of clean code sooner or later.


Cunningham's Law states "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."


I tried to write as if I'm dirty coder and how would I react if someone told me about clean coding. I saw people thinking in a way I wrote in this post. I wrote it straight forword thinking anyone who knows little bit about clean code would disagree with me and eventualy realize that this is dirty coders point of view. I put sketch at the bottom which depicts the fact that dirty coders likes to code as they are doing since they started and don't want to adopt clean coding standards. I hope this will clears the air.


Yes, that's good to know. There are two issues you should consider here:

  1. I didn't understand your sketch. Maybe it needs a caption.

  2. This is a classic case of Poe's Law. It's possible that a dirty coder reading this would feel that they've gained justification for their actions, which would damage their career and make a heavy workload for those who work with them.

With satire or parody, I find it's almost always wise to clearly label it as such. I'd feel bad for you if a potential employer found this article and thought you really felt that way!


Guys, as some mentioned its confusing, plz tell if I should add some 😊or 😜 in post to make it clear that this is nothing but a satire and sarcasm!


I wasn't sure it was satire and sarcasm until I saw your discussion comment.

I would add this at the very top:

#define SATIRE 1
#define SARCASM 1

And this at the very bottom:

#undef SARCASM
#undef SATIRE


Please Don't add anything... I wasn't sure at first until i've read the tdd part XD. It's a nice "take thing into perspectives"


Yes please add something to make it more clear that this is sarcasm.


Brilliant! This article is brilliant! Effectively and accurately depicting careless and selfish dirty coders state of mind (and I know some), while subtly emphasizing the utmost necessity of such tools and conventions. The strong reactions only confirm the accuracy of what you wrote, take it as compliment! I myself was getting crazy reading your post :)
But I'd like to hear the dirty coders, what are your arguments in favor of your coding style? And please forget about speed, which is nothing more than an illusion, giving you immediate satisfaction and coming at you like a boomerang when maintenance comes...


Despite the sarcasm, I think there is a point to some of it :-).
I have seen teams where the TDD is so extreme that people would write tests just because one has to write tests (because otherwise the code metrics would not pass), instead of focusing on the tests that matter.

Because at the end, all these tests don't help if the most important tests are missing, plus it adds so much overhead (tests have to be maintained), that it can be counter productive. I feel that sometimes people take the rules to literally without thinking about why the rules exist and when they make sense.

I have seen code where the modularization is taken to such an extreme, with long hierarchies interfaces and so many levels of code and gazillion tiny classes with hardly any code, making the code much less readable.

In general I think people need to take any rule with a grain of salt, and break it occasionally when it makes sense, and not blindly accept them.


Even if this is sarcasm, I think there is a point to some of it :-).
I have seen teams where the TDD is so extreme that people would write tests just because one has to write tests (because otherwise the code metrics would not pass), instead of focusing on the tests that matter. Because at the end, all these tests don't help if the most important tests are missing, plus it adds so much overhead (tests have to be maintained), that it is really counter productive. I feel that sometimes people also take the rules to litterally without thinking about why the rules exist and when they make sense. I have seen code where the modularization is taken to such an extreme, that the end results is gazillion interfaces and levels that are never used at the end, making the code less readable. In general I think people need to be more critical of any new paradigm :-). So to me, pieces like this help to think about what we are doing and why :-).


Sarcasm it's supposed to be funny. If it's not funny, it's not sarcasm.

If I were you, of just delete this post. Before hiring, I'd find this with your name on it and it's not obviously sarcastic.


You urgently need to add a disclaimer at the beginning of the post stating the (poorly executed) sarcasm in this post. It does feel as a legit article and even though there's a very important point in it to be made.

It's been around since August and I saw it on an sponsored post if I'm not wrong. Add some //comments to state your intentions. Otherwise it's very clever.


The scary part is even when this is satire, there are actual people out there thinking these exact same things.


As a developer i'll quit if I had to maintain code not tested... Naming convention on variables and functions is essential to me too, I use name casting to do so. If you follow your article you end with unmaintainable spaghetti code in my personal opinion.


Why quit? For me, it's a challenge to maintain code not tested. As one of my fellow architect said, "any code that isn't tested, is legacy code". Writing tests for legacy code it's one of my favorite parts of a project. I feel like a little Sherlock Holmes.


Thanks for sharing this Dattatraya, this is one of my favorite post on all dev.to 😂!


Please Don't add anything... I wasn't sure at first until i've read the tdd part XD. It's a nice "take thing into perspectives"


This is why those of us that are professionals will never be part of a profession. There's always one idiot who runs up technical debt.

If I were the Irondale author of this post, if remove it because I would never hire someone with such narrow and short sighted opinions.