3 ms·

To counter the flood of 'you sound reasonable', I think you are probably being unreasonable. The hint is "spaghetti code". What might have happened is you sta

To counter the flood of 'you sound reasonable', I think you are probably being unreasonable. The hint is "spaghetti code". What might have happened is you started slagging off everyone's code as soon as you've come in and now you're plucking at straws to justify it as you're getting ostracized. Also, objectively speaking, how can writing MORE code and spending MORE time talking to people be faster? Your argument makes no sense. Tests and reviews are a massive drag on development, also more code means more bugs. That we know. It would take years to get full test coverage and somehow you think that makes everyone inherently faster? Also, ask yourself this, how much money have they lost so far by doing this? Is it perchance $0? Zero downtime? As you've not listed a single actual COST of what they're doing. While direct to prod/connect to prod db is nuts and not normal, you also haven't given the context of who did that and why they did that. Is there really no staging server? No Dev branch?

mb20 6y ago
I think it is faster in the long term because well tested code is less likely to contain bugs, and reviewed code more maintainable as it adheres to an agreed upon standard. So it may be longer in the short term, but faster overall as you have to revisit the code less due to these reasons.
anthony_r 6y ago
I take it you've never worked in that type of an environment, with code review and (good, not necessarily perfect) test coverage. I am working in an environment like that and I regularly push 20-40 changes per week. There's no problem with speed. Furthermore, had there not been tests (and not just unit tests; the important stuff is large scale performance tests and output differs) I would never be able to push code out so quickly.
- mattmanser 6y ago
  I can regularly push 20-40 changes per week, with or without tests. What's special about that? How can writing MORE code be faster? Be honest with yourself, you know it's slower, it's hard to get right, and it's easy for many programmers to end up writing really bad tests that hinder rather than help. Certain orgs might be able to pull it off, but generally speaking it's cargo culting.
  - UK-Al05 6y ago
    It works because tests provide you with incredibly fast feedback if your change works or not. Then you can confidently and automatically deploy to prod straight away without much manual checking.
strzibny 6y ago
It's faster, because once the code is reviewed and deployed, it most likely works. And test ensures that this functionality stay in place with (almost) no bugs. The opposite is a shitshow that looks fast to inexperience people...
Aqueous 6y ago
working in a large company with tons of spaghetti code and i can assure you it’s a real thing and that it not only slows you down it can actually strangle your company. making sure no more of it gets to production has become a top priority company-wide
- lazulicurio 6y ago
  Yep. Worst application I've ever had to work with was a WinForms monstrosity where ~300 form elements were used to store the application state, and none of them were named (so it was all "TextBox1", "TextBox2", etc.). Most of the application logic was in a single ~8000 line method. An absolute nightmare to debug or modify.
nocitrek 6y ago
I am much more comfortable refactoring my codebase and gradually raise standards of quality of it because of unit tests. If I change piece of code I will know if I modified key functionality of my software. When someone else is editing the code, he is also confident that the module he did not work on is still working as expected. He does not need check up with me and waste mine and his time. I am not sure why would you test your code manually. Total redundancy.

mb20 6y ago

I think it is faster in the long term because well tested code is less likely to contain bugs, and reviewed code more maintainable as it adheres to an agreed upon standard. So it may be longer in the short term, but faster overall as you have to revisit the code less due to these reasons.

anthony_r 6y ago

I take it you've never worked in that type of an environment, with code review and (good, not necessarily perfect) test coverage. I am working in an environment like that and I regularly push 20-40 changes per week. There's no problem with speed. Furthermore, had there not been tests (and not just unit tests; the important stuff is large scale performance tests and output differs) I would never be able to push code out so quickly.

mattmanser 6y ago
I can regularly push 20-40 changes per week, with or without tests. What's special about that? How can writing MORE code be faster? Be honest with yourself, you know it's slower, it's hard to get right, and it's easy for many programmers to end up writing really bad tests that hinder rather than help. Certain orgs might be able to pull it off, but generally speaking it's cargo culting.
- UK-Al05 6y ago
  It works because tests provide you with incredibly fast feedback if your change works or not. Then you can confidently and automatically deploy to prod straight away without much manual checking.

strzibny 6y ago

It's faster, because once the code is reviewed and deployed, it most likely works. And test ensures that this functionality stay in place with (almost) no bugs. The opposite is a shitshow that looks fast to inexperience people...

Aqueous 6y ago

working in a large company with tons of spaghetti code and i can assure you it’s a real thing and that it not only slows you down it can actually strangle your company. making sure no more of it gets to production has become a top priority company-wide

lazulicurio 6y ago
Yep. Worst application I've ever had to work with was a WinForms monstrosity where ~300 form elements were used to store the application state, and none of them were named (so it was all "TextBox1", "TextBox2", etc.). Most of the application logic was in a single ~8000 line method. An absolute nightmare to debug or modify.

nocitrek 6y ago

I am much more comfortable refactoring my codebase and gradually raise standards of quality of it because of unit tests. If I change piece of code I will know if I modified key functionality of my software. When someone else is editing the code, he is also confident that the module he did not work on is still working as expected. He does not need check up with me and waste mine and his time. I am not sure why would you test your code manually. Total redundancy.