The Economics of Clean Code
frederickvanbrabant.com
frederickvanbrabant.com
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'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.
Now imagine how amazing it is to join a team where efforts are constantly made to name meaningfully and that there aren't 8 concerns mixed into a single god class. New devs join and they immediately understand what's happening in the business because the code translates directly to the reality. They don't have to learn two languages (business and dev speak).
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's easy to determine where the code should go and where logic of different kinds should reside.
Maybe we were just interpreting things wrong, but it was very difficult to agree on what those principles meant in practice.
Liskov's substitution principle is also rather complex. I'm not sure I correctly understand it, but I think it is widely violated even by good code. If I have it right, the principle means the result of your program cannot change, no matter what subtype you substitute.
class Base {
virtual int size() { return size_; }
...
class Derived : public Base {
virtual int size() { return rand(); }
...
Derived should act like a Base with slightly different implementation details. This is all LSP is. It's a fancy phrase for a very simple concept.
As I understand it, Java's Object.toString() is an example of an LSP violation because different subtypes of Object return different strings.
An LSP violation of toString() would be something that returns a string that doesn't represent the object. If you were to return the current time as a string for an object that has nothing to do with time, that would be an LSP violation.
> Subtype Requirement: Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T.
Why is the exact value of the string returned not a provable property? And, to your example, if a provable property is that the returned string represents the object, how did you know it was a provable property? And how do you prove it?
The rule seems very formal, but your notions seem very informal, and I don't know how to reconcile them.
Their notions are informal, but on some level it's just the experimentalist's interpretation of LSP -- much how some physicists (loosely) argue that if you can't make measurements to prove a theory wrong then the theory doesn't matter, it might similarly be reasonable to ignore LSP with respect to properties that you don't care about (where that definition is fuzzy and hard to pin down but should represent a definitive class of things within any given single program). E.g., most people don't rely on toString() doing much more than giving a bit of human intuition into the type and properties of an object, so any implementation which respects that behavior satisfies a realist's LSP.
For those of us who have finally made it to the other side of the above process, clean code is more of a "feeling" than a "look". 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 "clean", but our spidey-sense is our guiding light _not_ some internal catalog of "unclean" code snippets to avoid.
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's less about "looking" at the code and more about "seeing" the program.
Juniors just thrash around from one design pattern to the next, never really achieving anything other than learning what doesn't work.
A much more experienced developer will have an understanding about what clean code looks and where it'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've firmed up the requirements.
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 'clean code'.
Then I point out that, if they just refactor to a single method that's 20 lines, they can read it from beginning to end and it makes sense.
In any case, I think the core issue is really how much faith you have in the proficiency of your teammates. If you can't trust the developers in your team to actually only write functions that do what they say in the name (without nasty side-effects), then I can see why not having all the logic in front of you in one giant function can be annoying - you have to jump into all the definitions and manually double check to be sure what's happening.
I've been thinking about this a lot lately actually. At some level, when you create a hierarchy of classes and/or a collection of objects, you're deciding that some logic is best implemented with that set of objects and the way they talk to each other as the fundamental building block. It's very much like designing a language; you're designing the lego bricks and then putting them together to make something. The hope is of course that you're going to be able to use those lego bricks in other situations by composing them in different ways.
Where I think we can go wrong is in getting stuck on the one abstraction type; particularly in this case it's falling into a mindset where the only way to compose software is by comnposing objects. Yet at some level, you're going to be composing your logic out of function calls (or what essentially look like them). You need to know at what level you're building and viewing the system. Sure, you can build a set of objects that you can then use to build some other logic that's implemented by their composition and collaboration, but sometimes maybe all you need is a method that implements this logic more directly, using function calls and their results. From far away, it's OOP with objects collaborating via messages; from up close, it's just procedural (or even functional) code with restrictions on the state it has access to.
This mistake I think is embodied in a sentiment I used to pick up on a lot at the tail end of my CS education (around the time Java was really starting to come into fashion). It was a sentiment I'd describe as something like "OOP has superceded procedural programming". To which I'd always want to ask the question "but what about inside your objects?"
For this reason, it's better to prefer as little structure as you can reasonabley get away with, not more. Now, this is a nuanced view, a senior person can absolutely insist on more structure up front and avoid issues, but they'll have a good reason for doing so that doesn't involve "it's clean code".
But in general, you want as little structure as you can get away with. It's a lot easier to change something that hasn't been abstracted to death with guesses about what the future is going to hold.
I think part of the issue is a perspective thing. If I spend a day throwing something together and it sits for 6 months, great. I got ROI from that code. If 6 months in new requirements come in and I decide I need to rewrite it, who cares. It worked day in and day out for 6 months off a days worth of effort.
Too many people view code as needing to be long lived and unchanging.
There's a lot of social pressure that pushes people to view code as a thing that's either done and permanent, or not done, unfinished and therefore unacceptable.
It's called imperative programming. Funny how rarely you see the word.
I don't think code reuse is itself a bad thing, but it can easily be overused and cause far more confusion than benefits.
Developers do deep work with a framework which ties them to a specific language and the accompanying ecosystem. So, what you see is the "not invented here" syndrome, and how already solved problems are tackled again in that specific ecosystem.
Many solstices ago, I was a PHP developer. If you'd ask me to split a 2.55 Gb CSV file in several CSV files as a one-off request, I would have fiddled with a PHP script, because that was my bread and butter. Probably would have taken something like https://csv.thephpleague.com/ off the shelf to get the job done.
Well, no, you can do exactly that in a single line with tail, head, split and cat.
Since I moved away from PHP, I have come to find a new, deep respect for the already existing general purpose commands which are part of the Unix spec. And reflecting on my earlier work, I realize that I could have solved some challenges a lot quicker.
Now, this is not a stab at clean code or PHP. Both are valuable tools.
Rather, a big lesson for young developers is that the cleanest code out there... is the code you didn't write at all, as you leverage what's already there.
You can't, because csv records may span multiple lines. So dicing them with standard tools may subtly break them. Unless you know your particular CSV data only has single line records.
(I take your broader point though. It's just that CSV is a bad example, because you usually wind up needing specialized tools to deal with them. It's likely that your PHP script would actually be more correct!)
To GP: also - CSV headers. Still possible in one line of shell, but it is starting to get unwieldy.
I should have mentioned another lesson for junior developers: learn to understand the structure of your data and avoid making assumptions about formatting.
I disagree. First 20 lines in a single block means that any single line can have interact with any other. The 19th line's behavior can be subtly influenced by what's on the first line. That means it's not just an issue of reading line-by-line. You have to keep every line in the entire code block in working memory simultaneously.
The limits of human working memory is about seven or eight chunks. When functions get longer than this, they take exponentially longer to understand. 100 lines of code broken up into 25 line functions can take ten times longer to understand than 1000 lines of code broken up into well-abstracted four line functions.
I couldn't put this into the words as well as you did, I know myself one of the turning points of realising I had become a better developer was learning from those who taught me how to identify the design patterns and how to build up requirements.
Clean code is usually less important than a good structure, if you have bad deverlopers or a lot of juniors, your processes should be in place to not allow them to go too far off course. This is what really improves the development time and the maintenance.
The messy code is usually localised to a small area and if a refactor is required, its much smaller.
This isn't the main thrust of Sandi Metz's famous "All The Little Things" talk, but it's front-and-center in the approach she takes to cleaning up the code. Half the talk - basically all the parts where she keeps mentioning, "You'll notice our complexity metrics are still getting worse even though the code is getting better" - largely consists of getting the way the software models the business domain whipped into shape.
Or, to go full analogy, no number of trips to The Container Store will leave your house feeling clean and organized if half your possessions are junk that you don't need and the furniture arrangement is awful.
I think it's consensual by now (at least 'round these parts) that we've gone too far with clean and patterns and being too clever for your own sake (or that of your company) and even agile (once management took the concept over and changed it to its very opposite, kinda like democracy nowadays versus the Ancient Athenian spirit if you think about it). It's all pop culture by now, see that Silicon Valley show.
The most tragic, in a sense, is that the people who created those concepts, who formalized them (extreme programming, uncle Bob, etc) very clearly stated that these are not "hard rules" and cannot work as such, ever — like we say "it's a 6" or "it's a 2" by instinct, there's no science there, no genius, just practical methods.
The minute it became some sort of KPI the whole essence turns sour, possibly detrimental to the mission.
When you approach things this way, with this prior or meta-knowledge so to speak, you can very much apply "clean code" principles to an otherwise very domain-driven model and software architecture; in fact one could argue you're making a true mathematical model — which is really not about people and compile times but about exactitude, precision, an as-honest-as-can-be mapping of a real phenomenon. Had we built physics like we approach "great code" nowadays, we'd have much prettier formulas that approximate truth in abstraction but never quite reach it. A treat for theoreticians, a nightmare for people with real-world, industrial problems.
Indeed. Keeping code "clean" is more about how it represents the concepts and relationships it is dealing with and less about whether it follows any specific style rules. In my experience, code that is easy to understand and maintain often has a relatively simple design that stays close to its problem domain as much as possible.
Of course, good style is still important, and being able to write tidy code when you have to move away from the real world concepts and get into the implementation details is also important. However, without some overall structure that reflects what the software really does and how it's used, it's easy to lose focus and concentrate too much on the supporting cast at the expense of the stars of the show.
I really disagree. To take a prime example, short functions are almost always better than long functions. Regardless of the content, codebases that are refactored into smaller, more self-contained functions almost always improve in reliability, performance, readability, and extensibility.
I think the reason for this largely comes down to reducing the surface area of interactions. A 100 line function can introduce subtle interactions between the first and 99th line. Whereas a three line function, the graph of potential dependencies is much smaller.
A similar logic extends to smaller, more self-contained code blocks, classes, modules and even applications.
only if you can also divide and conquer the amount of persons that will dev, because now when there was one name to learn and assign meaning to, there are ten different names.
I am speaking as someone who used to have a hard limit on function length (20 lines, in Allman style :-) ) - this ended up being really harmful and creating way too complex code sometimes.
To give you an example, when using Java's stream functionality, I tend to insert every method call in the chain after stream() in a new line, for readability:
...
entityIds.stream()
.map()
.filter()
.collect();
...
Interesting. And what happened with the other 97 lines of code? A fair comparison would be a 100 line function and maybe 20 functions of 5 lines and maybe 20 additional lines for function signatures plus maybe 20 lines coordinating the 20 functions. We also then have introduced 20 function names.
This one is so very disputed, though.
My own sense is that it's not the length of the function, it's the length of the loops and the complexity of the branching. Short functions help when they prevent those from occurring. But, in cases where neither is present, I haven't seen a refactoring to short functions that I thought was an unambiguous improvement. Even that variable from line 1 influencing line 99 doesn't end up being particularly difficult to see or understand as long as the control flow is linear.
The more lines of code that exist in a block, even with linear control flow, the exponentially higher chance that one line inadvertently clobbers something that subsequent line depends on. Consider a function like
def foo (msg: str):
head_index = find_header(msg)
... # 50 lines of code
log(msg, head_index)
... # 50 lines of code
return msg[head_index]
def foo (msg: str):
head_index = find_header(msg)
...
head_index += offset_digest(...) # Needed for log formatting
log(msg, head_index)
...
return msg[head_index]
An engineering culture that emphasized small functions avoids this problem, because the change would instead move the logic to its own self-contained function. That avoids the problem of new code accidentally clobbering the old code.
def foo (msg: str):
head_index = find_header(msg)
...
log_offset(msg, head_index)
... # 50 lines of code
return msg[head_index]
def log_offset (msg, head_index):
head_index += offset_digest(...)
log(msg, head_index)If a variable is declared at the beginning of a block, its use has to be audited throughout the entire block. It's a lot easier to confirm that a variable is never mutated across 4 lines than it is across 200.
When the size of a code block exceeds the capacity of working memory (about 8 chunks), then devs will skip the cognitive effort and fall back to the most permissive types by default. Not always, but bugs mostly come from the codebase at its worse, not its best.
Considering your point from the other direction, the most mutability disciplined codebases tend to naturally bias towards short functions. In my experience most long functions are long, because the locally-scoped variables are being used to haphazardly track statefulness across the control flow. To contrast, Haskell's immutability and purity strongly restricts that pattern. Unsurprisingly, one of the most striking features of Haskell codebases are how short the functions tend to be compared to something like Java.
Well, if the variable is declared at the beginning of the block and is scoped to the entire block, we have two possibilities.
One is that the variable really is relevant throughout the block, or close to it. In that case, full mutability makes it more difficult to understand the behaviour, but if the variable is immutable or can only be mutated using explicitly controlled tools then the audit you mention is trivial.
The other is that the variable is only relevant to some relatively small part of the block. In that case, it is possible that the function is trying to do more than one thing and that part of it could beneficially be separated into its own function, taking any variables that are only relevant to that part with it. It is also possible that the variable is being declared prematurely and starting its lifetime earlier than necessary, in which case it may be better to move the declaration later so its lifetime is shorter and the area where it is in scope is reduced.
The latter cases do tend to lead to shorter functions, or at least reduced scopes, and for good reasons.
However, what you can't do is magically take a mutable variable that is genuinely relevant throughout some algorithm that really is complicated enough to require 200 lines of code to describe it, say the current state of some fundamentally complicated state machine, and make that complexity go away just by factoring out smaller functions. You're still going to have to pass the variable or some equivalent around, and you're still going to need to mutate the state in lots of places. But now your logic for doing so is scattered across 50 4-line functions, and to establish the true behaviour you don't just have to audit one of them, you have to audit them all and all the code that connects them.
It's even easier when the language you're using doesn't let you mutate or rebind in the first place. You mention Haskell codebases having short functions, but that isn't an automatic given. Haskell and other ML languages are quite friendly to long functions specifically because the language guarantees no mutation, among many other reasons.
In fact, the Elm project explicitly tells Elm developers to not worry about the length of functions because of this property. You can't accidentally mutate or change something and not notice, because you simply aren't allowed to do that.
This is a popular claim in some circles, but I don't think it stands up to scrutiny.
As others have observed, while you may gain locally through having simpler individual functions, you may also lose globally because you now need to manage the complexity of how all those functions relate.
There seems to be very little evidence to support the argument that shorter functions are objectively better, and if anything the evidence we do have suggests that extremely short functions are objectively worse in terms of things like defect density.
I would rather argue that functions should do one thing well. This will tend to correlate with shorter functions rather than 100+ line behemoths, but the important thing is that a function represent a single, coherent idea. Maybe that idea can be expressed as some neat one-liner in a functional programming language. Maybe it's some 200+ line ordered sequence of conditions that systematically determines how to shift between states in a state machine that is modelling a fundamentally complicated situation.
I contend that one of the ways a junior developer becomes a senior developer is learning about what works and what doesn't that comes from thrashing about in a codebase. They're being paid less than the senior folks so don't worry about them thrashing about (and pair with them using an open and inquisitive mindset to help them think through the consequences of their changes).
Not every situation requires the same level of verbosity and be structured in the same way, for example.
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.
Horizontal slices give you something like the classic monolithic three-layer architecture, and vertical slices give you more of a component-based approach.
The big trick is to know which approach you're using, and stick to it. In a layered architecture, you absolutely do not skip layers, but it's generally fine to have one layer talk to pretty much any part of a neighboring layer. In a component-oriented architecture, it's really not a big deal IME to let controllers talk directly to the database, just so long as you never let one component directly access another component's schema. You get data out of other components by talking to their public interfaces.
As long as you color within those lines, things won't get too tangled. If you're really worried, I suppose you could try doing both vertical and horizontal splits, but my impression is that that always places the application at risk of collapsing under the weight of its own bureaucracy.
I can write decent code that is easily readable with that flow.
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 / future-proof/performant.
Even integrating with legacy code-bases is more clear and straightforward. I recommend every Junior to read "preserving domain integrity".
Ps. You don't need 4 layers for every bounded api, just use it, when it's appropriate ( the smaller the logic, the less you split up) and if you need a quick intro then DDD quickly is ok.
Both are for microservices, but just replace microservice with module and it's the same thing. Just less of an devops overhead since it's in one application.
Please take time to familiarize yourself with the concepts first.
Domain events ( = broadcast important changes. Eg. PayPalPaymentConfirmed, CustumerEmailChanged ). Tip: this is important for having a lovely coupled legacy integration ( eg. For an anti-corruption layer )
Cqrs instead of inserts and edits in one IService/ILogic.
Handlers and Mediator ( c# library)
Events for combining logic ( something like Nats supports 5 million messages/ second)
correlationId and excellent logging should be your number #1 priority.
DDD is better for a NoSql backend than a Sql one. Although I prefer MartenDb though, using it by default as NoSql ( BSon) and using duplicated properties for performant searches, so I don't need a Search Service, NoSql allows you to quickly store your Bounded Contexts.
Accepting duplicate data on different domains and handling it with replaying events.
Database per service ( or at least table), do not integrate as you would do before in SQL.
Clean architecture is a good fit ( domain.core, domain.infrastructure, domain.application and if you want a microservice, add domain.api )
Event Storming for discussing new projects with domain experts.
If you want to read about it, try DDD quickly, it's quick to read.
There is one downside and that is that there are a lot of patterns. But coming from a guy that hated the word ( but applied the concepts), it becomes very quick to communicate with other teams and discovering their entire architecture within 10 minutes.
That's just my 2 cents though, since it's literally adapted to fit my needs.
lovely coupled legacy integration, had to be loosely coupled :)
It can refer to indentation, identifiers, coherent types, cyclomatic complexity, encapsulation, coupling, modularity, configurability...
The ideal clean code of course has proper indentation, self-explaining identifiers, coherent types, minimal cyclomatic complexity, perfect encapsulation, perfect coupling, perfect level of modularity and perfect level of configurability. To which degree we want to achieve the ideal and to which degree these individually factor into it varies from project to project.
The summary says it well:
> don’t over-invest (financially and technically) but also don’t try and outrun the liabilities
I think people conflate clean code (readability) with code refactoring. For the sake of readability I don't think having clean code matters much... but refactoring I think can be important depending on the complexity you're dealing with. But even then, I'd only worry about refactoring when it comes time to worry about it. Usually I find that's when the scope of the software grows by some factor, or when you foresee it growing by some factor and you find it cumbersome to add simple features, yet a simple refactoring would make the addition of features much easier.
So IMO, the importance of "clean code" depends on the complexity you're dealing with. Always having clean code just for it's own sake seems unnecessary...
Suppose the ideal clean code base. There is of course no stale code there. In the event of new business requirements, it has been reconsidered carefully and rewritten to cover the new requirements in a way that's architecturally consistent. If that was impossible with some previous iteration of the architecture, the overall architecture has also been reconsidered and changed.
For your jQuery example, with unlimited resources available to address code smell, you'd of course either replace it with some existing higher level library that suits your use case, or you'd write your own high-level generalizations. I have seen a lot of code that was terrible not because they had unwieldy business requirements, but frankly because the code had poorly considered abstractions and unclear boundaries. Features were added without consideration for the architecture. Quick and dirty fixes were considered preferable to overhauls. Short term workarounds ended up being long term don't-touch-this-we're-not-sure-what-it's-doings. What worked at some thousand LOC became the guiding principle for further additions.
The real problem is that rewriting or cleaning up can become unbearable for some combinations of organization and code base. It takes time and can become an organizational hurdle if people are simultaneously implementing new features or fixing bugs. Every time a developer says "this will take several weeks to implement" and the project owner successfully insists that it can't, the code base gets dirtier. In the real world some PPM of fecal matter is acceptable because getting the last few particles out is going to increase the cost by an order of magnitude.
Our short iteration times in software are the envy of many engineering professions but it's the fitness for purpose part that nips some of us.
I don't necessarily believe Clean Code 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.
The economics seem like they should include many more factors. There'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's time to market we care about and nobody is going to lose much sleep if you lose 0.0005% of your SLOs over a 3 month window.
Actually, no. The goal is to have a sufficiently profitable (or for non-profit use cases, worthwhile) project.
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.
In the case of "unclean" 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.
I think it has conway’s law written all over it. And as soon you try to fight that you have lost that battle.
Code for the sake of Keeping code clean is wrong, but pretty.
I've worked in 2 companies that used PHP, where php programmers formed a "clean code religion". 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. "Code is documentation" 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't know what you're doing and you want to hide it. It's a way to say "its not my fault, look I followed clean code rules, my work if flawless".
And coders in those companies didn't even noticed that there is something wrong. I'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'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 "if making dynamic menu is such a problem, why don't you have it prerendered in a text format, and then load that text when page loads, you won't need to render anything?" He replied that this would be against the rules and the code would have to use hack or something. I don't know any fucking rule that wouldn't allow me to do such a thing. I recognize eyes of a fanatic when I see them, so I've shut up. They solved the problem of menu by displaying users a loading gif when the code waited for menu to be rendered
After that day I decided I wont do any PHP gigs anymore. Nor work with something similar in syntax to PHP.
Programmers should not have the responsibility to decide these things on their own; it should come from the companys risk assessments and help with the goal of the company, not the goal of the programmers (which is to put neat things on their CV.)
This is spoken as a programmer, by the way.
Normally you need a senior dev with a sense of pragmatism above them all to smack down any attempts to straitjacket the coding below/around them.
I use PHP a lot, simply because there's so much of it out there (lots of work), and one of the firsts thing I often do when taking on a project from another vendor is rip out any "no space at the end of the line" linting garbage and the like. As always in life, it's not about swinging for one side (vomitcode) or the other (anal styleguides), but achieving balance.
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.
You can find people who'll disagree with you on every point in this list. So yeah, nobody agrees what "clean code" looks like.
(Not TDD, mind. It apparently doesn't matter much whether you write tests first or second, just that you write them at all.)
Neah, that's not it. You can write crappy code, as hard to understand by others as it is to understand by you - in fact, that's what happens more often than not. It's not that you understand it but nobody else does - it's that in 1month, nobody understands it.
The objective definition that I like is "code with no incidental complexity" where "incidental complexity" is as defined by Rich Hickey (see "Simple made easy").
> Follow good rules of thumb
Those are not necessarily great rules of thumb, though. There can be too many unit tests, or bad unit tests. And it may be more appropriate to test something at the component level, or integration level. The rule of thumb for a good test is that it should test the business logic as opposed to current implementation. Or that it should not be non-deterministic (e.g. don't test with random data unless you can save the inputs that caused the failure, and reproduce it later; if you can't and just e.g. add a random amount of delay in your tests, it's not a great test).
1. If you don't have users, you don't have technical debt (you might have lot'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/spend/gain some resource then that value exchange has not happened yet.
2. Correct Code* that is unclean and could be improved in <= time that it took to write is just bad code. Fix this code now.
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.
*code that correctly implements business logic, incorrect code is always bad - no matter how long it took to write.
Of course, more likely case is that bad code + bad factoring comes together
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 <6 weeks, then do whatever. If you think you'll be around longer than 6 weeks, then make it clean.
[1]: https://martinfowler.com/articles/is-quality-worth-cost.html --> Not Robert C. Martin, btw.
There is business reality - parents (expect miracles, but don'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)
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.
Sure there is. You want clean code, here you go: