3 ms·

Replying to myself to continue this ridiculous story: Part II: Any check-ins (apart from the senior 2 developers) went via a code review from one sarcastic guy

Replying to myself to continue this ridiculous story: Part II: Any check-ins (apart from the senior 2 developers) went via a code review from one sarcastic guy. He would pick up on use of std algorithms and was in general very very picky. And extremely sarcastic. The "management" staff weren't developers but promised things to customers and so the only question you would ever be asked is "is it done yet?". Any explanation of where you were or issues was met with "so is it not done then?" and then being told to speak to the way-too-busy top senior developer. The "manager" would ask you to assist with colleagues, eg. "You know about Visual Studio don't you? So-and-so is having difficulty" even though so-and-so was working on a web project in a completely different language to you, whilst you worked on desktop software in C++.... They had a non-software-developer team of "designers" who would "design" things and then give some paragraph of "design" to you, which you had to estimate, and then about 9 months later you'd get the work to do but were held to the estimate. Any extra time involved asking the managing director for more time and justification for wanting more time. He was in a city the other side of the country. Any bugs that came in had 4 hours to find and fix, and any amount of this time (up to the 4 hours) would be taken up by the support staff (who were sadly not knowledgeable about many things) "triaging", eg. an issue with database connectivity would have them suggesting adding a row to the database.... They lacked basic troubleshooting skills. Any more time you needed had to go via the managing director for permission, and then he would refer to the most senior developer because the managing director was not a software developer... You had to write "programmer notes" for the wiki detailing what you wrote and why so that in future developers could refer to them - nobody did because they just looked at the mound of code when they were assigned work. The programmer notes were often copied and pasted by the "QA" department into release notes, which meant the release notes included internal programmer notes and details. The "QA" department didn't understand how the software worked and despite being there for 13 years still had to get the single-person "IT" guy to do things like add in an ODBC connection to a database. They had to "test" things that they didn't understand - they had the programmer notes and "design" to refer to, but had no understanding of where it fitted into the grand scheme of things.

72deluxe 4y ago
Finally, the last bit of this sorry tale. Part III: The single "IT" guy didn't put UPS on anything so when the power failed all the servers just carried on running until they died. Bye bye Dell servers. The computers were locked down because one user ran an EXE and it encrypted everything on his machine. All network activity was logged. All work was recorded on an internally written "log" system that also monitored mailboxes so any email sent that included a log number ended up automatically on the internal log system. This meant a few occasions of people complaining about others ending up on a log. Any work you did involved "clicking onto a log" but then if you didn't do this you'd get a Skype message from a "manager" asking why you weren't "clicked onto a log". The internal log system was written in ASP and used SQL Server but used a lot of SQL functions and was next to impossible to debug because it was hosted on an IIS server that was in use. There was no test server. The main database was 200 GB or something like that so you just had to work against this live database. All of the software was 32 bit and had about 150 DLLs along with some OCX. The use of COM and ActiveX everywhere by junior developers meant they got the AddRef/ReleaseRef stuff wrong and you'd get leaks everywhere. Installation of the software (it was just a desktop app that talked directly via ODBC to a database) involved about 30 manual steps - there was no installer. It put some of the DLLs into the System32 directory and installed CPL applets for Control Panel so was very firmly stuck in 1996. Customers actually had to pay for the single "IT" guy to install the software. The build ran daily (and/or whenever anyone checked in code using TeamSource in Visual Studio) and they pushed out software to users using an appalling C# web service / utility system one guy had written. It was spaghetti and objects made calls into other classes and changed their members. The guy eventually faked his own car crash and just disappeared from work, never to return. The code of his that I inherited was appalling. The build ran an ANSI and a Unicode build, even though they actually were still just distributing the ANSI build.... You had to wrap all of your strings in _T wrappers and make sure you used the appropriate typedef for wide or narrow characters. You didn't have time to build the entire thing to test it worked in both, so tested in one and checked in and then got berated when you "broke the build" that automatically ran in Unicode/ANSI when you checked in. It sent out an email to everyone detailing the last check in and who it was. The web service that served the data relied on a secondary document service that silently failed for years when serving documents to customers, but nobody noticed. Not even the customers. They wouldn't be receiving files and nobody had noticed for about a decade. I once fixed this but it meant the secondary distribution service now got an exception when it asked for something that didn't exist, so was told I couldn't go home until it was fixed. They employed a team of people to help "manage" (I guess?) whose sole job was to pester you on Skype and add events to your calendar for when you'd have a meeting with your boss (the senior developer). You would have a meeting with the developer and this other person would be on the call but would say and do NOTHING. They wouldn't even make notes. I honestly have no idea what their job was. The software was also incredibly incredibly ugly. It also used Crystal Reports for its "report" system which was a steaming pile of buggy C# that threw exceptions in its own libraries all of the time, and would take 30 seconds per report to interrogate the database to see what format the fields were. You could have written your own PDF-writing report system in a month (since most reports only used 1 or 2 queries), and wrapped it in a PDF.js web view and that would have performed 10000% better than the absolute crud Crystal Reports but no, that wasn't important. The guy that wrapped the Crystal Reports library in a "viewer" window was also the same guy that faked his own car crash... He would run a background thread and then update the UI from the background thread and say that it sometimes seemed very slow or would appear to hang.... you think so?!?! Duh! It was a horrendous job. I enjoyed the C++ side of it but not the 20 years worth of overly-complicated code (loading/saving from/to a database doesn't need such complexity) and obsession with COM and MFC was horrible. I didn't like the toxic culture (witch hunt people when they get it wrong rather than train them) nor the obsessive micromanaging. The company was a great study into fomenting a bonkers environment where people worshipped "the build", feared the bosses, and had become so used to the ridiculous software that they didn't even see how stupid typing numbers into a grid to change behaviour was in 2017 or whenever it was. I didn't enjoy getting shouted and sworn at. I left and worked fewer days elsewhere. I believe the company is still doing well (they made enough money from licences and writing custom extensions that everybody inherited, so all customers got a really really really complicated piece of software that did way more than they needed, and slowly at that) but I believe it's circling the drain because of the baggage of its design and COM architecture. C++ good, COM bad.

72deluxe 4y ago

Finally, the last bit of this sorry tale. Part III: The single "IT" guy didn't put UPS on anything so when the power failed all the servers just carried on running until they died. Bye bye Dell servers. The computers were locked down because one user ran an EXE and it encrypted everything on his machine. All network activity was logged. All work was recorded on an internally written "log" system that also monitored mailboxes so any email sent that included a log number ended up automatically on the internal log system. This meant a few occasions of people complaining about others ending up on a log. Any work you did involved "clicking onto a log" but then if you didn't do this you'd get a Skype message from a "manager" asking why you weren't "clicked onto a log". The internal log system was written in ASP and used SQL Server but used a lot of SQL functions and was next to impossible to debug because it was hosted on an IIS server that was in use. There was no test server. The main database was 200 GB or something like that so you just had to work against this live database. All of the software was 32 bit and had about 150 DLLs along with some OCX. The use of COM and ActiveX everywhere by junior developers meant they got the AddRef/ReleaseRef stuff wrong and you'd get leaks everywhere. Installation of the software (it was just a desktop app that talked directly via ODBC to a database) involved about 30 manual steps - there was no installer. It put some of the DLLs into the System32 directory and installed CPL applets for Control Panel so was very firmly stuck in 1996. Customers actually had to pay for the single "IT" guy to install the software. The build ran daily (and/or whenever anyone checked in code using TeamSource in Visual Studio) and they pushed out software to users using an appalling C# web service / utility system one guy had written. It was spaghetti and objects made calls into other classes and changed their members. The guy eventually faked his own car crash and just disappeared from work, never to return. The code of his that I inherited was appalling. The build ran an ANSI and a Unicode build, even though they actually were still just distributing the ANSI build.... You had to wrap all of your strings in _T wrappers and make sure you used the appropriate typedef for wide or narrow characters. You didn't have time to build the entire thing to test it worked in both, so tested in one and checked in and then got berated when you "broke the build" that automatically ran in Unicode/ANSI when you checked in. It sent out an email to everyone detailing the last check in and who it was. The web service that served the data relied on a secondary document service that silently failed for years when serving documents to customers, but nobody noticed. Not even the customers. They wouldn't be receiving files and nobody had noticed for about a decade. I once fixed this but it meant the secondary distribution service now got an exception when it asked for something that didn't exist, so was told I couldn't go home until it was fixed. They employed a team of people to help "manage" (I guess?) whose sole job was to pester you on Skype and add events to your calendar for when you'd have a meeting with your boss (the senior developer). You would have a meeting with the developer and this other person would be on the call but would say and do NOTHING. They wouldn't even make notes. I honestly have no idea what their job was. The software was also incredibly incredibly ugly. It also used Crystal Reports for its "report" system which was a steaming pile of buggy C# that threw exceptions in its own libraries all of the time, and would take 30 seconds per report to interrogate the database to see what format the fields were. You could have written your own PDF-writing report system in a month (since most reports only used 1 or 2 queries), and wrapped it in a PDF.js web view and that would have performed 10000% better than the absolute crud Crystal Reports but no, that wasn't important. The guy that wrapped the Crystal Reports library in a "viewer" window was also the same guy that faked his own car crash... He would run a background thread and then update the UI from the background thread and say that it sometimes seemed very slow or would appear to hang.... you think so?!?! Duh! It was a horrendous job. I enjoyed the C++ side of it but not the 20 years worth of overly-complicated code (loading/saving from/to a database doesn't need such complexity) and obsession with COM and MFC was horrible. I didn't like the toxic culture (witch hunt people when they get it wrong rather than train them) nor the obsessive micromanaging. The company was a great study into fomenting a bonkers environment where people worshipped "the build", feared the bosses, and had become so used to the ridiculous software that they didn't even see how stupid typing numbers into a grid to change behaviour was in 2017 or whenever it was. I didn't enjoy getting shouted and sworn at. I left and worked fewer days elsewhere. I believe the company is still doing well (they made enough money from licences and writing custom extensions that everybody inherited, so all customers got a really really really complicated piece of software that did way more than they needed, and slowly at that) but I believe it's circling the drain because of the baggage of its design and COM architecture. C++ good, COM bad.