Write shitty code(cyclic.sh) |
Write shitty code(cyclic.sh) |
So now, unless time crunch is so bad I have no option (and even then I push back against it to try & get more time to do it right) those are the time I'll cut corners on robustness, readability, etc. I also put a comment in at the top with a deep apology to the angry version of my future self with a reminder if the circumstances at the time. It helps me not pound the keyboard so much in frustration.
You should feel good when you know what mistakes you did because that means you know better now. This process should be iterated a few times.
In a big codebase futureproof is more important, but let's put that aside and talk about quick and dirty standalone programs. Even when talking about the needs of now, ugly code can slow you down significantly. Ugly code takes you longer to debug, longer to see errors, longer to modify, longer to built upon even in the next hour.
So for me it's a matter of writing code that is at least good enough for me NOW, and then I start thinking about futureproof and other maintainers as I get closer to a commit and during pull requests.
` const arr = []; for (let i = 0; i < anotherArray.length; i++){ arr.push(someOperationOnEachElement(anotherArray[i])) } `
instead of
` const arr = anotherArray.map(someOperationOnEachElement) `
Not knowing what your tool/language can lead to hard-to-maintain code. One should always try to leverage the expressiveness and syntactic sugar wherever relevant.
` const arr = []; for (let i = 0; i < anotherArray.length; i++){ arr.push(someOperationOnEachElement(anotherArray[i])) } `
instead of
`const arr = anotherArray.map(someOperationOnEachElement)`
Not knowing what your tool/PL can do can lead to hard-to-maintain code. One should really leverage the expressiveness and syntactic sugar wherever relevant.
code practices languages -> clean code practices articles* can do can lead -> can lead
(There's no edit option for me, so replying:)
The problem: irreproducible results.
Once you chain dozens of command lines, unversioned shitty scripts, no md5 checksum-ed inputs/intermediate results etc. you are in a smelly swamp full of monsters. Even you one week later will not be able to do it again.
Markdown docs/jupyter notebooks are minimum even if one does quick and dirty proof of concept thingy IMHO.
Oh how I can relate do this. I've seen so much guilt and inaction from developers who are paralyzed by "should". They so badly don't want to be a "bad engineer" that they'll over-engineer just about everything and end up causing a lot of problems.
Good or bad code is a learned ascept of an engineer, or experience rather. If you care enough then eventually you will write great code unconsciously with high velocity. Someone's shitty code might be fucking beautiful if they practiced for many years.
My advice is, work in a place with good code review, code quality culture because it really does make the difference. We're unconsciously shaped by our peers.
I hope that screenshot is a joke, cause holy crap! That doesn't look good.
I seriously wish the author is not defending that kind of shittiness.
I am all good with the if(process.env.env !== 'notProd') part, but indentation, come on?
I think this can't be a real piece of code anyways, cause the author would have done console.log('here1'), console.log('here2'), and console.log('here3').
Attempts to do everything absolutely correct are not productive on early stages.
So it's OK to write dirty during search for solution. Anyway it's my personal code on this stage.
But then comes time to publish code. I respect my colleagues, I can't make them read dirty code.
Still, I have never understood why anyone would want to write
if (success == true)
if (success) case result of
Error e -> -- some error handling code
Ok a -> -- the happy pathTo make a medical analogy, I don't know that I would trust a surgeon with a billion operations record and a 50% complication rate more than one with a 1000 operation record and 1% complication rate.
And I certainly would hate to be the colleague inheriting their patient.
The problem is that a lot of engineers try to go the shortest way possible, instead of investing extra effort to think little about the future. They see it either black or white, either shitty or perfect - there is no middle ground. I just noticed that every type of copy/pasting is now ok if your application is using "microservices" architecture. Nobody knows why "microservices" were chosen (as there is no demand for it, nor the implementation of that "architecture" allows them to easily scale), but hell, now we don't need to isolate the common stuff into a single place. And then, when they see some crap, then they keep adding more crap for a sake of consistency.
If it works, there are no plans to extend it and there is no one to read it - then it doesn't matter what it is. I know its good code without having to look
And the article itself is another "should".
Bravo.
I feel code quality is important, not because of future state and optimization but a strong architecture will facilitate other engineers learning, which is critical. For example, not all engineers have learned design patterns like the strategy design pattern or observer, etc (see https://refactoring.guru/design-patterns/catalog for great examples) where a little guidance can save them a lot of pain.
With that said, I understand we all bring different skills to the table. Some people love making every linter pass while others could care less and some actively hate it. This is fine, we just need to respect each other enough to try to build on each other’s strengths and support each other where we’re weaker.
TLDR: Rather than saying it’s fine to write “bad” code, say don’t let code quality intimidate you, and be willing to try. You can always refactor later and you’ll learn as you go.
While it’s fine to feel sorry that they weren’t exposed to it, I wouldn’t personally say I feel sorry as I find it hinders people’s willingness to ask for help. Invite questions don’t make people feel bad for not knowing something you or I may think is obvious. We all were beginners at some point.
I.e. we don't need to talk about it because we all just do it vs not talking about it and not doing it.
But here's the problem:
- In the past five years, it has never failed.
- In the past five years, it has not needed to adapt.
- If I change it successfully, it will make exactly zero difference to my paying customers.
- If I change it unsuccessfully, it will break a core part of the system that people are paying for.
If I were to refactor it at this point, it's really only to pander to my own ego, which probably isn't a sensible business goal.
The code you are talking about here sounds very low drama, which is code that I love.
Maybe we should distinguish between "pretty" code and "shitty" code?
For me, shitty code implies poorly-named variables, confusing logic, brittle tests that couple tightly to the implementation and resist refactoring the code under test, etc. Shitty code makes it harder to understand what is going on, and makes it harder to adapt to new requirements.
At the other end of the spectrum is what I call "gold-plated" code. This is over-engineered, or just overly aesthetically pleasing for a practical and utilitarian tool that will eventually be replaced. It's code that was written to satisfy the perfectionist impulses of the author (we all have these), rather than to add business value.
In the middle is pragmatic, utilitarian code. The level of quality required to be in the sweet spot of course depends on the audience and longevity of the code in question. A language stdlib should be much higher quality in many dimensions than a startup's prototype. So shitty library code might look nicer than gold-plated startup code. It's all relative to your use-case.
In other words, as with about 50% of such thought-pieces that get posted here, I can summarize my objection as "don't give unidirectional advice when you're optimizing a U-shaped error function". You can err by making your code too polished and not polished enough. For a given startup, it might be that the most common error is to gold-plate, and so the advice "make it shittier" is right most of the time. But you're missing the underlying principle if you think that's the right advice all the time.
One of the arts of software development is deciding when it is worthwhile to optimize along some quality axis and how much to invest.
That is, knowing when to churn the code out fast, knowing when to optimize and for and what and when to leave it alone are all much more subtle trade offs than they appear on the face of it.
I've been in the OP's situation before and the shitty code lasted until it's natural end of life successfully.
I've also been in the situation where everything was fine for years and then sudden new business priority changes dictated a slew of simple feature requests we couldnt handle.
As are "it works, so it must be good enough, right?" implementations, when it only works for circumstantial reasons. Code that would fail on encountering single-digit hours is still shitty code even when it works in 0-23 instead of am/pm and happens to never run before noon.
i’ve been told i wrote shitty code because i didn’t use abstract types or generics or i wrote overloaded methods that repeated themselves. but i knew the domain and i knew the task and my code fit within the domain and accomplished the task.
i’ve also supported code that was beautiful, idiomatic, flexible, and downright professional-looking, but it tried to do too much or it had severe antipatterns (especially in data access layer) and was a nightmare to troubleshoot. also, the lead developers on these projects seemed to be far less open to feedback than the people whom i’ve supported who wrote code like i did
I've worked with too many 'architecture astronauts' over the years who over-design everything based on the latest-and-greatest thing they just read online someplace, and make it so complex no one understands how it works, or how to maintain it, and often doesn't do what it was intended.
In my humble opinion, what makes code non-shitty is that it is clear (well named variables, state manipulation is very explicit), well documented, as concise as reasonable, and handles the full range of inputs/outputs properly either by restricting the input/output space via types or assertions.
As originally championed and coined by Ralph Johnson and his protégés at UIUC, it was strictly a (semi provable) safe transformation to the code structure/syntax (usually motivated by trying to make the code easier to understand and/or maintain). Since it was a new word in those days, we still used the terms rewrite and rearchitect as the primary lexicon of “change the code” and “refactor” stated to its niche.
Of course pure refactorings sometimes aren’t as pure as we hope. And they’re often coincident with rewrites and rearchitectures, because we often transform the code first to make a change in behavior easier to implement.
I’m not complaining about the use here. A drop in replacement of an http library would indeed be a true refactoring if indeed none of the externally viewed behavior changed, but as the OP has undoubtedly learned through their own experience, most refactorings end up being something like refarcotring++.
I’m mostly just marveling how in 30 short years, I got to witness the transformation of this term in coumputing lingo.
That, on its own, is a cost, and that cost can warrant a refactor. To go for an extreme:
It's written in COBOL, it is the last cobol code in your entire code base, and the only engineer with any experience in cobol is about to retire.
If that happens, I'd refactor it. If you don't, and 2 years hence the customer calls in a panic that the product they are still paying for isn't working, you're really screwed. I doubt the customer is willing to wait for you to __learn COBOL first__.
But, merely 'the code is not at all written with modern practices and our current team's preferred style and such in mind; it wouldn't pass code review right now?' - yeah, don't refactor that, absolutely.
This is such an underutilized heuristic. I find phrasing the question as “Should we risk having a detrimental impact on customers for an aesthetic desire?” helps me to either get my head straight or to realize that the refactor has genuine value beyond aesthetics.
If it is impossible to understand, but never needs to be understood, it has no cost... Until you or someone else needs to understand it, that is :)
You've just argued that difficulty of understanding times need to understand is cost, not complexity. It doesn't make sense to claim that complexity becomes simplicity if you no longer need to understand it.
I like this. Sums it up pretty nicely.
What you are describing is a perfect code, made for the sake of perfectness.
I made a service that was reliable, but only because there are a lot of ifs inside the code that fixed bugs. It was really shitty code that somehow worked reliably.
The service was replaced because someone else rewrote the whole thing in another language.
But it could be fun! You are aware of the risks, so if you'd really love to do it, knock yourself out! :D
Another perspective: It has occupied your mind for such a long time, why not get rid of it?
Every refactoring comes at risk of breaking something. So if you refactor this code often, you are risking an outage--the very thing you are trying to prevent!
As others have said, if it ain't broke, don't fix it.
It sounds to me like said shitty code got lucky in the tech debt casino. But great! Look at it, so you know how it works, but don't mess with it.
Refactoring is code transformations that don't affect functionality. If something broke, that's a failed refactoring.
All is fine as long as you don't need to.
When somebody change that library without approval, it will be a pandora box.
So it's a ticking time bomb.
> - In the past five years, it has never failed.
> - In the past five years, it has not needed to adapt.
It's not a ticking bomb. The longer this runs, the less likely it will be a ticking bomb. Nobody is trying to adapt the code. Nobody is changing a library.
As with anything in engineering, the answer is always "it depends". I think programmers too often take for granted this idea that all code must adhere to some strict "clean code" rules, or follow some kind of laws or naming conventions or whatever.
That sounds like amazing code, shitty code breaks prod.
> Usually it means spending more time now to make the code better for some future state of the world.
No. That is called premature optimization/abstraction/development and should be avoided. Shitty code is shitty today. Poorly chosen names, copy-pasted pieces, implementation doesn't reveal intent, mismatch in code and comments, etc. Doing these right should be habitual and shouldn't be a function of cycle time. Otherwise, they tend to creep easily.
The startup I work at has been compartmentalizing and chipping away at our shitty code for the past eighteen months. We're not doing this because it offends our aesthetic sensibilities. The shitty part of our codebase is truly shitty. It fails to do its job regularly, causing significant toil in various parts of the business. Junior engineers can't make simple changes to it without causing serious regressions in seemingly unrelated parts of the system. It's slow as fuck. New engineers have to spend weeks reading the codebase if they hope to understand it, and some just give up. There's a big, measurable, drop in velocity whenever we have to work with the shitty codebase. So now we're effectively forced to do an incremental rewrite in order to build new features, which is terrible because rewrites suck and bring their own drop in velocity with them.
In practice, writing shitty code is not all that much faster than writing good code if you know how to write good code quickly - but I guess some people don't bother to learn.
I read somewhere once that at a growing company the next person who works on the code you wrote is highly likely to be new to the company and have less industry experience than you. When you write code, you should write so that that person can work on it productively.
Even better: Learn to write boring code, fast.
There will be exceptions, but those are rare and better resist the urge for abstraction until the very last moment!
For writing without thinking:
> You have to soak up the fundamentals as you practice on your own, studying them until they become a part of your very being. If the fundamentals do not operate subconciously when you sit down to play, you have not mastered them yet.
For fast boring code:
> Go is the kind of game in which you are an expert if you can just keep on making ordinary moves. You need not play any especially brilliant moves at all. Amateurs' moves, however, are frequently far from ordinary; in fact, I see them making the most nonsensical moves imaginable[.]
More here: https://arunkprasad.com/log/kageyama-7-dan-on-amateurs-and-p...
Under-rated comment of the day.
PS: It also seems the author is still early in the learning process, my advice: what you describe are all good programming practices, they're not just useful for the "learning phase", keep them!
Both extremes are awful choices IMO. If the code you are writing is truly unlikely to be extended and adapted then it may be fair to relax your requirements for code quality. As for most things I'd say that applying some discretion to your actual context is more valuable than blanket approaches of embracing bad code.
Code can be good without taking forever and without being over-designed. On the other hand the accumulated effects of shitty code upon more shitty code is unlikely to be a net positive.
Well-designed code can be simple.
My opinion is "do the thing that another developer can understand quickly" is the minimum requirement. Even if the code doesn't work (or has a bug!) at least it has some chance that it can be fixed.
I think the author is conflating two issues, 1) planning for the unknown is impossible and time consuming (true!) and 2) all software engineering practices also make coding slow (false!).
Oh boy...
If masters and geniuses of the past would read the "common-sensical" advice we hear today and how it is being expressed, they would not be surprised by the general shitty state of the world (all civilisations around the world) but to find it plain miraculous that we're still in a semi-funcional way or alive at all.
If you know how to write good code, write good code for the state of the world right now then. Care about the future in the future. Kent Beck taught us this already in a very detailed way two decades ago. Invented Unit Tests in Smalltalk to have fast feedback on regressions frequently and granularly. All languages have that today. Then why in the world do, instead, these software engineer self-serving rationalizations that will accumulate tech debt you're carefully not talking about?
How in the world an unexperienced developer would receive this advice as a propaganda in any way other than a push of self-indulgence for incompetence? How this advice makes you an A player?
I think your intuition is right, the world economy seems to have been hollowed out. Look at medicine, the media, big tech... They all suck. It seems as though they've been promoting idiots intentionally and now idiots are calling the shots.
To choose libraries I won't have to mess with. To DRY up the architecture so I'm not implementing the same thing 5 times in a higher layer that would be trivial in the lower layer.
To not encourage sprawling piles of code by making sure there's one obvious way to to the things that need doing.
Shitty code will just teach me to code. But I already know how to code. I've been coding for a while now.
I don't need to be any better at writing average crappy code. I need to be better at writing bulletproof code that is as close to bug free as it can get, and architecting to prevent the need for shitty code.
Should musicians be lazy in their practice? Everyone outside of tech says you will play how you practice.
So if they encourage shitty code... you wonder if they really are all that committed to making bug free apps, or if they are dragging the old WorseIsBetter anchor.
Works -> Like -> Love
First I write code that works, pretty much by whatever means I can. Sometimes it's great, but most often, shitty is the right word for it. But it works (sometimes, well, sometimes... um...). Then I try to refactor to something that is likable. It's often not perfect at this point because maybe it's not as performant, there are side effects or the api isn't as well designed as it should be. The final step is to really go for something that is lovable, which usually means will not have to be re-written for a while, and often becomes quite re-usable. The nice thing about this approach is that I'm able to get things working quickly (and make customers happy) and it differs optimization until enough is actually understood to optimize.
First pass gets me something that works, then every subsequent pass makes it a little better, like, outlines first, then some colours, then some shading, then some fine details etc
Now if the code is unmaintainable and every change takes 5 times as long as soon it should and introduces 3 new bugs we are in trouble.
Shitty code is almost always unmaintainable. (Unless the shittyness is local inside small functions, but I doubt that's acommon case.) Of course over-engineering and needless optimizations also lead to unmaintainable code.
If the company policy were "Write shitty code" I would run away. I am sure it would lead to absolutely horrible results. At my work we stress the value of good code. Still we end up with shitty code regularly. We just didn't know better when we did it. And we do not rewrite everything once we believe to know better. It's hard enough to struggle with that level of shittyness, I don't want to have it increased fully intentionally. I do that for scripts I will never use again, but not for anything I merge to the code base.
Background: I am writing a novel. In the beginning I sat down and obsessed with every little detail, spending multiple days figuring out the perfect formulation and text flow. And then I would maybe change a little thing in the story-line and have to start over again. This really sucked the whole fun out of the writing process.
Then I changed my approach: I just write whatever comes to my mind, independent of whatever I just wrote before. Doesn't matter if the previous scene had character A as sidekick, if I like character B more, then I simply switch them. Some scene is way over the top and doesn't make sense? Doesn't matter, I write it. Writing is fun again. I sit down, get into deep-work-mode and just write. No constraints, no thinking.
Granted, this is only draft #0 and I will probably have a rude awakening when I have to merge all my writings for the next iteration of drafs drafts, but so far I am rolling!
I find that throw-away code gets my point across much more cleanly without people's objections being raised immediately. Most engineers understand that when I say "throw-away code" it doesn't mean the code doesn't work. It just means that I can _throw it away_ when I need to later. It is "shitty code" because it's _supposed_ to be replaced.
I think the reality, though, is that that day never comes. Usually if something works, it will never be replaced. So the real trick is writing something that finds a perfect balance between "just works" and "elegant/aesthetic/maintainable/readable".
Anything else, that ships to any kind of production environment, needs to be reliable and maintainable.
Shitty code is a false economy. Time savings often fail to materialize if not out right end up costing more in maintenance.
Good code is not something extravagant nor expensive. It’s something simple that just works and looks obvious to anyone who looks at it.
Good code is not over designed code.
The difference between shitty code and good code is often the difference between a prototype and something production ready.
Take the prototype code you wrote, careful think of all the edge cases, maybe test them, rename anything confusing, comment non obvious things if any, and refactor, throw away as much as you can until every line matters.
Good code does not trouble your sleep because you know you did everything you could to ensure it is reliable and even if there is a bug, there’ll be enough info logged and the code is so clear, that fixing the issue will be obvious.
If you’re in the habit of writing good code, you will become better at it with practice and be extremely efficient. If you’re in the habit of writing shitty code, you’ll have to write more shitty code to work around shitty bugs and spend endless time chasing mysterious problems in production.
For me I try to follow two principles:
First, write boring code, and I mean boring, long variable names, no syntax sugar, no clever combination of boolean chains... code that I would use to teach a beginner in the language (or more aptly, future me) how to start coding!
The second is plan to write things twice. This one is a double-edged sword inasmuch as it can help to further clarify or make even more boring the code, or be the place to start adding "optimization" and "cleverness" in the code... I try to stick to the former.
Some of the most valuable code I've written I would call either "hacks" or "scripts", not code, but nonetheless, it solved a real problem instead of being beautiful/elegant or whatever
One thing I hear repeated over and over is: Code is going to change frequently. Well that's not universally true. I don't even think that's true for the vast majority of code in production globally.
If you build an app with one specific, well-defined purpose that iself is not going to change a lot (eq. supporting the workflow of a specific business, managing inventory, etc.) that might easily run for a decade with <10% LOCs ever being touched. I've build dozens of those in my career and I'm certain I'm not the only one.
If you're on the quest for the most beautiful code in this scenario you're wasting your client's time and money for your own vanity.
The more code you write, the more you start to see larger patterns that hinder or improve your system design. You don’t see those things as easily if you are writing bits and pieces slowly. As an aside, writing code in a professional setting can be limiting as well since you may not be able to write code quickly (or shitty) enough to get to a place where you see the effects of your decisions. You’ll write less code and end up focusing on making safe decisions, which means less experimentation in techniques.
But I’m in it for the craft. I want to build and sell super high quality bicycles that ride and look beautiful and will ride for a lifetime.
And for that, every little detail of the bike has to be crafted in a high quality manner.
Sure you could buy a $1500 xerox, but you could also buy a $99 laserjet. Across the N items you buy, a handful will fail or need replacement. they're the things you buy quality versions of.
Oh right, I'd have to ask you about it. And chances are, you're not even working here anymore. https://news.ycombinator.com/item?id=29919428
That said, there are definitely people that swing too far the other way. Some people create abstractions where there doesn't need to be. And they're usually not well thought out ones either.
I wish there was a way for code work like pen/pencil and paper, where if you're doing exploratory work, you can sketch. And it'll look like a sketch for other people reading your code, however that can be indicated. But once you learned enough of the domain, you can firm things up, like you do with a pen to add safety and other constraints.
Where I think the OP is referring to writing shitty code is when coding either purely for the fun of it ... to learn a new technique, or a new language for instance, or when prototyping something - sending out the feelers to see if something you can hack together in a short space of time could be developed into a viable solution (at which point, you'd then start to either refactor it into decent, production ready code, or toss it aside and begin again).
Shitty code definitely does have its place, but anywhere near a production codebase isn't it.
To me it is a lot like writing in a human language. When I am texting someone I am close with there is no reason to avoid slang or to use the best grammar and punctuation. When I am writing my CV it would be advisable to be more formal.
The author of a dime-store novel will write at a different standard than the Encyclopedia Britannica.
My point is that you should write the code that is necessary for the situation and if you are part of an engineering organization the leadership or team as a whole should decide when to use what level of quality and should understand what the trade offs are. There are legit business reasons to write throwaway code when time is of the essence and there are times when you need to take the time to risk over-engineering/over-building something just to be as certain as possible that it won't fail.
I think a lot of code that is described as shitty comes from doing the first step, but due to time constraints the second step is skipped.
Refactoring is part of a cycle and you do it before you publish your code to others. If you don't clean it up, you are wasting someone's time.
This is really helpful.
I think I write reasonably good code. When people who are junior to me ask me, how to differentiate between premature abstraction and writing good code, I don't generally have an answer. This comment made me realise what I actually think while writing code.
I'm working in ML research so I kind of write shitty code for a living. All these problems are small things, that are okay if you just try something new. If it sticks, you'll build on your previous code so the junk just piles up. The challenge is spotting the time when the shit just starts o bog you down.
I don't mean to be perfectionistic. There are certainly cases where “good programming habits” could be compromised. But people tend to excuse bad habits quite easily, without thinking of better ways.
The reality is that good engineering has higher upfront costs than quick-and-dirty. Sure, it's usually cheaper in the long run, but initially it either takes longer to plan or it takes more expensive engineers to execute. And for a lot of startups, getting that cheap MVP out the door is the only path to additional investment.
I'm all in favor of quality engineering, but I'm also pragmatic enough to realize that sometimes you have to sling a little shit in order to gain the luxury of doing it the right way.
> would the startup even exist if they had spent 2 or 3 times as long developing the MVP?
It does not take 2-3 times longer to write good software. Arguably a non-shitty version of our MVP would've actually been faster to develop, because we have a custom web framework, ORM, and build tool when we could've used mature open-source projects in their place.
> it takes more expensive engineers to execute
This is probably true, or perhaps "more carefully selected" (which just means a more expensive recruitment process).
Shitty code is impossible to work on as a team. Only for solo developers. I think shitty code can be fine for bells-and-whistles kind of logic but the foundation has to be carefully thought out. Good code is code which anticipates requirement changes. I disagree with the author of the article that it's not possible to predict the future. You only need to have a very vague idea about different future possibilities in order to be able to design a very good architecture.
Compare the shitty code approach to the good code approach when building a very simple front end application:
---
Shitty code approach:
You happen to know Swift so you just start coding the thing natively in Swift for iOS... Then after 6 months you did a lot of work and you start getting a few users then you figure out that a lot of people are complaining that you don't support Android, so then you start to build the same app again for Android using Android Studio... After 6 months, you roll it out. Then after 1 month users are complaining that the mobile app is unwieldy and they're asking for a web version... You are shocked. You did not see this coming. So then you spend another 6 months building another version of the app with React. Users start complaining that the UI in the web version of the application doesn't match the mobile version... Also, now some users demand a new feature... Now you have to implement it and test 3 times (once for each device), you are wasting huge amounts of resources, your team hates you. You're moving too slow. Your investors decide to cut your funding. Your career is over.
Good code approach:
After carefully looking through the requirements, you figure out that users will probably want to run the app on desktop, web, Android and iOS... So you look at what frameworks support all these platforms... You decide on VueJS with Electron because it's lightweight, has few dependencies and can run on all platforms including mobile. You decide to use CSS media queries for responsive design because it provides a relatively consistent UX/UI accross different devices. You spend 6 month building the app, you ship. Users start using your product, telling their friends about it (who are using different devices)... Some users point out that a feature is missing... No problem, you develop it once, test it once and ship it to all devices at once. Your users love it. Your employees are happy, your investors are pleased, they invest more. Your career is looking promising.
The point the author is trying to make is that trying to build a perfectly designed cathedral of code can often be counter productive.
Another is that we're in a highly competitive industry. Our shitty code is severely hindering our ability to move fast and respond to competitive pressure. Had we paid more attention to quality while building earlier versions of our software we would be building an insurmountable competitive advantage right now.
NB: there are non-shitty parts of our codebase which have been able to evolve effectively as the company has grown. So I have definitive proof it's possible to produce good code at the MVP stage.
I was going to write something similar, so piggybacking. The shittiest code I've seen has always suffered from this.
Sometimes it was shitty (in this sense) because of an assumption that it was "throwaway" code, but it was never thrown away. Gross copy/paste throughout, highly redundant code (same variable, or variable with the same intent, created in many local blocks), mostly existing in mega functions (thousands of lines long) with complex conditional logic to navigate to specific desired sections from the entry point at the top. If it was really throwaway code, then this can be tolerated. But it doesn't require much thinking into the future to replace a 10-line block that's repeated 50 times with one change at each location into a single function. If, in the future, some of those 50 uses of the function need a different function, change it then. Better that than having to keep 50 locations in sync with each other because "making a function now is premature optimization" or "YAGNI!!!". Well, programmer time and delivering quickly has value too. When what would have been a 5-minute task (read function, change function, rebuild, rerun) becomes a 5-hour, 5-day, or 5-week task then everyone is losing out because of the shittyness that was trivially observable and correctable early on.
The other big example of shitty code that is unmaintainable (or becomes unmaintainable) is tight integration between IO and business logic. Without a clean separation, you typically end up with similar repetition to what I described above, or something where a "small" change ends up having massive knock-on effects. This brings maintenance to a crawl as you have to tease out the consequences of that small change, which is non-trivial. That's what makes the code shitty. Corrections and clean separation are often forestalled for the same reason that the previous example often ends up with a mega function instead of a nice, often small, set of utility functions: YAGNI. If your project is going to last more than a few months and has even a modest level of complexity, you will need that clean separation. Otherwise, you end up with increasingly complex (but unnecessarily) code that works around the initial self-inflected hamstringing, or you waste weeks or months cleaning it up and delivering nothing to customers, who become impatient so the cleanup gets cut short and you now have a hybrid mess: half-good code (that will decay rapidly) and half-shitty code (that still can't be maintained).
I like it. Seems broadly applicable to any kind of advice-giving.
That has not been my experience in several industries. Sure, there is always something that is being changed, but once the project matures the changes tend to be at the boundaries or around new features that were recently introduced. A relatively small % of the code is changed each year.
Though, jokes aside, other than refactoring for efficiency, I think you're right. The term "shitty code" generally applies to the readability and not really the efficacy of code. We can usually go back and make it "prettier" with no real practical effect except to make ourselves look better during code review =/
This can be mitigated, look at languages which compile to byte code and are executed with a virtual machine. If it's sufficiently well-defined and stable, then the software can, more reliably, survive underlying hardware changes. Changes to network protocols are often out of our hands, though. Consider the push for HTTPS as well as updates to the HTTP spec itself. A web app from 2003 may or may not function, as written, today. Or it may "function" but users will see random failures (the browser insists on ignoring those HTTP requests for images hosted on another domain, for instance). And even if all the connectivity parts work, you rely on the client to still be able to render things correctly, good luck with your circa 1998 ISP hosted homepage's <blink> tags showing up correctly these days (which is probably a good thing, though).
The more control you have over the system, the less likely your software will be struck by "fatigue". The embedded systems I helped maintain that were written in the 70s and 80s and still running on the same hardware, no bit rot to speak of. Desktop application written in 1995 using Visual Fortran, massive bit rot.
It didn't wear out over time. The design of the seal was bad from the beginning.
But I think any legitimate refacvtoring can be carried out by automatic tools, with guarantees of unchanged functionality/semantics.
The number of refactorings possible for any piece of code is almost infinite; you can't just let some tool loose on your code to perform all possible refactorings. That's madness. You need a human to judge which refactorings are beneficial. But the actual transformation should be performed by a tool that knows the language, and can guarantee semantic equivalence.
And you still need tests. You can scrap them once the refactoring has been shown to have not changed the functionality.
The fact that in some instances this works is not a cogent argument for writing shitty code... there are some places where it is an absolute f-ing disaster!
At my previous place they had an ancient java application that powered their entire business. It had some reasonable parts, but some of it was a total mess from top to bottom. Leaky abstractions, multiple layers of incomprehensible inheritance, helper classes everywhere etc etc, the usual things you expect from a decade old java application.
A fair chunk of the code quite literally hadn't changed for a decade. There were classes written by the first few employees at the company and hadn't changed since that time. Indeed, no time was invested in fixing it because of the 'if it ain't broke, don't fix it' paradigm, which was correct for the first 10 years or so.
One day, there was a huge shift in the direction of the company. They wanted their java application to become multi-tenanted SaaS platform instead of single-tenanted system. I was put to work on the task, and found we had to touch virtually every part of the tech stack. It was an utter nightmare, and frankly we still had to cut corners because it would have taken another 10 years to do it properly.
My point is anyway assumptions are just that, assumptions. Assuming code is never going to change is as dangerous as assuming how could might change and planning for a thousand possibilities. In the case of my previous company, assuming multi-tenancy would be coming along would probably slowed them down significantly and was well beyond the scope of the company at the time. However, if they had spent a bit of time polishing the turds, and putting in place proper testing, it would have made life a hell of a lot easier when strange requests come along.
We have code like this where I work and cases where a change to something has caused that one rock solid process written by an intern in 1998 that few people even remember exists to suddenly start to fail. I would call it a ticking time bomb, and if it's one that will explode in a big way, it might be worth analyzing it to see how it will react to non-obvious parameters or environments.
I mostly agree with you, but 5 years is not very long time either.
The same as what happens with non-shitty code, you fix it.
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
Well, if you don't need to change it (like the GP), most dimensions are moot. We used to call that "maturity", but the entire concept is out of fashion nowadays.
What leads to a correct architecture being probably the most relevant one by a long shot. Because a good architecture is a hard requirement for parts of your code to stop changing (the other being requirements maturity, that is not a dimension of code quality).
But yes, before reaching maturity, there are many dimensions of quality you may want to optimize for, and they conflict between themselves. Also, architecture astronauts get this name because they don't create good architectures, so you don't want them designing it anyway.
Isn't that how you get ancient COBOL monoliths running on mainframes which everyone is afraid to touch?
Haven't you heard horror stories about complete hackery and shitshow (sometimes not even code, but actual company processes) built around them because fixing it might as well have become impossible?