5 ms·

When I started at my current job 9 months ago (with me, there are now two programmers in the team), there was no bug tracker or formal version control. We still

When I started at my current job 9 months ago (with me, there are now two programmers in the team), there was no bug tracker or formal version control. We still regularly edit the code on live servers for some bug fixes. The first two were (barely) workable for a one person team and got fixed once the team grew, and the third is honestly the right approach for the kind of software we write. The user base for most of our products numbers in the dozens, and I'd rather get a prod bug fix out there as soon as possible rather than having to mess with commit;cd $prod_dir;pull -u or having to deal with the complexity of having too many code environments. I have not yet succeeded at getting a proper testing framework in place - too much hassle dealing with selenium and we don't yet have enough tests written to justify spending more effort. It's the initial capital investment that'll make it worth it, but I just haven't gotten around to it. Rather work on building an actual product that'll add direct value rather than just saving my ass. These are all practices that in a larger team, or with a larger user base, or with higher requirements, would be untenable. But they work for us, for now.

freshhawk 14y ago
I've certainly been in that same situation and made the same choices (version control/bug tracker a must, tests would be great but no one finds the time and once it's been left a while then it never gets done). It was a defensible choice at the time. I learned my lesson though, retroactively adding proper deployment practices is pretty easy, adding tests later is freaking impossible. It's harder to do later when the code isn't fresh in your head (or you didn't even write it) and it takes a lot of time to write tests for legacy code and getting approval to take that much time away is near impossible. Now I pay the 5% tax to do things right and develop features 2-3 times faster long term. (Those numbers are based on pulling some numbers from my work logs and time sheets a while ago, they are very rough and small sample size on a project where there was legacy code with no tests and new code with tests). To go back to my point though, it's not some rabid devotion to some pet philosophy that would make me think seriously about starting a new job somewhere where they don't test. It's because I've done both and I like my job so much more when I don't have to deal with the bullshit that comes from years or even just months of developer laziness (often my laziness). I can spend more time concentrating on creative problem solving and actual features and less on debugging fragile code.
- mkopinsky 14y ago
  At this point, I'm not convinced that not testing necessarily leads to laziness. In my job I deal with a fair amount of legacy code, and definitely find anecdotally that I work several times faster on new code, but that's because the legacy code is crap and the new code is clean and brilliant (just like all code written by yours truly). (Of course, the fact that the code is new and is being edited by the original author are the primary drivers, but I think my code quality is slightly better than my predecessors'.) Once the code is well-written, I don't think that adding tests would significantly improve my productivity. Having a test suite would give me confidence and save me time doing manual testing (no need to test features I haven't touched and am not worried about), but don't see it having a major impact on my development productivity per se.
  - freshhawk 14y ago
    I meant that laziness leads to not testing. And the "bullshit' that arises from not testing are the bugs and regressions that happen after you role out anything new that isn't completely self contained. "Once the code is well-written, I don't think that adding tests would significantly improve my productivity" Yeah, if you never touch that code again then it would not, I agree. I don't have many modules or classes that never change though. I suppose there might be other types of programming where that's not the case.

freshhawk 14y ago

I've certainly been in that same situation and made the same choices (version control/bug tracker a must, tests would be great but no one finds the time and once it's been left a while then it never gets done). It was a defensible choice at the time. I learned my lesson though, retroactively adding proper deployment practices is pretty easy, adding tests later is freaking impossible. It's harder to do later when the code isn't fresh in your head (or you didn't even write it) and it takes a lot of time to write tests for legacy code and getting approval to take that much time away is near impossible. Now I pay the 5% tax to do things right and develop features 2-3 times faster long term. (Those numbers are based on pulling some numbers from my work logs and time sheets a while ago, they are very rough and small sample size on a project where there was legacy code with no tests and new code with tests). To go back to my point though, it's not some rabid devotion to some pet philosophy that would make me think seriously about starting a new job somewhere where they don't test. It's because I've done both and I like my job so much more when I don't have to deal with the bullshit that comes from years or even just months of developer laziness (often my laziness). I can spend more time concentrating on creative problem solving and actual features and less on debugging fragile code.

mkopinsky 14y ago
At this point, I'm not convinced that not testing necessarily leads to laziness. In my job I deal with a fair amount of legacy code, and definitely find anecdotally that I work several times faster on new code, but that's because the legacy code is crap and the new code is clean and brilliant (just like all code written by yours truly). (Of course, the fact that the code is new and is being edited by the original author are the primary drivers, but I think my code quality is slightly better than my predecessors'.) Once the code is well-written, I don't think that adding tests would significantly improve my productivity. Having a test suite would give me confidence and save me time doing manual testing (no need to test features I haven't touched and am not worried about), but don't see it having a major impact on my development productivity per se.
- freshhawk 14y ago
  I meant that laziness leads to not testing. And the "bullshit' that arises from not testing are the bugs and regressions that happen after you role out anything new that isn't completely self contained. "Once the code is well-written, I don't think that adding tests would significantly improve my productivity" Yeah, if you never touch that code again then it would not, I agree. I don't have many modules or classes that never change though. I suppose there might be other types of programming where that's not the case.