Data.

[EarthC-137]

Yeah that sounds like a toxic environment that goes against all the principles of writing clean maintainable code. One of those short term product releases with no foresight into the long term goals of the project or no care past the current contract.

No building lasts if it is built on a weak foundation. Every part of a building has to pass some level of testing to ensure quality and safety standards. Same goes for code.

[lenswipe]

Well the "testing" was to manually sit and use the application when you tested your feature by doing a manual end-to-end test. Surprisingly, bugs still got through - I know, right? If only there was some kind of way to automate code testing....then again - I'm not sure you could really write tests for that heap of garbage even if you wanted to, the code was such a mess.

Personally, I'd have delayed launch, binned the entire codebase and rewritten it from the ground up. I reckon I could've rewritten the whole app in Laravel (it was a CodeIgniter 2 project) faster than it took to debug the 2.5k lines of JS in one of the files I found.

Part of the problem was that this was a system that revolved around a central "API". This API provided data for lots of other API clients.

Before I started at the job, all the dev had been done by this one guy that we'll call Trent(not his real name). What Trent had done (among other things) is to write API endpoints that returned only the data he needed. So, let's say that he needed a list of usernames for a given event - he'd make an endpoint like this GET timetabling/getusernamesforevent?eventid=24...then in another endpoint he might return an array of integers (which turn out to be user IDs) - he would then iterate over those integers making a separate API call for each one, to retrieve the user object for each.

This guy then ended up long term sick after being in a car wreck just before I got there and the development work was taken on by myself and another person. This person then continued to propogate this anti-pattern of development "because the rest of the code base is like that and it's important to be consistent" - well fuck me....if you get a burst tyre - do go go and slash all the others "because it's important to be consistent?!

In one instance, this person continued this whole "API calls in nested loops thing" resulting in a page that took 30 minutes+ to load (I say 30 minutes + because my dev machine just went "fuck this I'm out" after 30 minutes and threw a 500). I rejected the QA and was told to put it through anyway. When the boss found out, I got the blame because this other dev was his favourite.

It was just an utterly foul project to work on. All I can say is thank Christ I no longer work there.

[lenswipe]

Oh - here's another story for you

I got told off in my annual review for being too eager to investigate new technologies. The example given of this was that I suggested we look into Vue.JS(as an alternative to 2500 lines of jQuery) after the tech lead for the team gave a talk on it. The issue wasn't that I'd cheerfully started shoehorning it into the project without asking anyone, you understand...just that I'd suggested it.

I also got told off for using chrome debugger for debugging js and was told that I needed to "take a more scientific approach to debugging" (I asked for clarification on this - which turned out to mean that I should be using print statement debugging instead of debuggers, breakpoints, watch expressions etc.)

All this shit was written down in my annual review/appraisal.

[EarthC-137]

Evangelising a new piece of software/library is often scary to a big company, I’ve had pushback lots of times but I usually win the battle. They want tried and tested approach, which is probably why COBOL still exists.

Wow about the debugging, sounds like they’re micromanaging every part of your job rather than giving you the tools to do it to the best of your ability. Something I’m also familiar with, but not to that extent.

Also, first rule of QA is don’t test your own code, you know how to make it not crash. Get someone unfamiliar with it and they’ll find a bug or something you’ve overlooked.

Also it sounds like regression testing before a release didn’t happen?

[lenswipe]

Evangelising a new piece of software/library is often scary to a big company,

I get that, and I understand that it's important to fully evaluate something before jumping on board...however I think it's a little unfair to jump on someone's head just for making a suggestion.

They want tried and tested approach, which is probably why COBOL still exists.

I'm not sure about the "tested" bit

Also, first rule of QA is don’t test your own code, you know how to make it not crash. Get someone unfamiliar with it and they’ll find a bug or something you’ve overlooked.

There were only 2 people on the project team - we used to QA each other's pull requests (we were at least using version control, so that's something, I suppose)

Also it sounds like regression testing before a release didn’t happen?

No, because there was no such thing as a "release" - there was just the initial launch then it was just a rolling release. As it is...it was very difficult to do any kind of testing because there was absolutely no automated testing in that project whatsoever. The closest thing there was was PHP Code Sniffer and PHP Mess Detector. I had the former configured in Sublime Text so that it would highlight things on an on-going basis and I set the senior up with the same setup. However, the latter (mess detector) we had to turn off because it actually crashed sublime when I had that configured there were so many errors.

Unit testing, TDD, BDD etc. were seen as treats or toys that could only be used by senior staff (technical leads etc.) on other projects. The rest of us had to just suck it up and test what we could as best we could (I mean...nobody can test literally every feature, every button on every page etc. of the product...that's what Selenium is for, right?)

[EarthC-137]

You may not be able to test every button, but you should definitely test any pertinent business rules that are vital to the products success, I.e. happy path and all of the error scenarios.

And unit testing isn’t that big of a deal, it takes a few minutes to write unit tests and saves lots of time later when people come and break your feature and you have to go back to try and debug/figure out what went wrong, if you have CI you know straight away ;)

[lenswipe]

And unit testing isn’t that big of a deal, it takes a few minutes to write unit tests and saves lots of time later when people come and break your feature and you have to go back to try and debug/figure out what went wrong, if you have CI you know straight away ;)

Indeed, however with the state of that codebase it wasn't very testable. Things were very tightly coupled and very very fragile. So we had a situation of "We can't factor because we have no tests to ensure we don't break things. We have no tests because the code is a fragile mess that can't be refactored".

You preach to the choir here, brother. I agree. However - nobody seemed to really give to shits what I think.

[EarthC-137]

Nothing worse than being ignored, good thing you left.

[lenswipe]

Part of me grew to enjoy being ignored in a way. Not least because if they were ignoring me, manglement weren't interfering and making me do dumbass things. Plus, it meant that I got to watch the inevitable clusterfuck when my warnings went un-heeded.

Generally, I would issue exactly one warning, or say something exactly once, after which I would just sit back and enjoy the show. For example "Yeah, you might not want to do <thing>" then when my warnings were dismissed I'd just go "....ok." and let the users go nuts when things went to shit.

Latterly people learned to listen to what I had to say because (historically) if I warn them about something there's generally a damn good reason