This thread made me realize that it's better to have a working profitable project with bad code, than a perfect unfinished project, with meticulously chosen design patterns.
Afraid of being judged for bad code, I could not start until I had the right architecture.
I'm glad I read this.
This is developers therapy.
* Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress.
* Team B deliberates and deliberates. They try to avoid taking shortcuts. But in the end, even their code doesn't have the strongest tests, doesn't generalize for all the known use cases, etc. Team B never gets users or gains momentum, and their code+architecture was probably no better than Team A -- they just took 3x the time to get there.
I had a lot of trouble trying to explain this to juniors.
The most important things is to have code that is easy to refactor when you know what you're doing (i.e. everything is working properly). Juniors I worked with had a nasty definition of a pretty code being split into a hundred files, each no longer than a screen, and each function no longer than 5 lines. The onboarding of new devs to such code was way worse than into a code that would be 10k lines in one file, but with a flat structure and less interdependency.
Very true.
I'll just add that another most important thing is to actually take time to refactor, even when things are busy.
I spend maybe 1/3 of my time refactoring, and that feels good.
Once you know it works take a minute to clean up and make the changes fit your preferred style, extract repeated code into shared methods, comment the tricky bits, etc.
I had an "everything should be broken into a hierarchy!" stage back when I was learning to code, and boy was I off track. In my defense, at the time (and this dates me) OOP was all the rage.
Procedural spaghetti is more manageable, though I once had to update a C app with a 3000 line case statement. Pure madness.
Golang does a good job of addressing this one particular problem.
In a subsequent project we banned subclassing of exceptions.
But... isn't the easiest way to show that there is little interdepency to put them in separate files that don't import from each other?
This whole post is about how refactoring doesn't matter because your project's development lifetime isn't long and wide enough for maintentance to matter.
It makes debugging in Java or C# an exercise in face shredding frustration. Where each class is in a file, it's better to structure the class consistently with other classes in the project, and things like naming conventions become a lot more important.
You could argue that the C/C++/Java/C# languages are fundamentally broken because they don't encourage the succinct, small class methods that Smalltalk did, but you could also argue that those small methods don't necessarily work very well in a different class of languages from Smalltalk and neither approach is really more productive than the other, with the caveat that Smalltalk is largely dead and irrelevent to modern programmers other than a curio.
Just starting and doing it is just unreasonably effective because very few projects actually need novel solutions - most are just fine with off-the-shelf hacked together solutions.
Thinkers are required if the software is actually groundbreaking new work. Almost everyone's work on this forum probably isn't that however (mine included), which is why I agree with your sentiment
This is the dumbest part. You’d think that someone documented something when they originally built it, but nooo. Don’t even know the requirements, just that it has to be the same as the previous one.
It sounds like your CTO did not just operate quickly, but also sloppy and chaotic. From what I am gathering from this thread, the best practice is to move quickly AND organized such that refactoring is reasonable.
Team C works like team A. However every time a feature ships, someone who knows that feature well immediately refactors the relevant code to remove the prototype scaffolding. When code becomes static, an expert adds good quality comments. When a bug is found, it is recreated in a regression test prior to being fixed for good.
Hack at the code for 4 years, collect your options and leave the mess to someone else.
To be honest, a hacky codebase written fast is not the worst codebase to deal with. The worst type is when someone had the time to overarchitect and overengineer things.
Following references across 200 different files, tracing calls through hundreds of microservices. Graphql servers with complex resolver logic.
I concur. Refactoring should be as much about removing unneeded abstraction and features as it is about adding same.
> there is little incentive or bonuses for improving the situation.
Yeah, I just can't seem to believe this in my soul. I just want to fix ugly code and can't stop myself. I get huge satisfaction from speeding up, tidying up or fixing up bad code.
It doesn't help when management wants to minimize time spent on such tidy-up, especially when it's hurting our productivity to maintain it without fixing it.
1. Figure out what needs doing and what code you need to use
2. Refactor the code you're using until the new code or change is easy
3. Make the change
4. Tidy and document.
Repeat
I often also document during step 1, while I am trying to understand code and realise that comments are missing.
The beginner uses simple chords
The intermediate uses advanced chords, crazy fills and runs and riffs.
The advanced uses simple chords
Intermediate devs write code that is over-engineered in places where it could be simple, while still needing a lot of extensive refactoring in the parts that deal with irreducible complexity.
Expert devs think deeply about the problem at hand, understand where the complexity is, and create a solution that is as simple as possible, but no simpler. After the fact, beginner and intermediate devs tend to think of this code as something trivial, that anyone could do.
This is why it may sometimes be tactically useful for the expert dev to sometimes take on projects that some beginner or intermediate team has been struggling with for some extended period of time, analyze it properly, and show how elegant the difficult parts can be solved.
Care is needed, though, as it can affect the morale of the other devs and even cause hostility. If the expert dev has a secure position in the organization and want to keep those other devs around, keeping a low profile as well as letting those devs take as much as possible of the credit is adviced.
Also when someone from Team A initiate the code and Team B takes over, there were few times that Team B feels like the code is damn no good and just massively refactor it with what they think is good (re: the boilerplate) without others' concern. Then when Team B leaves, it goes to 1st paragraph..
I think as a team we need to consider the learning curve of our own code cz we don't code for ourselves.. And it's good to know the tolerance & acceptance to 'structure' of the code from other people..
But ultimately, Maddy Thorson isn't selling a block of code. They're selling a game and it has extremely satisfying control of the character. And that's all that really matters for a player controller.
Maybe better organization and design patterns could have made it faster to develop? But I don't believe it would.
But also the type of product does matter for this. Celeste had 2 programmers so a lot of the things necessary for a team of 100 devs would just be harmful. If you're making a library/framework to be used and modded by others, architecture matters a lot more. If you're designing an enterprise application that you know will need business logic customizations for 25 business customers it matters more. It's all about knowing the scope of your project. But also until you start getting that many customers, maybe the unsustainable method is what will allow you to reach those first few sales more quickly to be able to stay in business long enough to be bit by the technical debt.
Laster on Noel Berry did give a response explaining the various design choices behind their code:
https://github.com/NoelFB/Celeste/tree/master/Source/Player
Anyways, kudos to the team sharing their code even if it's a bit messy.
The new shiny services took much longer to identify bugs and add new features due to the complexity of the design and endless interfaces.
I'm so afraid of creating programs in languages that don't enforce a structure at all, even though I know how to write everything from scratch make it work.
If it's some framework, then it'll already be structured somewhat.
In the rare event that I do create something with no frameworks, I ensure that there aren't much global variables.
apparently jwz decided not to be linked from here :/
there's an archive.org link below.
NOT SFW! https://cdn.jwz.org/images/2016/hn.png
It's funny. Why does he hate us so?
For future reference, a non-archive, non-jwz.org link. Straight from the source as that's the author's own site.
Then just copy & paste it.
A lot of businesses were built on PHP this way
I was so afraid to cook in a dirty kitchen, I ended up not cooking at all.
This thread made me realize that's better to sell food prepared on dirty surfaces with unrefrigerated ingredientes half-eaten by rodents and roaches that makes people sick, than fresh food prepared on clean surfaces with clean utensils.
I'm glad I read this.
This is a restaurant worker story.
I was so afraid of not using the right construction materials and not building code-compliant structures, I ended up not building at all.
This thread made me realize that's better to sell houses with structural problems and low quality materials that will be unsafe to live in, than houses built according to code.
I'm glad I read this.
This is a builder story.
"Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with.
Using bad ingredients in food, or poor quality materials in construction has tremendous impact on the final product.
>"Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with.
Just calling code good or bad doesn't mean much - ultimately, results matter - if your code doesn't have tons of bugs, if your team can add features without any problems, if you can ship reasonably on time, if your product delivers value to the end user, etc - then you have succeeded. It doesn't matter what outsiders think about the code or what labels people give. Its best to ignore them and continue doing good work.
Failure is cheap in our industry. That's largely a very good thing.
Also all of your examples have wildly different impacts than a dev "portfolio project". They all cause physical harm to people, which a poorly coded website/cli tool/etc almost certainly won't. Unless this person's hobby is writing code for MRI machines, in which case, go ahead and make everything is perfect, but that doesn't seem to be the case here.
Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering.
Ok, so let's continue this analogy on the other one.
It's less like basic hygiene, and more like refusing to cook outside a clean room.
> Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering.
Basic development good practices are something you develop during the "portfolio building phase", not before.
Your entire point rests on a baseless assumption. There's absolutely nothing in the parent's post that indicates that the programs he would create could have the potential to harm humans.
That is a really sad statement that is predicated on the assumption that nothing can be objectively compared and therefore nothing can be ranked, which is also a way to kill arguments that lead to innovation and iterative improvement.
You can measure the complexity of an algorithm, you can measure the cyclomatic complexity of a function, you can measure code in terms of length, you can count references to external functions or modules, etc.
There are many ways in which you can compare code and make decisions about what style is more convenient for your team.
What is clearer for you to understand?
a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1
b) 12
If your argument was true, they would both be the same. We both know that a) is a waste of time.
If you take any style guide, book about good practice, or stuff like that, you'll find that there are some good ideas, and there are some bad ideas. Even with something as simple as code formatting, we still don't know as an industry if it's better to format everything the same, or use formatting to convey information. The debates about OO, FP, static/dynamic typing are endless and there's no evidence about which is better. There is a rough idea that you need more organization when more people work on code (static types, microservices, more documentation, more isolated parts), but even that isn't really clear.
My assumption is not that "nothing can be objectively compared and therefore nothing can be ranked". It's not even an assumption, it's what I've seen in this industry: we lack data to give objective good practice that go beyond anything trivial ("try to make code easy to read and simple", "give meaningful names to your variables"). There is a wide gap between "common sense" and "cargo cults", which is the gap between easy and complex topics. I would really like if in the last 50 years we had learn a lot about how to build software as an industry, as people. The reality is that we haven't.