The Economics of Clean Code

Most people have never worked on a long term project applying SOLID principles and DDD and therefore cannot fathom how efficient a team can be when it is applied.<p>Have you ever worked at a company where you join and there is a God class (or two or three) and none of the business people and developers talk the same language. The code does things but you couldn&#x27;t in a million years guess why or how you came about it without having a huge history lesson on the company and its codebase.<p>Now imagine how amazing it is to join a team where efforts are constantly made to name meaningfully and that there aren&#x27;t 8 concerns mixed into a single god class. New devs join and they immediately understand what&#x27;s happening in the business because the code translates directly to the reality. They don&#x27;t have to learn two languages (business and dev speak).<p>Now imagine that dev having to add a grandfather clause to an old account. Where should he put it in the `Account`, `Plan`, `User`, `Subscription` or `Business` class? When the distinction between concepts are clear in the code it&#x27;s easy to determine where the code should go and where logic of different kinds should reside.

I think the problem is that it&#x27;s difficult to articulate what clean code &quot;looks&quot; like. Unfortunately, this is precisely the medium (&quot;looking&quot;) through which many developers learn best. Yes there are books, and rules, and this, and that explaining which properties clean code must exhibit, but for many these rules are simply too abstract when the rubber meets the road. So we start to emulate the &quot;look&quot; of clean code (example are everywhere!) instead of the intent. And you know what happens... a mess.<p>For those of us who have finally made it to the other side of the above process, clean code is more of a &quot;feeling&quot; than a &quot;look&quot;. Of course we can point to pain points in the code and explain why this or that might need to be refactored in order to be more &quot;clean&quot;, but our spidey-sense is our guiding light _not_ some internal catalog of &quot;unclean&quot; code snippets to avoid.<p>For me the most important part of writing clean code is making sure it can be understood (which means it can be changed). And to this end I think Flow Of Control tends to be an important consideration because I have realized it&#x27;s less about &quot;looking&quot; at the code and more about &quot;seeing&quot; the program.

There&#x27;s a difference between a super-experienced, super-senior developer &quot;keeping their code clean&quot; and a junior one doing the same thing.<p>Juniors just thrash around from one design pattern to the next, never really achieving anything other than learning what doesn&#x27;t work.<p>A much more experienced developer will have an understanding about what clean code looks and where it&#x27;s necessary. They will recognise when there is a huge amount of uncertainty, for example, so spend less time writing loads of fantastic code before they&#x27;ve firmed up the requirements.<p>So it really depends on the nature of the project and who you have on your team as to whether you need to worry about &#x27;clean code&#x27;.

From my experience a good thing to do is to set up strong static code analysis (like eslint, TypeScript strict mode, IntelliJ inspections, Sonarqube, ...) when the project begins. This helps to avoid some endless discussions and some bugs. Another upside is, that the rules are enforced automatically what is better than to remind your colleagues each and every time when the break the rules. With a set of rules written down as a config file for a code analysis tool, there is a definition of clean code (even if not a complete one).<p>Starting with overly strong rules and relaxing them later is better than starting with loose rules and tighten them later, because it would require much refactoring to introduce a new rule, whereas dropping a rule is a thing of a few seconds.

Keeping code clean doesn&#x27;t mean architectural perfection. It means architectural consistency. So, if your controllers talk directly to your database, great! Just make sure it&#x27;s easy to do and doesn&#x27;t involve too much boilerplate.

I used to think that clean code was short lined straightforward functions in a nlayer app with logical services ( in general)<p>I can write decent code that is easily readable with that flow.<p>But ever since I integrated DDD and event driven design for splitting up modules for their bounded context, the old code seems not that clean anymore. And I love it, although it caused a lot of refactoring and it is slower to develop, aside that... the code became way more flexible &#x2F; future-proof&#x2F;performant.<p>Even integrating with legacy code-bases is more clear and straightforward. I recommend every Junior to read &quot;preserving domain integrity&quot;.<p>Ps. You don&#x27;t need 4 layers for every bounded api, just use it, when it&#x27;s appropriate ( the smaller the logic, the less you split up) and if you need a quick intro then DDD quickly is ok.

This article sounds much more clever than it actually is. Admittedly it does take time to actually know how to write clean code, but if you can, I&#x27;d argue it takes less time to write clean code than anything else. Especially if you have a great senior engineer who can architect all of the inheritance and fan out the implementation of the adapters to more junior people.

The problem with the word &quot;clean&quot; is that it is a very ambiguous term.<p>It can refer to indentation, identifiers, coherent types, cyclomatic complexity, encapsulation, coupling, modularity, configurability...

I don&#x27;t feel this article brings too much new information to the clean code discussion table. As always, the advice is to strike a balance according to your best judgement.<p>The summary says it well:<p>&gt; don’t over-invest (financially and technically) but also don’t try and outrun the liabilities

I think the author mistakes messy code for technical debt. Even with clean code, you will have technical debt because as the business evolves, your code becomes stale. For instance, your UI might start out simple so you start with just jquery. The code is clean because you didn&#x27;t write crazy long methods, etc. Business keeps adding features to the page and after a while jquery becomes unmanageable. Now you have technical debt.

I think a lot of people forget the last part of, <i>ship the first thing that works</i>: it has to &quot;work&quot; for some reasonable expectations of fitness for purpose.<p>Our short iteration times in software are the envy of many engineering professions but it&#x27;s the fitness for purpose part that nips some of us.<p>I don&#x27;t necessarily believe <i>Clean Code</i> is the silver bullet to avoiding difficult to maintain code but some kind of standard is important. There are principles and patterns of design that are known to be effective which can be useful in guiding a project through the tactical phases from cascading poor short-term choices that lead to long-term technical debt.<p>The <i>economics</i> seem like they should include many more factors. There&#x27;s a time and a place where the effort for a correct-by-construction approach costs too much and the risk tolerance of introducing errors or incorrect behaviors is tolerable to the people funding the project. In such cases it&#x27;s <i>time to market</i> we care about and nobody is going to lose much sleep if you lose 0.0005% of your SLOs over a 3 month window.

&gt; But I’m sure you would agree that before you can have a maintainable product, you should first strive to have an actual product.<p>Actually, no. The goal is to have a sufficiently <i>profitable</i> (or for non-profit use cases, worthwhile) project.<p>It is entirely possible, easy even, to ship a product and gain revenues, but in an unsustainable way that is a net negative to stakeholders, users, or other relevant parties.<p>In the case of &quot;unclean&quot; code, it might not be as bad as ignoring significant security considerations, but it could sink entire business plans, causing negative side effects for people you are notionally supposed to be looking out for: teammates, partners, collaborators, etc. In a for profit business, that often involves wasting investment in the process.

The problem that I observe at my work place is that the spaghetti has moved a level up. The &quot;code&quot; which sits inside individual microservices is mostly fine. However the topology of how those interact is a convoluted, intractable mess.

One of the things that has almost disappeared from these kinds of discussions, is pedantry and feuding over formatting and naming styles. The ubiquity of automatic linters has saved millions of hours of useless bikeshedding.

I’m not sure I buy the “clean code” dogma anymore. If the purpose is to keep the code clean for the sake of the language I think you have missed the point. I think the code should be clean with regards to what it is trying to solve not wrt what language or style you have chosen. Code that is obvious what’s business solution it solves, no matter how messed up that case is is a win.<p>I think it has conway’s law written all over it. And as soon you try to fight that you have lost that battle.<p>Code for the sake of Keeping code clean is wrong, but pretty.

PHP community is here a funny example. Basically an example what happens when you bully coders that their languages sucks. They went for fullblown corporate style clean code rules (slow), for a language used in places where speed is crucial. This language currently is completly suboptimal for business if you apply clean code rules.<p>I&#x27;ve worked in 2 companies that used PHP, where php programmers formed a &quot;clean code religion&quot;. One company died, another lost a lot of money. It was directly connected to the clean code rules - they went over the deadline, by a lot, they created overbloted code(but ok with the rules) that was pain in the ass to work on. &quot;Code is documentation&quot; was repeated like a mantra, which is a pile of bullshit by the way and is not making stuff easier (and I ended up with my own docs anyway). Clean code rules are cool if you don&#x27;t know what you&#x27;re doing and you want to hide it. It&#x27;s a way to say &quot;its not my fault, look I followed clean code rules, my work if flawless&quot;.<p>And coders in those companies didn&#x27;t even noticed that there is something wrong. I&#x27;ve noticed when it was too late. In the second company, on my last day (half the company was sacked cause client got pissed and cut the money), we where in a restaurant eating and talking about programming stuff. Guys (who weren&#x27;t sacked) where discussing a new web page they where working on. The main frontend guy, said he spend 2 weeks perfecting a dynamic menu cause he had some problems with loading time. The guy was rendering the menu in JS, on frontend, record by record. I asked him &quot;if making dynamic menu is such a problem, why don&#x27;t you have it prerendered in a text format, and then load that text when page loads, you won&#x27;t need to render anything?&quot; He replied that this would be against the rules and the code would have to use hack or something. I don&#x27;t know any fucking rule that wouldn&#x27;t allow me to do such a thing. I recognize eyes of a fanatic when I see them, so I&#x27;ve shut up. They solved the problem of menu by displaying users a loading gif when the code waited for menu to be rendered<p>After that day I decided I wont do any PHP gigs anymore. Nor work with something similar in syntax to PHP.

Part of the problem is that nobody agrees what &quot;clean code&quot; looks like. The only objective definition is &quot;code that somebody else can understand as easily as if they had written it themselves&quot;. Which never happens.<p>Follow good rules of thumb like keeping methods short, reuse code rather than cutting and pasting, and write unit tests (and, of course, use spaces and not tabs). Otherwise, all code is as clean as all other code.

I agree, I tend to find myself assuming everything not &quot;clean&quot; is technical debt - putting things in these three buckets has helped (YMMV).<p>1. If you don&#x27;t have users, you don&#x27;t have technical debt (you might have lot&#x27;s of #2 though). You could frag the entire app and the only thing of value (not potential value) lost would be your job. Debt implies value was quickly received in exchange for a flexible re-payment schedule (of time in this case, not money); if the code is not actively being used to save&#x2F;spend&#x2F;gain some resource then that value exchange has not happened yet.<p>2. Correct Code* that is unclean and could be improved in &lt;= time that it took to write is just bad code. Fix this code now.<p>3. Correct Code that is unclean and would take significantly more time to improve than it took to write is technical debt (but only if you have users). This is where a balance needs to be struck between business needs and development needs. Manage this code carefully.<p>*code that correctly implements business logic, incorrect code is always bad - no matter how long it took to write.

I mean, code <i>less</i>. I&#x27;m fine landing in 3k lines of garbage that makes perfect use of some great libraries and platform features. Much better that vs taking ownership of 30k lines of great code that duplicates a lot of stuff that should be imported.<p>Of course, more likely case is that bad code + bad factoring comes together

The problem underlying is fundamentally a bargaining and expectations issue. Sorry for the plug but you should check out my post about time estimates: <a href="http:&#x2F;&#x2F;kyleprifogle.com&#x2F;dear-startup&#x2F;" rel="nofollow">http:&#x2F;&#x2F;kyleprifogle.com&#x2F;dear-startup&#x2F;</a>

&gt; But I’m sure you would agree that before you can have a maintainable product, you should first strive to have an actual product.<p>The assertion that proponents of clean code make is that the fastest way to the end goal (in the ~6 week window) is with high internal quality[1]. If your project is &lt;6 weeks, then do whatever. If you think you&#x27;ll be around longer than 6 weeks, then make it clean.<p>[1]: <a href="https:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;is-quality-worth-cost.html" rel="nofollow">https:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;is-quality-worth-cost.html</a> --&gt; Not Robert C. Martin, btw.

I have Malcolm in the middle look on it... (senior dev)<p>There is business reality - parents (expect miracles, but don&#x27;t put enough effort pushing it to Malcolm, because he is smart) There is developers reality - Reese (they think everyone else is stupid but not them) There is testers reality - Dewey (they trust developers too much) There is customers reality - Francis (business had high hopes for them but it turns out they were wrong)<p>How does it come to clean code? In reality there is no clean code as we would like there to be. There is only messy reality. Uncle Bob is a salesman selling dreams and promises.

Fancy title, with content everyone knows. Meh!

Simple trade-off: the more &quot;clean&quot; your code is, the more it will benefit when others&#x2F;future-you reads it. If it&#x27;s a quick one-off or if it&#x27;s just for you, the value of &quot;cleanliness&quot; is far less than the value of speediness and responsiveness to client.

Has there been a post-2000 company that has succeeded with no one complaining about tech debt?

Its likely wrong to apply a template Rule to every single project. For a small project, no this would not necessarily apply. An experienced lead knows When to apply what and not just go by single principles

Cool metaphor of “well balanced and nutritional dinner” vs “fast food.”

&quot;We are in too much of a hurry to do a good job.&quot;