3 ms·

I have been in both kinds of companies. 20 years ago, having none of these basics was almost the norm. It can work, and sometimes I even miss those days, becaus

I have been in both kinds of companies. 20 years ago, having none of these basics was almost the norm. It can work, and sometimes I even miss those days, because it can be fun and very fast paced. However, it also comes at a price. There's a constant, high stress level because things break all the time, even on production, and you have to be quick to fix them, often directly on production. I wouldn't want to go back, especially not with a bigger team or today's average developer and project complexity. And it sounds like you already made your decision. Unless there are compelling reasons to stay (and maybe try to introduce newer practices), you have learned a lesson which questions to ask in your next interview (also google for Joel Test) and try to find something new.

collyw 6y ago
I think it's fine until your product and team reaches a certain size. Our product is currently beyond that point but out tech lead still carries on adding more stuff and not adding any tests.....
OldHand2018 6y ago
> 20 years ago, having none of these basics was almost the norm I guess I worked at one of the best then. It still went out of business.
- tjansen 6y ago
  I just read the almost 20 year old Joel Test page for the first time in a long while and I was surprised by what it didn't contain. For example, it doesn't even mention unit tests. Which is no real surprise, because JUnit itself is only 23 years old. Things like code coverage tools didn't exist back then. And while there were some early tools for automated builds, like Mozilla Tinderbox, setting them up was a real challenge.
  - OldHand2018 6y ago
    Code coverage and automated testing tools existed and were mature when I started at my now defunct employer 20 years ago. In The Soul of a New Machine [0] (published 40 years ago) such tools were used and the author wrote about them without any indication that they were new or novel. Every new generation of developers thinks that the "old days" were primitive, but that's just not true. [0] https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine
  - ChrisMarshallNY 6y ago
    Unit tests are definitely plenty old. I think that maybe folks aren't quite clear on what "Unit Test" means. Nowadays, "unit test" means a test written into an existing test harness system, like JUnit or XCTest (what I use). In fact, I was writing unit tests for PHP-based Web apps and C++-based Mac software more than twenty years ago. I just had to write my own framework. Even nowadays, I sometimes write my own framework. For example on my [hopefully] last PHP project, I designed a SaaS-type system, and eschewed PHPUnit; mostly because it would need some special installation that might be beyond the ken of the target users. Instead, I wrote my own test harness system, and it worked great. It wasn't a crazy amount of extra work. I always create massive tests, anyway, so it wasn't that big a deal. For my Apple/Swift work, I rely on XCTest, which is a perfectly acceptable test harness. I'm pretty sure that unit tests were mentioned in Writing Solid Code, which is almost 30 years old.

collyw 6y ago

I think it's fine until your product and team reaches a certain size. Our product is currently beyond that point but out tech lead still carries on adding more stuff and not adding any tests.....

OldHand2018 6y ago

> 20 years ago, having none of these basics was almost the norm I guess I worked at one of the best then. It still went out of business.

tjansen 6y ago
I just read the almost 20 year old Joel Test page for the first time in a long while and I was surprised by what it didn't contain. For example, it doesn't even mention unit tests. Which is no real surprise, because JUnit itself is only 23 years old. Things like code coverage tools didn't exist back then. And while there were some early tools for automated builds, like Mozilla Tinderbox, setting them up was a real challenge.
- OldHand2018 6y ago
  Code coverage and automated testing tools existed and were mature when I started at my now defunct employer 20 years ago. In The Soul of a New Machine [0] (published 40 years ago) such tools were used and the author wrote about them without any indication that they were new or novel. Every new generation of developers thinks that the "old days" were primitive, but that's just not true. [0] https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine
- ChrisMarshallNY 6y ago
  Unit tests are definitely plenty old. I think that maybe folks aren't quite clear on what "Unit Test" means. Nowadays, "unit test" means a test written into an existing test harness system, like JUnit or XCTest (what I use). In fact, I was writing unit tests for PHP-based Web apps and C++-based Mac software more than twenty years ago. I just had to write my own framework. Even nowadays, I sometimes write my own framework. For example on my [hopefully] last PHP project, I designed a SaaS-type system, and eschewed PHPUnit; mostly because it would need some special installation that might be beyond the ken of the target users. Instead, I wrote my own test harness system, and it worked great. It wasn't a crazy amount of extra work. I always create massive tests, anyway, so it wasn't that big a deal. For my Apple/Swift work, I rely on XCTest, which is a perfectly acceptable test harness. I'm pretty sure that unit tests were mentioned in Writing Solid Code, which is almost 30 years old.