Speaking of programming...
...
Yeah, a huge part of the problem is our policy on testing: the developer is responsible for that as it's being developed. He (we're all guys here at the moment) just fixes everything he comes across, finishes developing, thinks of ways it might break, and tries to fix it all before too much time has been spent on it and he has to move on to something else. That is, testing is 100% informal. Nobody here but me even knows what a unit test or integration test or regression test even is. QA consists of the other devs poking through the system briefly and making sure nothing obvious is broken. Then we wait for complaints to roll in and fix things as they're reported.
That largely stems from the fact that we work almost exclusively on intranet software and tools. If they're buggy, nobody really cares. They just come yell at the devs to fix it and we do. Or silently ignore it and let bugs hang around for years.
When you combine that development practice with public facing software that can cost people money, bad stuff happens. What's even better is when you don't have a dedicated development environment and can
only work on live code. We had to take the system down for a day because we couldn't develop anything without breaking the live site.
Even better is that our partner relies on this system to send emergency notices to people in the event of disasters or the like, so that part of the system had to remain online as we worked,
whatever the costs. So you can imagine how jittery I got when I broke that for multiple hours before I got it back online. Thank goodness they didn't try to use it in that time period.
I've advocated formal testing many times. Every time I do, the response is, "Yeah, we should definitely do that." Then we don't. As the one who knows something about how it's done, I guess it's my job to sort of spearhead that change. We've tried using development sites in the past but never really made use of them. It was just too annoying to work on the dev site, then copy the fix or changes over when you could just do it straight on the live site. Even now, after finally using Git for source control, we do the same thing. Git's just a way to keep track of code changes; the work is still done on live code and committed after the fact.
The problem of course, is that we've just got way too much to do. 3 developers and a huge mound of things that needed to be done yesterday don't leave a lot of room for experimenting with new technologies or methodologies.
I've considered trying to work on that some in my free time, but I am
not turning into my manager who works almost every waking hour of his life.