--- title: "Ugly Code Means Your Product Used to be Successful" url: "https://osherove.com/blog/2013/6/4/ugly-code-means-your-product-used-to-be-successful.md" canonical: "https://osherove.com/blog/2013/6/4/ugly-code-means-your-product-used-to-be-successful.html" published: "2013-06-04T12:27:04" updated: "2013-06-04T12:27:04" tags: ["Other", "Unit Testing"] author: "Roy Osherove" description: "I have now worked at a bunch of companies, and consulted for quite a few. I have looked at some pretty horrible code. Every company I visit with say the same thing: “Yeah, but our code really sucks. “ It does not suck…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Ugly Code Means Your Product Used to be Successful By Roy Osherove June 4, 2013 In [Other](https://osherove.com/blog/category/other), [Unit Testing](https://osherove.com/blog/category/unit-testing) **Historical article** · Originally published June 4, 2013; technical details may be outdated. I have now worked at a bunch of companies, and consulted for quite a few. I have looked at some pretty horrible code. Every company I visit with say the same thing: > “Yeah, but _our_ code _really_ sucks. “ It does _not_ suck any more than other code I have seen. It usually sucks just about as much. Do a thought experiment: Of the ugly code you’ve seen, _when_ was it written? How long has it been alive?  Most of the time, I have seen ugly code that started a good few years ago. I have also worked in companies that practiced TDD and unit testing, and still had ugly code. Their code did NOT start out with unit testing, and was just as untestable and hard to read and lots of the code you see in your own place. If you ‘hack away’ code and it suddenly becomes successful, you hack away even more. and then suddenly, it is 2 years into the product’s life, and now it is becoming increasingly hard to maintain. NOW you also realize your code really sucks, because it was never intended to be a long lived piece of code, it was always a type of experiment to see what would happen; Would people _really_ like it? And then they did, and then there wasn’t enough time except to take money, fix patches and live. And now it’s time to pay all that technical debt, and that is a good thing, because if you find yourself in technical debt,  it means your product has gone through its trial by fire, and now it is growing up to become a real boy. So do not feel bad your code **used** to suck. You’re doing something about it now, right? it was just in its puberty, when you needed to focus your efforts on making sure you’re on the right path. When I am in a startup, I usually do not write tests until I feel that - I know how to build what I am trying to build. - I know customers _really want_ what I want to build. - I know the code I write will live more than a month. Until then, I think of things as a big prototype, but unlike other places, I am not afraid of throwing it away, but I am also not afraid to accept the fact that some hackity crap code will enter during the experimentation process. Does this mean you have permission not to write unit tests? YES, IF the main focus in your head is to get feedback that you are building the right thing. Once you know it is the right thing, not doing automated tests is very foolish. ## More in Other [All posts in Other](https://osherove.com/blog/category/other) - Jul 29, 2007 ### [Hire me for a day: Two Opportunities](https://osherove.com/blog/2007/7/29/hire-me-for-a-day-two-opportunities.html) - Jun 1, 2007 ### [Why I won't be switching to Google RSS Reader](https://osherove.com/blog/2007/6/1/why-i-wont-be-switching-to-google-rss-reader.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/