7 ms·

Very senior developers know things that are not intuitive, but very true. So I'll let you in on a few secrets. "Good enough is always good enough". You probabl

Very senior developers know things that are not intuitive, but very true. So I'll let you in on a few secrets. "Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less. Clean code doesn't mean "no bugs" and "good software": - I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example). - I've seen a terrible mess of code, that was practically bug free (because it was running for years in production). And have seen that same code refactored to clean code by a junior (who thought he would 'fix things'), and introduced a lot of bugs (because that is just what happens when you write code, even clean one, even by a senior developer). If you deliver a final product (such as a game for example), that will not need extra features, you can hack stuff in at the end. When you would hack code together at the start, you will shoot yourself in the foot by needing to go through your mess all the time. But when you do this at the end of the project, you can save time by adding in quick hacks. The technical dept that you introduce doesn't need to be paid off. Of course you cannot do this with a long running project. But with a deliverable product go right ahead. The main thing that you have to consider is this: EVERYTHING IS A TRADE-OFF. I see juniors make this mistake all the time, selecting the best programming language, the best VCS, the best whatever. You know, that 'best' thing also has drawbacks. So it's always about making trade-offs, selecting something despite the drawbacks, because of the benefits. General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet. How to make the proper trade-offs? Experience ;).

carlmr 8y ago
>- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example). Are you sure that wasn't an optimization to get "LTO" with a non-LTO linker?
- Asooka 8y ago
  No, in that case you would #include all your .c files in one .c file and compile that for release, but would otherwise work in the usual manner. CMake actually has builtin support for doing just that.
  - carlmr 8y ago
    That would be a nicer way to do it, but it doesn't contradict what I said.
    - paulddraper 8y ago
      Any halfway decent developer that wants single file optimization but doesn't want to author the source code in one file will do this. See "Unity build".
- koonsolo 8y ago
  I talked to the developer, and it was him who mentioned this, and he was not proud of that part ;).
skohan 8y ago
> Clean code doesn't mean "no bugs" and "good software" This gets missed too often: clean interfaces are important, whether it's a UI or an API. Clean code? It depends. I once interviewed a dev who had all the right answers when it came to software development practices, TDD, etc, but when we looked at the product he was working on, the UX was a stuttering mess. I don't care what your code looks like if you did not achieve a good end-product.
- fredrb 8y ago
  > don't care what your code looks like if you did not achieve a good end-product. I do care if your code is a mess if other engineers have to maintain it.
  - skohan 8y ago
    I'm not saying clean code is not desirable. Code which is easy to maintain and modify is absolutely better than messy code. My point is that "good code" should be prioritized behind a good product. The purpose of code is to deliver a product, not to be well-factored or to embody certain principals. If your product is bad, your code is already categorically bad, no matter how beautiful it is.
    - ensiferum 8y ago
      But it's really difficult to make a good product and good product experience on a messy code base. Quality code leads to better product IMHO. (of course good quality code base can still suffer from badly designed UX)
      - skohan 8y ago
        The devil is in the details. Sure, if your codebase is systemically messy, it's probably going to take forever to get anything done, and you will probably end up with bugs in the final product. But what if you have a component here or there with well defined, well tested interfaces, but internally it's a bit of a mess? Or what if you hack together a proof-of-concept for a new feature to get it out the door and see what users do with it before investing a lot of time in making it perfect? Those kinds of things can help your organization move faster. As with most things, clean vs messy code is not a binary. It's the sum of a lot of individual value judgements about when it's pragmatic to focus on code quality.
lmilcin 8y ago
Very true, I agree on all points. I would add the amount of effort put into designing and polishing any project that you can defend is correct is related to how much future development and use the project will see and how critical the project is for the company. So, if you want to work o a nice quality project or want to spend a lot of your time on improvements to quality find yourself a project that will either see a lot of future development or a lot of future use or is extremely critical to the business or, best, all of these characteristics. I see this mistake happen all the time -- people complaining on quality, disparaging previous developers or demanding effort to improve it just for quality sake ("because I just read this book and it can be done better") without reasonable arguments to support from business POV. Also I see people categorizing all project deficiencies as technical debt where what they should be doing is to first establish what would be reasonable expectation regarding quality and then the debt is only what would be absolutely necessary to reach that reasonable expectation. So for example, if you make a small app that will not reasonably see a lot of future development but is critical to work reliably in production (and it isn't) your debt would most likely be centered around making the application reliable enough and probably not around making the code nice (as long as it isn't preventing makeing the application reliable).
dullroar 8y ago
Agree with all points. Here's another - depending on the size of the shop and the population of users it will be delivered to, there are trade-offs that must be made as you go towards zero on both of those axes. For example, if you have two developers delivering in-house apps to 250 end-users in a SMB company, then the answer is never, "That will take two years and $2M." It is, "We can have that for you in a month," and then you deal later with things that necessarily got skipped. Sometimes it means refactoring and bug fixing, if the pain points to the business are large enough. Sometimes that may mean reaching into a database to fix data that is caused by a complex bug that only manifests itself once a year and isn't worth fixing outright (because there are other things you're working on now). That outlook is probably way to "Realpolitik" for the purists, but it is reality in small shops (which still do exist).
marcosdumay 8y ago
> General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet. And that, of course, has it's exceptions too. Non-optimized stuff exist, and everything that isn't on the optimum line can be improved in some way without drawbacks. Besides, the optimum line is always moving.
- koonsolo 8y ago
  So you optimized some code, cool! - How certain are you that you didn't introduce a bug? - Is it also running faster on this exotic platform that we still need to support? - Did it involve API changes? - Do we need to put this into production now, or wait for the next optimization to save some time? - How much time did we spend on this? Was there something else that would have made a bigger impact? In theory you can improve things without drawbacks, but in practice you always have to make the right trade-offs.
  - marcosdumay 8y ago
    Just to point, my comment wasn't about code optimization (but can apply to it too).

carlmr 8y ago

>- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example). Are you sure that wasn't an optimization to get "LTO" with a non-LTO linker?

Asooka 8y ago
No, in that case you would #include all your .c files in one .c file and compile that for release, but would otherwise work in the usual manner. CMake actually has builtin support for doing just that.
- carlmr 8y ago
  That would be a nicer way to do it, but it doesn't contradict what I said.
  - paulddraper 8y ago
    Any halfway decent developer that wants single file optimization but doesn't want to author the source code in one file will do this. See "Unity build".
koonsolo 8y ago
I talked to the developer, and it was him who mentioned this, and he was not proud of that part ;).

skohan 8y ago

> Clean code doesn't mean "no bugs" and "good software" This gets missed too often: clean interfaces are important, whether it's a UI or an API. Clean code? It depends. I once interviewed a dev who had all the right answers when it came to software development practices, TDD, etc, but when we looked at the product he was working on, the UX was a stuttering mess. I don't care what your code looks like if you did not achieve a good end-product.

fredrb 8y ago
> don't care what your code looks like if you did not achieve a good end-product. I do care if your code is a mess if other engineers have to maintain it.
- skohan 8y ago
  I'm not saying clean code is not desirable. Code which is easy to maintain and modify is absolutely better than messy code. My point is that "good code" should be prioritized behind a good product. The purpose of code is to deliver a product, not to be well-factored or to embody certain principals. If your product is bad, your code is already categorically bad, no matter how beautiful it is.
  - ensiferum 8y ago
    But it's really difficult to make a good product and good product experience on a messy code base. Quality code leads to better product IMHO. (of course good quality code base can still suffer from badly designed UX)
    - skohan 8y ago
      The devil is in the details. Sure, if your codebase is systemically messy, it's probably going to take forever to get anything done, and you will probably end up with bugs in the final product. But what if you have a component here or there with well defined, well tested interfaces, but internally it's a bit of a mess? Or what if you hack together a proof-of-concept for a new feature to get it out the door and see what users do with it before investing a lot of time in making it perfect? Those kinds of things can help your organization move faster. As with most things, clean vs messy code is not a binary. It's the sum of a lot of individual value judgements about when it's pragmatic to focus on code quality.

lmilcin 8y ago

Very true, I agree on all points. I would add the amount of effort put into designing and polishing any project that you can defend is correct is related to how much future development and use the project will see and how critical the project is for the company. So, if you want to work o a nice quality project or want to spend a lot of your time on improvements to quality find yourself a project that will either see a lot of future development or a lot of future use or is extremely critical to the business or, best, all of these characteristics. I see this mistake happen all the time -- people complaining on quality, disparaging previous developers or demanding effort to improve it just for quality sake ("because I just read this book and it can be done better") without reasonable arguments to support from business POV. Also I see people categorizing all project deficiencies as technical debt where what they should be doing is to first establish what would be reasonable expectation regarding quality and then the debt is only what would be absolutely necessary to reach that reasonable expectation. So for example, if you make a small app that will not reasonably see a lot of future development but is critical to work reliably in production (and it isn't) your debt would most likely be centered around making the application reliable enough and probably not around making the code nice (as long as it isn't preventing makeing the application reliable).

dullroar 8y ago

Agree with all points. Here's another - depending on the size of the shop and the population of users it will be delivered to, there are trade-offs that must be made as you go towards zero on both of those axes. For example, if you have two developers delivering in-house apps to 250 end-users in a SMB company, then the answer is never, "That will take two years and $2M." It is, "We can have that for you in a month," and then you deal later with things that necessarily got skipped. Sometimes it means refactoring and bug fixing, if the pain points to the business are large enough. Sometimes that may mean reaching into a database to fix data that is caused by a complex bug that only manifests itself once a year and isn't worth fixing outright (because there are other things you're working on now). That outlook is probably way to "Realpolitik" for the purists, but it is reality in small shops (which still do exist).

marcosdumay 8y ago

> General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet. And that, of course, has it's exceptions too. Non-optimized stuff exist, and everything that isn't on the optimum line can be improved in some way without drawbacks. Besides, the optimum line is always moving.

koonsolo 8y ago
So you optimized some code, cool! - How certain are you that you didn't introduce a bug? - Is it also running faster on this exotic platform that we still need to support? - Did it involve API changes? - Do we need to put this into production now, or wait for the next optimization to save some time? - How much time did we spend on this? Was there something else that would have made a bigger impact? In theory you can improve things without drawbacks, but in practice you always have to make the right trade-offs.
- marcosdumay 8y ago
  Just to point, my comment wasn't about code optimization (but can apply to it too).