Oh, man, I just realized I haven't ranted one of my best stories on here!

So, here goes!

A few years back the company I work for was contacted by an older client regarding a new project.

The guy was now pitching to build the website for the Parliament of another country (not gonna name it, NDAs and stuff), and was planning on outsourcing the development, as he had no team and he was only aiming on taking care of the client service/project management side of the project.

Out of principle (and also to preserve our mental integrity), we have purposely avoided working with government bodies of any kind, in any country, but he was a friend of our CEO and pleaded until we singed on board.

Now, the project itself was way bigger than we expected, as the wanted more of an internal CRM, centralized document archive, event management, internal planning, multiple interfaced, role based access restricted monster of an administration interface, complete with regular user website, also packed with all kind of features, dashboards and so on.

Long story short, a lot bigger than what we were expecting based on the initial brief.

The development period was hell. New features were coming in on a weekly basis. Already implemented functionality was constantly being changed or redefined. No requests we ever made about clarifications and/or materials or information were ever answered on time.

They also somehow bullied the guy that brought us the project into also including the data migration from the old website into the new one we were building and we somehow ended up having to extract meaningful, formatted, sanitized content parsing static HTML files and connecting them to download-able files (almost every page in the old website had files available to download) we needed to also include in a sane way.

Now, don't think the files were simple URL paths we can trace to a folder/file path, oh no!!! The links were some form of hash combination that had to be exploded and tested against some king of database relationship tables that only had hashed indexes relating to other tables, that also only had hashed indexes relating to some other tables that kept a database of the website pages HTML file naming. So what we had to do is identify the files based on a combination of hashed indexes and re-hashed HTML file names that in the end would give us a filename for a real file that we had to then search for inside a list of over 20 folders not related to one another.

So we did this. Created a script that processed the hell out of over 10000 HTML files, database entries and files and re-indexed and re-named all this shit into a meaningful database of sane data and well organized files.

So, with this we were nearing the finish line for the project, which by now exceeded the estimated time by over to times.

We test everything, retest it all again for good measure, pack everything up for deployment, simulate on a staging environment, give the final client access to the staging version, get them to accept that all requirements are met, finish writing the documentation for the codebase, write detailed deployment procedure, include some automation and testing tools also for good measure, recommend production setup, hardware specs, software versions, server side optimization like caching, load balancing and all that we could think would ever be useful, all with more documentation and instructions.

As the project was built on PHP/MySQL (as requested), we recommended a Linux environment for production. Oh, I forgot to tell you that over the development period they kept asking us to also include steps for Windows procedures along with our regular documentation. Was a bit strange, but we added it in there just so we can finish and close the damn project.

So, we send them all the above and go get drunk as fuck in celebration of getting rid of them once and for all...

Next day: hung over, I get to the office, open my laptop and see on new email. I only had the one new mail, so I open it to see what it's about.

Lo and behold! The fuckers over in the other country that called themselves "IT guys", and were the ones making all the changes and additions to our requirements, were not capable enough to follow step by step instructions in order to deploy the project on their servers!!!

[Continues in the comments]

It finally hit me the other day.
I'm working on an IoT project for a late-stage ALS patient. The setup is that he has a tablet he controls with his eye movements, and he wants to be able to control furnishings in his room without relying on anyone else.
I set up a socket connection between his tablet and the Raspberry Pi. From there it was a simple matter of using GPIO to turn a lamp or fan on or off. I did the whole thing in C, even the socket programming on the Pi.
As I was finishing up the main control of the program on the Pi I realized that I need to be more certain of this than anything I've ever done before.
If something breaks, the client may be forced to go days without being able to turn his room light on, or his fan off.
Understand he is totally trapped in his own body so it's not like he can simply turn the fan off. The nursing staff are not particularly helpful and his wife is tied up a lot with work and their two small children so she can't spend all day every day doting on him.
Think of how annoying it is when you're trying to sleep and someone turns the light on in your room; now imagine you can't turn it off yourself, and it would take you about twenty minutes to tell someone to turn it off -- that is once you get their attention, again without being able to move any part of your body except your eyes.
As programmers and devs, it's a skill to do thorough testing and iron-out all the bugs. It is an entirely different experience when your client will be depending on what you're doing to drastically improve his quality of life, by being able to control his comfort level directly without relying on others -- that is, to do the simplest of tasks that we all take for granted.
Giving this man some independence back to his life is a huge honor; however, it carries the burden of knowing that I need to be damned confident in what I am doing, and that I have designed the system to recover from any catastrophe as quickly as possible.

In case you were wondering how I did it all: The Pi launches a wrapper for the socket connection on boot.
The wrapper launches the actual socket connection in a child process, then waits for it to exit. When the socket connection exits, the wrapper analyzes the cause for the exit.
If the socket connection exited safely -- by passing a special command from the tablet to the Pi -- then the wrapper exits the main function, which allows updating the Pi. If the socket connection exited unexpectedly, then the Pi reboots automatically -- which is the fastest way to return functionality and to safeguard against any resource leaks.
The socket program itself launches its own child process, which is an executable on the Pi. The data sent by the tablet is the name of the executable on the Pi. This allows a dynamic number of programs that can be controlled from the tablet, without having to reprogram the Pi, except for loding the executable onto it. If this child of the socket program fails, it will not disrupt its parent process, which is the socket program itself.

We're using a ticket system at work that a local company wrote specifically for IT-support companies. It's missing so many (to us) essential features that they flat out ignored the feature requests for. I started dissecting their front-end code to find ways to get the site to do what we want and find a lot of ugly code.
Stuff like if(!confirm("blablabla") == false) and whole JavaScript libraries just to perform one task in one page that are loaded on every page you visit, complaining in the js console that they are loaded in the wrong order. It also uses a websocket on a completely arbitrary port making it impossible to work with it if you are on a restricted wifi. They flat out lie about their customers not wanting an offline app even though their communications platform on which they got asked this question once again got swarmed with big customers disagreeing as the mobile perofrmance and design of the mobile webpage is just atrocious.

So i dig farther and farthee adding all the features we want into a userscript with a beat little 'custom namespace' i make pretty good progress until i find a site that does asynchronous loading of its subpages all of a sudden. They never do that anywhere else. Injecting code into the overcomolicated jQuery mess that they call code is impossible to me, so i track changes via a mutationObserver (awesome stuff for userscripts, never heard of it before) and get that running too.

The userscript got such a volume of functions in such a short time that my boss even used it to demonstrate to them what we want and asked them why they couldn't do it in a reasonable timeframe.

All in all I'm pretty proud if the script, but i hate that software companies that write such a mess of code in different coding styles all over the place even get a foot into the door.

And that's just the code part: They very veeeery often just break stuff in updates that then require multiple hotfixes throughout the day after we complain about it. These errors even go so far to break functionality completely or just throw 500s in our face. It really gives you the impression that they are not testing that thing at all.

And the worst: They actively encourage their trainees to write as much code as possible to get paid more than their contract says, so of course they just break stuff all the time to write as much as possible.
Where did i get that information you ask? They state it on ther fucking career page!

We also have reverse proxy in front of that page that manages the HTTPS encryption and Let's Encrypt renewal. Guess what: They internally check if the certificate on the machine is valid and the system refuses to work if it isn't. How do you upload a certificate to the system you asked? You don't! You have to mail it to them for them to SSH into the system and install it manually. When will that be possible you ask? SOON™.
At least after a while i got them to just disable the 'feature'.

While we are at 'features' (sorry for the bad structure): They have this genius 'smart redirect' feature that is supposed to throw you right back where you were once you're done editing something. Brilliant idea, how do they do it? Using a callback libk like everyone else? Noooo. A serverside database entry that only gets correctly updated half of the time. So while multitasking in multiple tabs because the performance of that thing almost forces you to makes it a whole lot worse you are not protected from it if you don't. Example: you did work on ticket A and save that. You get redirected to ticket B you worked on this morning even though its fucking 5 o' clock in the evening. So of course you get confused over wherever you selected the right ticket to begin with. So you have to check that almost everytime.

Alright, rant over.
Let's see if i beed to make another one after their big 'all feature requests on hold, UI redesign, everything will be fixed and much better'-update.

Working on a data structure project for a university's course.
Made a dictionary and was testing it's search functionality. 😢

KISS.
Keep it simple, stupid.

At the beginning the project is nothing but an idea. If you get it off the ground, that's already a huge success. Rich features and code quality should be the last of your worries in this case.

Throw out any secondary functionality out the window from day 0. Make it work, then add flowers and shit (note to self: need to make way for flowers and shit).

Nevertheless code quality is an important factor, if you can afford it. The top important things I outline in any new non-trivial project:
1. Spend 1-2 days bootstrapping it for best fit to the task, and well designed security, mocking, testing and extensibility.
2. Choose a stack that you'll most likely find good cheap devs for, in that region where you'll look in, but also a stack that will allow you to spend most of your time writing software rather than learning to code in it.
3. Talk to peers. Listen when they tell that your idea is stupid. Listen to why it's stupid, re-assess, because it most probably is stupid in this case.
4. Give yourself a good pep talk every morning, convincing you that the choices you've made starting this project are the right ones and that they'll bring you to success. Because if you started such a project already, the most efficient way to kill it is to doubt your core decisions.

Once it's working badly and with a ton of bugs, you've already succeeded in actually making it work, and then you can tackle the bugs and improvements.

Some dev is going to hate you for creating something horrific, but that horrific thing will work, and it's what will give another developer a maintenance job. Which is FAR, far more than most would get by focusing on quality and features from day 0.

OH MY FUCKING GOD! WHY THE FUCK WOULD YOU REWRITE A FUCKING PIECE OF CODE AND DON'T MAINTAIN ITS FUNCTIONALITY?
ARE YOU FUCKING MAD????

JUST SPENT 1 FUCKING HOUR TRYING TO FIGURE OUT WHY THE FUCK THE DATA WASN'T BEING PASSED TO REDUX STORE!

YEAH, UNIT TESTING SURE IS A FUCKING WASTE OF TIME YOU DUMB FUCKING IDIOT THAT HAS MASHED POTATOES FOR A BRAIN!

GO ROT IN HELL YOU PIECE OF SHIT!!!!

NOW IF I DON'T FIX THIS SHIT MY ASS IS ON THE LINE BECAUSE I MADE THE FUCKING FUNCTIONALITY THAT YOU BROKE?? NO FUCKING WAY!

I DON'T CARE IF YOU ARE MY BOSS, I'M GONNA GIT BLAME THE SHIT OUT OF YOU IF ANYONE PISSES ME OFF!

Client:
"Ok,. so your saying that its gonna take you 63 hrs to create a simplified CRM with basic functionality and auto fill docs or automated work flow docs as an added feature?"

My response (after already under-quoting and planning on cutting some corners because he has a smaller budget than normally necessary):
"It sounds simpler than it is. There are a lot of things I need to take into account that you wouldn't even think about.

For instance:

Making sure your emails don't go to the client's spam folder. This requires the sending domain to be verified via DNS settings. I have to ensure your email content passes a spam test (link to text ratio needs to be good). I assumed you'd want an email that has your logo and looks good. This means testing the design in Outlook to make sure it's not broken.

What if the email doesn't send due to an invalid email address, or bounces back? You'll need to be notified.

What if the client list for the week contains duplicates? You need them merged or ignored.

Generating a PDF from HTML can be tricky because the conversion isn't apples to apples so there are things I need to adjust to make them as close as possible.

Making a site completely mobile friendly (the tier 3 option) can be very time consuming as well. It's not about whether or not it fits on a mobile phone, it's about whether or not it's intuitive and useful. You're essentially getting a mobile app without paying for separate development of an app.

If I took everything into consideration and built this to be 100% bullet proof, it would cost tens of thousands.

I'm doing my best to leverage your needs with the probability of running into an issue. I'm not going waste my time/your money on something that will likely never happen."

Oh man. Mine are the REASON why people dislike PHP.

Biggest Concern: Intranet application for 3 staff members that allows them to set the admin data for an application that our userbase utilizes. Everything was fucking horrible, 300+ php files of spaghetti that did not escape user input, did not handle proper redirects, bad algo big O shit and then some. My pain point? I was testing some functionality when upon clicking 3 random check boxes you would get an error message that reads something like this "hi <SENSITIVE USERNAME DATA> you are attempting to use <SERVER IP ADDRESS> using <PASSWORD> but something went wrong! Call <OLD DEVELOPER's PHONE NUMBER> to provide him this <ERROR CODE>"

I panicked, closed that shit and rewrote it in an afternoon, that fucking retard had a tendency to use over 400 files of php for the simplest of fucking things.

Another one, that still baffles me and the other dev (an employee that has been there since the dawn of time) we have this massive application that we just can't rewrite due to time constraints. there is one file with (shit you not) a php include function that when you reach the file it is including it is just......a php closing tag. Removing it breaks down the application. This one is over 6000 files (I know) and we cannot understand what in the love of Lerdorf and baby Torvalds is happening.

From a previous job we had this massive in-house Javascript "framework" for ajax shit that for whatever reason unknown to me had a bunch of function and object names prefixed with "hotDog<rest of the function name>", this was used by two applications. One still in classic ASP and the other in php version 4.something

Legacy apps written in Apache Velocity, which in itself is not that bad, but I, even as a PHP developer, do not EVER mix views with logic. I like my shit separated AF thank you very much.

A large mobile application that interfaced with fucking everything via webviews. Shit was absolutley fucking disgusting, and I felt we were cheating our users.

A rails app with 1000 controller methods.

An express app with 1000 router methods with callbacks instead of async await even though async await was already a thing.

ultraFuckingLarge Delphi project with really no consideration for best practices. I, to this day enjoy Object Pascal, but the way in which people do delphi can scare me.

ASP.NET Application in wich there seemed to be a large portion of bolted in self made ioc framework from the lead dev, absolute shitfest, homie refused to use an actual ioc framework for it, they did pay the price after I left.

My own projects when I have to maintain them.

Hey guys,

this rant will be long again. I'm sorry for any grammar errors or something like that, english isn't my native language. Furthermore I'm actually very sad and not in a good mood.

Why? What happened? Some of you may already know - I'm doing my apprenticeship / education in a smal company.
There I'm learning a lot, I'm developing awesome features directly for the clients, experience of which other in my age (I'm only 19 years old) can only dream.
Working in such a small company is very exhausting, but I love my job, I love programming. I turned my hobby into a profession and I'm very proud of it.
But then there are moments like the last time, when I had to present something for a client - the first presentation was good, the last was a disaster, nothing worked - but I learned from it.

But this time everything is worse than bad - I mean really, really worse than bad.

I've worked the whole week on a cool new feature - I've done everything that it works yesterday, that everything gets done before the deadline of yesterday.

To achieve this I've coded thursday till 10pm ! At home! Friday I tested the whole day everything to ensure that everything is working properly. I fixed several bugs and then at the end of the day everything seems to be working. Even my boss said that it looks good and he thinks that the rollout to all clients will become good and without any issues.

But unfortunately deceived.

Yesterday evening I wrote a long mail to my boss - with a "manual". He was very proud and said that he is confident that everything will work fine. He trusts me completly.

Then, this morning I received a mail from him - nothing works anymore - all clients have issues, everything stays blank - because I've forgotten to ensure that the new feature (a plugin) and its functionality is supported by the device (needs a installation).
First - I was very shoked - but in the same moment I thought - one moment - you've written an if statement, if the plugin is installed - so why the fuck should it broken everything?!
I looked instant to the code via git. This has to be a very bad joke from my boss I thought. But then I saw the fucking bug - I've written:
if(plugin) { // do shit }
but it has to be if(typeof plugin !== 'undefined')

I fucked up everything - due to this fucking mistake. This little piece of shit I've forgotten on one single line fucked up everything. I'm sorry for this mode of expression but I thought - no this can not be true - it must be a bad bad nightmare.
I've tested this so long, every scenario, everything. Worked till the night so it gets finished. No one, no one from my classmates would ever think of working so long. But I did it, because I love my job. I've implemented a check to ensure that the plugin is installed - but implemented it wrong - exactly this line which caused all the errors should prevent exactly this - what an irony of fate.

I've instantly called my boss and apologized for this mistake. The mistake can't be undone. My boss now has to go to all clients to fix it. This will be very expensive...

Oh my goodnes, I just cried.
I'm only working about half a year in this company - they trust me so much - but I'm not perfect - I make mistakes - like everyone else. This time my boss didn't looked over my code, didn't review it, because he trusted me completly - now this happens. I think this destroyed the trust :( I'm so sad.
He only said that we will talk on monday, how we can prevent such things in the feature..
Oh guys, I don't know - I've fucked up everything, we were so overhelmed that everything would work :(
Now I'm the looser who fucked up - because not testing enough - even when I tested it for days, even at home - worked at home - till the night - for free, for nothing - voluntary.

This is the thanks for that.
Thousand good things - but one mistake and you're the little asshole. You - a 19 year old guy, which works since 6 months in a company. A boss which trusts you and don't look over your code. One line which should prevent crashing, crashed everything.

I'm sorry that this rant is so long, I just need to talk to you guys because I'm so sad. Again. This has happend to frequently lately.

I fucking HATE testing JavaScript. It's such fucking bullshit. I've been struggling to test one simple functionality for multiple hours. It's probably one stupid thing I can't figure out, so I hope some sleep will grant me a fresh look tomorrow.

Also it's absolute bullshit the amount of libraries and dependencies you need to have to get some proper scalable tests going. Jasmine, Babel, ES2015, yarn/npm (because Jenkins is too fucking old to handle yarn). React, react test helpers, webpack. The list continues. FUCK OFF!

My coworker can't be bothered with learning git branching, so he comments out significant functionality during testing and then comments it back in before go-live. What could possibly go wrong?

"I'm almost done, I'll just need to add tests!"

Booom! You did it, that was a nuke going off in my head.

No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.

When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"

Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.

So let it be said:

- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.

Because then you suddenly have to mock away a http service and deal with zip files in your test cases.

The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.

In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.

Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.

That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.

Sidenote:

It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)

I'm coming off a lengthy staff augmentation assignment awful enough that I feel like I need to be rehabilitated to convince myself that I even want to be a software developer.

They needed someone who does .NET. It turns out what they meant was someone to copy and paste massive amounts of code that their EA calls a "framework." Just copy and paste this entire repo, make a whole ton of tweaks that for whatever reason never make their way back into the "template," and then make a few edits for some specific functionality. And then repeat. And repeat. Over a dozen times.

The code is unbelievable. Everything is stacked into giant classes that inherit from each other. There's no dependency inversion. The classes have default constructors with a comment "for unit testing" and then the "real" code uses a different one.

It's full of projects, classes, and methods with weird names that don't do anything. The class and method names sound like they mean something but don't. So after a dozen times I tried to refactor, and the EA threw a hissy fit. Deleting dead code, reducing three levels of inheritance to a simple class, and renaming stuff to indicate what it does are all violations of "standards." I had to go back to the template and start over.

This guy actually recorded a video of himself giving developers instructions on how to copy and paste his awful code.

Then he randomly invents new "standards." A class that reads messages from a queue and processes them shouldn't process them anymore. It should read them and put them in another queue, and then we add more complication by reading from that queue. The reason? We might want to use the original queue for something else one day. I'm pretty sure rewriting working code to meet requirements no one has is as close as you can get to the opposite of Agile.

I fixed some major bugs during my refactor, and missed one the second time after I started over. So stuff actually broke in production because I took points off the board and "fixed" what worked to add back in dead code, variables that aren't used, etc.

In the process, I asked the EA how he wanted me to do this stuff, because I know that he makes up "standards" on the fly and whatever I do may or may not be what he was imagining. We had a tight deadline and I didn't really have time to guess, read his mind, get it wrong, and start over. So we scheduled an hour for him to show me what he wanted.

He said it would take fifteen minutes. He used the first fifteen insisting that he would not explain what he wanted, and besides he didn't remember how all of the code he wrote worked anyway so I would just have to spend more time studying his masterpiece and stepping through it in the debugger.

Being accountable to my team, I insisted that we needed to spend the scheduled hour on him actually explaining what he wanted. He started yelling and hung up. I had to explain to management that I could figure out how to make his "framework" work, but it would take longer and there was no guarantee that when it was done it would magically converge on whatever he was imagining. We totally blew that deadline.

When the .NET work was done, I got sucked into another part of the same project where they were writing massive 500 line SQL stored procedures that no one could understand. They would write a dozen before sending any to QA, then find out that there was a scenario or two not accounted for, and rewrite them all. And repeat. And repeat. Eventually it consisted of, one again, copying and pasting existing procedures into new ones.

At one point one dev asked me to help him test his procedure. I said sure, tell me the scenarios for which I needed to test. He didn't know. My question was the equivalent of asking, "Tell me what you think your code does," and he couldn't answer it. If the guy who wrote it doesn't know what it does right after he wrote it and you certainly can't tell by reading it, and there's dozens of these procedures, all the same but slightly different, how is anyone ever going to read them in a month or a year? What happens when someone needs to change them? What happens when someone finds another defect, and there are going to be a ton of them?

It's a nightmare. Why interview me with all sorts of questions about my dev skills if the plan is to have me copy and paste stuff and carefully avoid applying anything that I know?

The people are all nice except for their evil XEB (Xenophobe Expert Beginner) EA who has no business writing a line of code, ever, and certainly shouldn't be reviewing it.

I've tried to keep my sanity by answering stackoverflow questions once in a while and sometimes turning evil things I was forced to do into constructive blog posts to which I cannot link to preserve my anonymity. I feel like I've taken a six-month detour from software development to shovel crap. Never again. Lesson learned. Next time they're not interviewing me. I'm interviewing them. I'm a professional.

Testing functionality of the form

I'm going to kill management.
After a serious migration fiasco at one of our biggest costumers the platform was finally usable again (after two days instead of 10 hours) and, of course, users started to report bugs. So good old po came in ranting that we as qa did a horrible job and basically tried to fault us for a fucked up update (because we produced user pain, which of course not being able to log in didn't do). Among the issues: If the user has more than a hundred web pages the menu starts looking ugly, the translation to dutch in one string on the third submenu of a widget doesn't work and a certain functionality isn't available even if it's activated.
Short, they were either not a use case or very much minor except for that missing function. So today we've looked through the entire test code, testing lists, change logs and so on only to discover that the function was removed actively during the last major update one and a half years ago.

Now it's just waiting for the review meeting with the wonderful talking point "How could effective QA prevent something like this in the future" and throwing that shit into his face.

I mean seriously, if you fuck shit up stand by it. We all make mistakes but trying to pin it on other people is just really, really low.

Worst collaboration experience story?

I was not directly involved, it was a Delphi -> C# conversion of our customer returns application.

The dev manager was out to prove waterfall was the only development methodology that could make convert the monolith app to a lean, multi-tier, enterprise-worthy application.

Starting out with a team of 7 (3 devs, 2 dbas, team mgr, and the dev department mgr), they spent around 3 months designing, meetings, and more meetings. Armed with 50+ page specification Word document (not counting the countless Visio workflow diagrams and Microsoft Project timeline/ghantt charts), the team was ready to start coding.
The database design, workflow, and UI design (using Visio), was well done/thought out, but problems started on day one.
- Team mgr and Dev mgr split up the 3 devs, 1 dev wrote the database access library tier, 1 wrote the service tier, the other dev wrote the UI (I'll add this was the dev's first experience with WPF).
- Per the specification, all the layers wouldn't be integrated until all of them met the standards (unit tested, free from errors from VS's code analyzer, etc)
- By the time the devs where ready to code, the DBAs were already tasked with other projects, so the Returns app was prioritized to "when we get around to it"

Fast forward 6 months later, all the devs were 'done' coding, having very little/no communication with one another, then the integration. The service and database layers assumed different design patterns and different database relationships and the UI layer required functionality neither layers anticipated (ex. multi-users and the service maintaining some sort of state between them).

Those issues took about a month to work out, then the app began beta testing with real end users. App didn't make it 10 minutes before users gave up. Numerous UI logic errors, runtime errors, and overall app stability. Because the UI was so bad, the dev mgr brought in one of the web developers (she was pretty good at UI design). You might guess how useful someone is being dropped in on complex project , months after-the-fact and being told "Fix it!".

Couple of months of UI re-design and many other changes, the app was ready for beta testing.

In the mean time, the company hired a new customer service manager. When he saw the application, he rejected the app because he re-designed the entire returns process to be more efficient. The application UI was written to the exact step-by-step old returns process with little/no deviation.

With a tremendous amount of push-back (TL;DR), the dev mgr promised to change the app, but only after it was deployed into production (using "we can fix it later" excuse).

Still plagued with numerous bugs, the app was finally deployed. In attempts to save face, there was a company-wide party to celebrate the 'death' of the "old Delphi returns app" and the birth of the new. Cake, drinks, certificates of achievements for the devs, etc.

By the end of the project, the devs hated each other. Finger pointing, petty squabbles, out-right "FU!"s across the cube walls, etc. All the team members were re-assigned to other teams to separate them, leaving a single new hire to fix all the issues.

I have this project I've inherited, yea I seem to do that a lot, but this damn thing, has to run in php5.4, has deprecated functions for php7 everywhere and a lot of them and there's no classes anywhere beyond some libraries.

Everything is procedural with random scripts being injected left right and center.

I kid you not,

$thisThing = true;
If(x==y)
require "path/to/some/script.php";
else
require "path/to/a/slightly/different/script.php";

If($thisThing === false){
// well it was modified in that small block about 10 different times
}

Those injected scripts then accept data from the parent scope so, looking at file X, you need to have open file A,B, E, and M to understand where variables have been initialised and what there current state could potentially be.

Basically this thing was bandaid after bandaid for feature requests with 0 refactoring.

Here I am trying to implement some basic functionality (should only take an hour or so + a bit of manual testing) but no, I'm literally at the point of hitting the delete button on the entire project and starting again.

Sometimes, being the only fullstack dev with access to a lot of systems gives you the ability to introduce functionality that:

A) prevents future errors

B) introduces new validations to users to make sure A) is prevented.

C) apply these changes to different projects

But most importantly...

D) without a single person in management getting involved or having to sign it off.

It's like running a company you own, but without owning it.

Granted with such power, comes the trust and responsibility of deploying changes with the adequate testing being done prior and handling change management, but fuck, sometimes I wonder if "god mode" for lack of a better term, is too much, or just enough to get the job done without the politics.

Had an idea for an app. I started writing the prototype in Node since I just had a simple API in mind. Wanted to have some very basoc crud functionality going and then hook up a nice interface to it. It has to do with logistics and analytics so I just wanted to start sketching something small, and being that i have been successful in doing an API like this in the pass with node and mongo for a local company I said why not.

I have finished a good chunk of it. Gotta love that js productivity. But what tripped me out about it was:

Check how big the folder size is: 387mb

EXCUSE ME??!!

I tripped, there was no way in hell this shit was that heavy. I am basically using Koi(to give it a whirl instead of express, gotta start testing koi sometimes right?) And some joi with morgan and winston. That is it. I am using mongo since legit its the only one i know, even with that there really can't be that much right?

Check node_modules size.....10mb....wtf? What
Wait
Did it?

Sure as shit....forgot that i was storing the mongo data folder inside the app's root folder.

This would have been nothing if it would have taken me 30 seconds to figure it out.

I was losing my mind for 30 mins before i decided to properly verify

I need some sleep

What.. the actual... fuuuuuck?!

Browsing through changes on TFS (yeah, yeah boo me for using TFS instead of git if you like, I don't care, most people use/prefer TFS here, so I conform 'to the standards'..)

Anyhow, going through changes, looking for the one where some comment appeared..

'a wild comment appeared'.. tadaaah!

Checked the rest of changes.. Hm.. Someone did a validity check.. that returns the 'false' if not passed.
// OK, great! They are finally testing their shit and fixing stuff..
But apparently then they decided it is OK to do all the shit anyways.. so WTF?!
Why even bother validating it?! Oh yeah, forgot... cuz in case it returned false YOU WERE NOT SUPPOSED TO LET SOME STUFF HAPPEN!! But they weren't assigned with that exact task I guess..

TO DO:
- do the validation algo // fml, not going into how fucked up that was written..but it was horrible!
- do validity check where appropriate/needed
- test validity check and that it doesn't break functionality

+ check if the validation actually logically works?! nope, not on my to do list, not my job..

All done, better not actually do something that requires you to think.. :\

How the fuck that happened?! How can one person be assigned to check if something is stupid/wrong?! and when checking (&confirming) still lets the customer do that shit anyways?! What's the point?! O.O

I was asked to look into a site I haven't actively developed since about 3-4 years. It should be a simple side-gig.
I was told this site has been actively developed by the person who came after me, and this person had a few other people help out as well.
The most daunting task in my head was to go through their changes and see why stuff is broken (I was told functionality had been removed, things were changed for the worse, etc etc).
I ssh into the machine and it works. For SOME reason I still have access, which is a good thing since there's literally nobody to ask for access at the moment.
I cd into the project, do a git remote get-url origin to see if they've changed the repo location. Doesn't work. There is no origin. It's "upstream" now. Ok, no biggie. git remote get-url upstream. Repo is still there. Good.
Just to check, see if there's anything untracked with git status. Nothing. Good.
What was the last thing that was worked on? git log --all --decorate --oneline --graph. Wait... Something about the commit message seems familiar. git log. .... This is *my* last commit message. The hell?
I open the repo in the browser, login with some credentials my browser had saved (again, good because I have no clue about the password). Repo hasn't gotten a commit since mine. That can't be right.
Check branches. Oh....Like a dozen new branches. Lots of commits with text that is really not helpful at all. Looks like they were trying to set up a pipeline and testing it out over and over again.
A lot of other changes including the deletion of a database config and schema changes. 0 tests. Doesn't seem like these changes were ever in production.
...
At least I don't have to rack my head trying to understand someone else's code but.... I might just have to throw everything that was done into the garbage. I'm not gonna be the one to push all these changes I don't know about to prod and see what breaks and what doesn't break
.
I feel bad for whoever worked on the codebase after me, because all their changes are now just a waste of time and space that will never be used.

Spent a lot of time designing a proper HTTP (dare I even say RESTful) API for our - what is until now a closed system, using a little-known/badly-supported message-over-websocket protocol to do RPC-style communications - supposedly enterprise-grade product.

I make the API spec go through several rounds of review with the rest of the dev team and customers/partners alike. After a few iterations, everybody agrees that the spec will meet the necessary requirements.

I start implementing according to spec. Because this is the first time we're actually building proper HTTP handling into the product, but we of course have to make it work at least somewhat with the RPC-style codebase, it's mostly foundational work. But still, I manage to get some initial endpoints fully implemented and working as per the spec we agreed. The first PR is created, reviews are positive, the direction is clear and what's there already works.

At this point in time, I leave on my honeymoon for two weeks. Naturally, I assume that the remaining endpoints will be completed following the outlines/example of the endpoints which I built. When I come back, the team mentions that the implementation is completed and I believe all is well.

The feature is deployed selectively to some alpha customers to start validation testing before the big rollout. It's been like that for a good month, until a few days ago when I get a question related to a PoC integration which they can't seem to get to work.

I start investigating and notice that the API hasn't been implemented according to the previously agreed upon spec at all. Not only did the team manage to implement the missing functionality in strange and some even broken ways, they also managed to refactor my previously working endpoints into being non-compliant.

Now, I'm a flexible guy. It's not because something isn't done exactly as I've imagined it that it's automatically bad. However, I know from experience that designing a good/clear/future-proof API is a tricky exercise. I've put a lot of time and effort into deliberate design decisions that made up the spec that we all reviewed repeatedly and agreed upon. The current implementation might also be fine, but I now have to go over each endpoint again and reason about whether the implementation still fulfills the requirements (both soft and hard) that we set out to meet.

I'm met with resistance, pushback and disbelief from product management and dev co-workers alike when I raise the concern that the API might actually not be production-ready (while I'm frantically rewriting my integration tests and figuring out how the actual implementation works in comparison to what was spec'ed).

Oh, and did I mention that product management wants to release this by end-of-week?!

A coworker of mine was asked to make a utility C# app to help with our internal testing. The idea was that the app would collect data and display the results.

He decided that it was very important that the app have a command line interface. He's spent far more time building the app from scratch for the command line than he would have if he'd used C#'s built-in GUI utilities.

Today was our demo day and he shows an internal command-line app in 2017 built in C#. I asked about the GUI and he said that the command line functionality was more important. I suggested that it was maybe less user-friendly and he proceeded to explain to me how "non-technical" people might prefer a GUI, but clearly any serious developer would just want a command line app.

I feel like, in one fell swoop, he trivialized my suggestion, didn't address any of the data visualization needs, and suggested I wasn't a "real developer". Am I right to feel a little outraged by this?

How to delete 16 days of commits 101 🤯:

First of all, me and my class (computer science in college) were working on a project for around 12 weeks, our “client” is one of our teacher and we literally just finished today to work on the project since our degree terminal projects are starting next week.

So now there's this guy in our class who kinda has the reputation to be stuborn and clumsy; he’s going to do his assigned task, commit, push it and put his task into QA (which is just peer evaluation and testing nothing really complex) and then when we try his functionality and finds out it isn’t working, we tell him and the only thing he always answers is : “but it works on my machine” and then we will need to explicitly ask him to be sure he has all the latest changes (database and codebase) and to see if it still works on his side since it doesn’t work for anyone else.

This actually happened quite a lot in these 12 weeks and you can definitely imagine that of course it would definitely not happen again today when we thought we were finally done with this project…

So another teacher gave us an assignment to create a development environment for our big project so we could try out Docker instead of virtual machines, he made GitHub Classroom repos with a minified version of our project and up to this point everything is fine and clear. That is until 3 hours ago, that our little clumsy friend somehow pushed his Docker related files on the main project, maybe he was trying his Docker setup on the real project no big deal you know EXCEPT IF HE HADN’T NOT PULLED SINCE 16 DAYS 😤.

He was doing maintenance on another project so I can maybe understand but gosh how did he not see the big warning of Git that he wasn’t up to date with master ? And yes we only have a master branch bear with us but hopefully we were able to create a new branch with the up to date project and then merge master.

A couple of us had a gut feeling that this guy would do something that would break the whole project right before we ended, turns out we were right 😅

It was around 2013, I was working on a project that had a great business idea, a really really bright feature (to this day I state the same) and all I was getting was around 400e/month of salary. (still was a junior dev)

So, I've been going on vacation to Spain for almost 1.5 month, everything was settled, there were no more pending jobs for me as I've finished everything that I could until more things would be done on the application and design that were needed.

It was 2nd week there, I didn't have a laptop with me as it was full vacation mode, no internet connection as it was almost 100e/month at that time, house I've lived in had no internet either. Then, one morning I receive a call that I must be on a skype meeting in any case - it was live or die situation. Me being me - went to a local internet cafe that was around 3km away from the house (on foot) - logged in to the call and proceeded. (I knew something is going to be fishy).

And there it was - I was needed to go back to my laptop and code a huge ass functionality so that we could present it to our testing clients. It was estimated to take around 3 weeks of full working days. No future payment, no compensation was offered but as stupid as I was - I went on with that and worked half of my vacation on full-day schedule... The functionality was delivered... Only after 4 months since the delivery date - the functionality was tested and after total of 9 months - was presented to the testers... I was pissed and asked for compensation as it was my vacation but all I heard was - NO, you took too long of a vacation and therefore it's your own fault. Soon after that I've started to receive every bit of blame if I was even 1 hour off the set deadline that was set by the manager that didn't have a single clue how programming works or even how to use the internet properly....

All in all, I'm still hurt of the 3 weeks that I've missed but since I've left the job 4 years ago (my salary had increased but I've quadrupled it since then) - I tend to see that it's a common practice to require things NOW and only deal with them MONTHS later...

Morale of the story:
Avoid working on your vacation at any means. If that will mean a lost job - then be it, you'll find a new one, presumably a better job.

So, I work in a game development studio, right?
We're trying to launch the title on as many platforms as reasonable, because as a social VR app we're kinda rowing upstream.
So far, Steam and Oculus have been fairly reasonable, if oddly broken and inconsistent.
Enter store 3.
Basically no in-game transaction support (our asking prompted them to *start* developing it. No, it's not very complete). No patch-update system (You want an update? Gotta download the whole fsckin' thing!). No beta-testing functionality for most of their stuff ("Just write the code like the example, it will work, trust us!"). No tools besides the buggy SDK (Wanna upload that new build? Say hello to this page in your web browser!).
So, in other words: Fun.

We've been trying to get actively launched for two months now. Keep in mind that the build has been up on Steam and Oculus for over a year and half a year (respectively), so the actual binary functionality is, presumably fine.

The best feedback we get back tends to be "Well, when we click the Launch button it crashes, so fail."
Meanwhile we're going back and forth, dealing with other-side-of-the-world timezone lag, trying to figure out what is so different from their machines as ours. Eventually we get them to start sending logs (and no, Windows Event logs are not sufficient for GAMES, where did you even get that idea????) except the logs indicate that the program is getting killed so terribly that the engine's built-in crash handler can't even kick in to generate memory dumps or even know it died.

All this boils down to today, where I get a screenshot of their latest attempt.

I just can't even right now.

Rant

I'm tired of this shit!!!

First I receive a task to create a new functionality for the app that I'm working on and some documentation (this is the only good part of all the rant) but no design.

It's been 2 weeks since I got assigned to this and still no design, no assets, no API calls that ACTUALLY WORK.

Today was testing a plist to get a banner link, and for 1 hour that little fucker didn't returned the image I was asking.

Better, I wasn't getting ANY IMAGE. Turns out that the link sends me to a HTML URL that doesn't have any image... go figure!

So I've been working on this from some images inside the PDF with the documentation given.

Oh! Wait! There's more!

The cherry on top is that I'm implementing a chat/voice call/video call into the app and the framework that I will be using is being created now, and it's not even finished!!!!!!

Company is about to get certified to ISO 9001:

Kick-off meeting with consultant announced weeks ago, mandatory for all employees.
Everyone is kind of joking about it, but also looking forward to certain workflows maybe changing to the better.

Two hours before meeting, told by CTO not to attend.

Some code I hadn't touched for half a year needs urgent patching to make the equipment pass EMC test (doing so within a few hours would help us save the lab cost for another day of testing).

When they applied RF noise to the bus lines, the CAN peripheral would glitch and need reset, this should happen covertly the first few times without raising any error to the user, so they could just finish the testing without being disturbed by the error - and the EMC lab will not test the functionality of the device after all.

The irony when you were actually supposed to learn about quality that day...

Me: *asks for sample data for all tables to test database transactions*

Team member: *gives over 45000 records only for city*

🤔 😐

TLDR: Walmart bug 😠

As a dev, I know that bugs happen. But as a dev from a small shop that has many clients and very few devs, I absolutely despise when a large company with many devs has a bug in a product that millions of people use.

WalmartContacts.com. How many devs do they have? And how many dedicated to this 1 product? How many people in QA? (how many on DevRant... lol)
And yet I can't even place an order using their reorder functionality. Seems like they should have this shit down. Seems like they should have all their regression testing ducks in a row. Seems like they should at least show some kind of error message so the user knows what's going on. Instead, no message at all, just the final checkout payment page reloading when I submit leaving me to wonder if my card has been charged or not.

Following my first rant, my boss had the brilliant idea of running the old and the new architecture in parallel. I had advised that it won’t be ideal since the same Scala code was ingesting into 2 different Kinesis streams and one was running an old KCL written in Java where as other was consumed by a Firehose delivery stream(eventually we will be ingesting it into Firehose directly). I had told few manual + automated tests on Code as well as from a functionality of the new architecture and a set of tests for checking the integration of the new Producer code with Consumer.

The statement I got from my boss was “This is the test, we test it on production in parallel”. My boss had a brilliant idea to fucking test the new code on the production directly but running them in parallel without accounting for undefined behaviour it might cause in the current production system. I mean my boss should get a Nobel peace prize for shattering our mental peace.

Anywho, we started the deployment today at 5AM in the morning. I had all the aws services deployed. Was just waiting to deploy the new Collector code which we did at 5AM. Immediately after 5 minutes the system went bonkers, there was fire, blood, demons and I was smoking a cigarette with the biggest “I told you so smile” on my face. I’ve just written an email to my boss and have told him calmly that “Listen motherfucker, 90 percent of the software companies aren’t idiots to focus on testing and quality. We need to start spending time on testing and quality else we’ll again be in the same soup after few weeks again”.waiting for his reply

So I joined a pretty big organization, and am working here for like the last 4 months. Barely wrote any code, mostly I have been documenting stuff, and testing stuff of other devs.
So I had a doubt regarding a functionality, like what I asked a senior dev was, Where exactly is this logic implemented in the codebase so that I can refer it. He was like, you are supposed to know it since you have worked on a testing ticket of it. And if I ask the manager such questions, he would be pissed off. My point of view is that yes, I might have seen that logic, and it might have been explained it to me once, but at that point of time, I did not knew about which functionality it was being used for. am I in the wrong here? Am I not paying enough attention to the code base given It's my 4th month here?

* Gets handed additions to current software platform (web)

* Gives back estimte of time after meeting with everyone and making them understand that once the testing phase of the project is reached there will be no changes, tests should be exhaustive and focus on SAID FUNCTIONALITY of the new additions. NO CHANGES OR ADDITIONS AT THIS POINT IN TIME

* All directives, stakeholders, users etc agreed on my request and spend an additional hour thinking of different corner and edge cases as provided by me in case they can't think of them (they can't, because they are fucking stupid, but I provided everything)

* Boss looks irritated at their lack of understanding of the scope and the time needed, nods in approval after he sees my entire specification, testing cases, possible additions to the system etc

* All members of the committee decide on the requirements being correct, concrete and proper.

* Finish the additions in a couple of weeks due to the increased demand for other projects, this directly affects the user base, so my VP and Director make it a top priority, I agree with their sentiment, since my Director knows what he is doing (real OG)

* I make the changes, test inside of my department and then stage for the testing environment. Everything is ready, all migrations are in order, the functionality is working as proper and the pipeline for the project, albeit somewhat lacking in elegance is good to go.

* Testing days arrive

* First couple of hours of test: Oh, you know what, we should add these two additional fields, and it would be good if the reporting generated by the system would contain this OTHER FORMAT rather than this one.

* ME: We stated that no additions would be done during the testing environment, testing is for functionality, not to see if you can all think of something else, even then, on June 10 I provided a initial demo and no one bothered to check on it on say something.

Them: Well, we are doing it now, this is what testing is for.

Me: Out of this room, the software engineer is me, and I can assure you, testing is not for that. I repeatedly stated that previously, I set the requirements, added corner cases, tables charts everything and not one single one of you decided to pay attention or add something, actually, said functionality you are requesting was part of one of my detailed list of corner cases, why did you not add it there and then before everything went up?

Them: Well I didn't read it at the time (think of the I in plural form since all of these dumb fucks stated the same)

Then my boss went on a rampage on their dumbasses.

I fucking hate software development sometimes.

Oh well. Bunch of fucking retards.

So... I take over this one ticket to test... the ticket mentions some visual component popping up when a button is clicked. It says there is a success and a failure message. The title of the story also mentions another functionality.

I start testing and some fellow QA asks me why I'm testing in this environment. Turns out, three people are sharing one environment and three different things are deployed...

I ask the dev whats going on because I heard there are multiple people deploying stuff...
He just tells me "oh, my changes are deployed I just checked".
I tell him that it's not about that but about communication and testing one thing at the time. Then I tell him, that I wouldn't test until his stuff is the only stuff there.

Some time later he hits me up again, now with the env to himself.

I test and quickly I see, that there is only the positive message even when I make sure that the backend is not reachable. I tell the dev what I found and he tells me "oh no, it's just the implementation of the popup thing, it's just frontend for now"...
I tell him, that the ticket should say so.
No answer for like 1-2 hours. Then I get an "ok".
End of the day.

Next day I come in and the fellow QA tells me, that the dev asked him to test the ticket.
I ask him if he changed anything about the scope of the ticket, he says no...
I'm like "ok... know what... begin testing and then tell him what I already told him".
So he's testing and then tells him again to update the scope.

Later in the daily the the dev's update is besically "they won't test my ticket..."

It would have taken him like 1 fucking minute to update the ticket...

The whole QA team was always trying to being helpful and even when the tickets where sometimes not 100% clear we always made it work... but now we are more and more going towards "MR does not meet ticketdescription, fix it" and "I don't care if its just a small thing... fix it and then come back to me"...

Seriously frustrating some times...

I am going to rant about this here because there is nowhere else where I can "SCREAM".

My work process....

Working on a project that does not have mockups nor a plan. I am building as I go. Design, infrastructure, EVERYTHING. Because my boss is a "genius".

And the project goes like this....

1. Boss tells me to build something.
2. I tell him the functionalities and design.
3. Boss, "Figure out yourself and we will see how it goes".
4. Me, Builds something.
5. Boss does not like it and demands changes.
6. I make the changes.
7. Repeat.

1 year and a half for one project that is a simple e-commerce. Show the products, a search functionality, users sign in and can order and show their orders.

A simple page in which does not take time, but without a plan, without A FUCKING PLAN this project will go on forever.

I am losing my mind. I put on test and tell my boss to test it for bugs. He demands a meeting and tells me, "we need to add this".

OH FOR FUCKS SAKE. TEST THE SITE FOR BUGS YOU FUCKING USELESS THING. I WILL FIX THE BUGS AND THEN WE WILL TALK FOR NEW MODULES.

I am doing documentation, database infrastructure, front-end, back-end, testing (because my boss cannot do it. It took him 2 week to start testing for some things after asking him every fucking day "Did you test it", "Did you test it").

Maintaining out CRM for bugs and new modules and maintaining our company's website.

The Odyssey of the Tenacious Tester:

Once upon a time in the digital kingdom of Binaryburg, there lived a diligent software tester named Alice. Alice was on a mission to ensure the flawless functionality of the kingdom's latest creation – the Grand Software Citadel.

The Grand Software Citadel was a marvel, built by the brilliant developers of Binaryburg to serve as the backbone of all digital endeavors. However, with great complexity came an even greater need for meticulous testing.

Alice, armed with her trusty testing toolkit, embarked on a journey through the intricate corridors of the Citadel. Her first challenge was the Maze of Edge Cases, where unexpected scenarios lurked at every turn. With a keen eye and a knack for uncovering hidden bugs, Alice navigated the maze, leaving no corner untested.

As she progressed, Alice encountered the Chamber of Compatibility, a place where the Citadel's code had to dance harmoniously with various browsers and devices. With each compatibility test, she waltzed through the intricacies of cross-browser compatibility, ensuring that the Citadel would shine on every screen.

But the true test awaited Alice in the Abyss of Load and Performance. Here, the Citadel's resilience was put to the test under the weight of simulated user hordes. Alice, undeterred by the mounting pressure, unleashed her army of virtual users upon the software, monitoring performance metrics like a hawk.

In the end, after days and nights of relentless testing, Alice emerged victorious. The Grand Software Citadel stood strong, its code fortified against the perils of bugs and glitches.

To honor her dedication, the software gods bestowed upon Alice the coveted title of Bug Slayer and a badge of distinction for her testing prowess. The testing community of Binaryburg celebrated her success, and her story became a legend shared around digital campfires.

And so, dear software testers, let the tale of Alice inspire you in your testing quests. May your test cases be thorough, your bug reports clear, and your software resilient against the challenges of the digital realm.

In the world of software testing, every diligent tester is a hero in their own right, ensuring that the digital kingdoms stand tall and bug-free.

Spent most of this week busting my ass working on a hotfix that came out of nowhere with mega high priority. This annoys me greatly because the hotfix wasn't even fixing a bug, it was adding new functionality because certain customers were being blocked from testing without this specific feature. In my humble opinion, given that we release every weekend, hotfixes should be reserved for actual critical bugs. But anyway, as I probably could have predicted, the code got to QA and exploded. Literally nothing works.
This is what happens when you try to rush out features to satisfy customers. If you try to rush something that is late, you WILL make it later.
Meanwhile there's an issue I'm supposed to be fixing for our next release which goes out this weekend and I've had no time to even look because of this hotfix. And now it's the end of the day and I just feel worn out from stress, tomorrow will no doubt be similar.

Two weeks before the release of a major new version of an application I'm working on, the testers finally got round to testing the new functionality (a set of a few features and a new page). They didn't agree with the requirements and got the requirements to change with the product owner.

The product owner now says that these changes "are easy to implement" and "the new requirements are clear" even though the other devs and I all don't understand the change. How would a product owner even know it is easy to implement?

Fun times.

So.. playing around with jquerys load() function because I'm trying to implement some updating functionality to a specific div. After researching a bit, it didn't seem like it would be too difficult.. but I could not for the life of me figure out why my template was not displaying! I tried testing with just some basic html and it worked fine. Even took a few snippets from my template and again.. it worked. As soon as I copy/pasted my whole template, the page renders nothing. I was seriously getting frustrated so I started entering the template manually testing each line. It worked until I got to this special div container I made.. went and looked at the css properties for it and..

display: none;

*facepalm*
I forgot I had set it to none because I was using jquerys fadeIn() function xD seriously??

My work product: Or why I learned to get twitchy around Java...

I maintain a Java based test system, that tests a raster image processor. The client is a Java swing project that contains CORBA bindings to the internal API of the raster image processor. It also has custom written UI elements and duplicated functionality that became available in later versions of Java, but because some of the third party tools we use don't work with later versions of Java for some reason, it's not possible to upgrade Java to gain things as simple as recursive directory deletion, yes the version of Java we have to use does not support something as simple as that and custom code had to be written to support it.

Because of the requirement to build the API bindings along with the client the whole application must be built with the raster image processor build chain, which is a heavily customised jam build system. So an ant task calls out to execute a jam task and jam does about 90% of the heavy lifting.

In addition to the Java code there's code for interpreting PostScript files, as these can be used to alter the behaviour of the raster image processor during testing.

As if that weren't enough, there's a beanshell interface to allow users to script the test system, but none of the users know Java well enough to feel confident writing interpreted Java scripts (and that's too close to JavaScript for my comfort). I once tried swapping this out for the Rhino JavaScript interpreter and got all the verbal support in the world but no developer time to design an API that'd work for all the departments.

The server isn't much better though. It's a tomcat based application that was written by someone who had never built a tomcat application before, or any web application for that matter and uses raw SQL strings instead of an orm, it doesn't use MVC in any way, and insane amount of functionality is dumped into the jsp files.

It too interacts with a raster image processor to create difference masks of the output, running PostScript as needed. It spawns off multiple threads and can spend days processing hundreds of gigabytes of image output (depending on the size of the tests).

We're stuck on Tomcat seven because we can't upgrade beyond Java 6, which brings a whole manner of security issues, but that eager little Java updated will break the tool chain if it gets its way.

Between these two components we have the Java RMI server (sometimes) working to help generate image data on the client side before all images are pulled across a UNC network path onto the server that processes test jobs (in PDF format), by reading into the xref table of said PDF, finding the embedded image data (for our server consumed test files are just flate encoded TIFF files wrapped around just enough PDF to make them valid) and uses a tool to create a difference mask of two images.

This tool is very error prone, it can't difference images of different sizes, colour spaces, orientations or pixel depths, but it's the best we have.

The tool is installed in both the client and server if the client can generate images it'll query from the server which ones it needs to and if it can't the server will use the tool itself.

Our shells have custom profiles for linking to a whole manner of third party tools and libraries, including a link to visual studio 2005 (more indirectly related build dependencies), the whole profile has to ensure that absolutely no operating system pollution gets into the shell, most of our apps are installed in our home directories and we have to ensure our paths are correct for every single application we add.

And... Fucking and!

Most of the tools are stored as source bundles in a version control system... Not got or mercurial, not perforce or svn, not even CVS... They use a custom built version control system that is built on top of RCS, it keeps a central database of locked files (using soft and hard locks along with write protecting the files in the file system) to ensure users can't get merge conflicts by preventing other users from writing to the files at all.

Branching is heavy weight and can take the best part of a day to create a new branch and populate the history.

Gathering the tools alone to build the Dev environment to build my project takes the best part of a week.

What should be a joy come hardware refresh year becomes a curse ("Well fuck, now I loose a week spending it setting up the Dev environment on ANOTHER machine").

Needless to say, I enjoy NOT working with Java. A lot of this isn't Javas fault, but there's a lot of things that Java (specifically the Java 6 version we're stuck on) does not make easy.

This is why I prefer to build my web apps in python or node, hell, I'd even take Lua... Just... Compiling web pages into executable Java classes, why? I mean I understand the implementation of how this happens, but why did my predecessor have to choose this? Why?

Coding the new functionality, 2 hours.
Writing and testing the unit test and e2e test, 2 weeks.

This is an actual transcript...
Since it's way too long for the normal 5000 characters, hence splitting it up...

Infra Guy: mr Dev, could you please give some rational for update of jjb?
Dev: sparse checkout support is missing
Infra Guy: is this support mandatory to achive whatever you trying to do?
Dev: yes
Infra Guy: u trying to get set of specific folder for set of specific components?
Dev: yes
Infra Guy: bash script with cp or mv will not work for you?
Dev: no
Infra Guy: ?
Dev: when you have already present functionality why reinvent the wheel
Dev: jenkins has support for it
Dev: the jjb is the bottle neck
Infra Guy: getting this functionality onto our infra would have some implications
Dev: why should I write bash script if jenkins allows me to do that
Dev: what implications ??
Infra Guy: will you commit to solve all the issues caused by new jjb?
Dev: you show me the implications first
Infra Guy: like a year ago i have tried to get new jjb <commit_url>
Infra Guy: no, the implications is a grey area
Infra Guy: i cant show all of them and they may hit like in week or eve month
Dev: then why was it not tackled
Dev: and why was it kept like that
Infra Guy: few jobs got broken on something
Dev: it will crop up some time later
Dev: if jobs get broken because of syntax
Dev: then jobs can be fixed
Dev: is it not ???
Infra Guy: ofc
Infra Guy: its just a question who will fix them
Dev: follow the syntax and follow the guidelines
Dev: put up a test server and try and lets see
Dev: you have a dev server
Dev: why not try on that one and see what all jobs fails
Dev: and why they fail
Dev: rather than saying it will fail and who will fix
Dev: let them fail and then lets find why
Dev: I manually define a job
Dev: I get it done
Infra Guy: i dont think we have test server which have the same workload and same attention as our prod
Dev: unless you test how would you know ??
Dev: and just saying that it broke one with a version hence I wont do it
Infra Guy: and im not sure if thats fair for us to deal with implication of upgrading of the major components just cause bash script is not good enough for u
Dev: its pretty bad
Infra Guy: i do agree
Infra TL Guy: Dev, what Infra Guy is saying is that its not possible to upgrade without downtime
Infra Guy: no
Dev: how long a downtime are we looking at ??
Infra Guy: im saying that after this upgrade we will have deal with consequences for long time
Infra Guy-2: No this is not testing the upgrade is the huge effort as we dont have dev resources to handle each job to run
Dev: if your jjb compiles all the yaml without error
Dev: I am not sure what consequences are we talking of
Infra Guy: so you think there will be no consequences, right?
Dev: unless you take the plunge will you know ??
Dev: you have a dev server running at port 9000
Infra Guy: this servers runs nothing
Dev: that is good
Dev: there you can take the risk
Infra Guy: and the fack we have managed to put something onto api doesnt mean it works
Dev: what API ?
Infra Guy: jenkins api
Infra Guy: hmmm
Dev: what have you put on Jenkins API ??
Infra Guy: (
Dev: jjb is a CLI
Infra Guy: ((
Dev: is what I understand
Dev: not a Jenkins API
Infra Guy: (((
Dev: (((((
Infra Guy: jjb build xmls and push them onto api
Infra Guy: and its doent matter
Dev: so you mean to say upgrading a CLI is goig to upgrade your core jenkisn API
Dev: give me a break
Infra Guy: the matter is that even if have managed to build something and put it onto api
Infra Guy: doesnt mean it will work
Dev: the API consumes the xml file and creates a job
Infra Guy: right
Dev: if it confirms to the options which it understands
Dev: then everything will work
Dev: I am actually not getting your point Infra Guy
Infra Guy: i do agree mr Dev
Dev: we are beating around the bush
Infra Guy: just want to be sure that if this upgrade will break something
Infra Guy: we will have a person who will fix it
Dev: that is what CICD is supposed to let me know with valid reasons
Dev: why can't that upgrade be done
Infra Guy: it can be done
Infra Guy: i even have commit in place

I like the people I work with although they are very shit, I get paid a lot and I mostly enjoy the company but..

Our scrum implementation is incredibly fucked so much so that it is not even close to scrum but our scrum master doesn't know scrum and no one else cares so we do everything fucked.

Our prs are roughly 60 file hangers at a time, we only complete 50% of our work each sprint because the stories are so fucked up, we have no testers at all, team lead insists on creating sql table designs but doesn't understand normalisation so our tables often hold 3 or 4 sets of data types just jammed in.

Our software sits broken for months on end until someone notices (pre release), our architecture is garbage or practically non existent. Our front end apps that only I know the technology have approaches dictated by team lead that has no clue of the language or framework.

Our front end app is now about 50% tech debt because project management is so ineffectual and approaches are constantly changing. For instance we used to use view models for domain transfer objects... Now we use database entities, so there is no commonality between models but the system used to have shared features relying on that..sour roles and permissions are fucked since a role is a page regardless of the pages functionality so there is no ability to toggle features, but even though I know the design is fucked I still had to implement after hours of trying to convince team lead of it. Fast forward a few months and it's a huge cluster fuck to enforce.

We have no automated testing of any sort or manual testing in place.

I know of a few security vulnerabilities I can nuke our databases with but it got ignored.

Pr reviews are obviously a nightmare since they're so big.

I just tried to talk to scrum master again about story creation since any story involving front end ui as an aspect of it is crammed in under one pointed story as sub tasks, essentially throwing away any ability to calculate velocity. Been here a year now and the scrum master doesn't know what I mean by velocity... Her entire job is scrum master.

So anyway I am thinking about leaving because I like being a developer and it is slowly making me give up on doing things to a high standard and I have no chance of improving things, but at the same time the pay is great and I like the people.

A very long rant.. but I'm looking to share some experiences, maybe a different perspective.. huge changes at the company.

So my company is starting our microservices journey (we have a 359 retail websites at this moment)

First question was: What to build first?

The first thing we had to do was to decide what we wanted to build as our first microservice. We went looking for a microservice that can be used read only, consumers could easily implement without overhauling production software and is isolated from other processes.

We’ve ended up with building a catalog service as our first microservice. That catalog service provides consumers of the microservice information of our catalog and its most essential information about items in the catalog.

By starting with building the catalog service the team could focus on building the microservice without any time pressure. The initial functionalities of the catalog service were being created to replace existing functionality which were working fine.

Because we choose such an isolated functionality we were able to introduce the new catalog service into production step by step. Instead of replacing the search functionality of the webshops using a big-bang approach, we choose A/B split testing to measure our changes and gradually increase the load of the microservice.

Next step: Choosing a datastore

The search engine that was in production when we started this project was making user of Solr. Due to the use of Lucene it was performing very well as a search engine, but from engineering perspective it lacked some functionalities. It came short if you wanted to run it in a cluster environment, configuring it was hard and not user friendly and last but not least, development of Solr seemed to be grinded to a halt.

Elasticsearch started entering the scene as a competitor for Solr and brought interesting features. Still using Lucene, which we were happy with, it was build with clustering in mind and being provided out of the box. Managing Elasticsearch was easy since there are REST APIs for configuration and as a fallback there are YAML configurations available.

We decided to use Elasticsearch since it provides us the strengths and capabilities of Lucene with the added joy of easy configuration, clustering and a lively community driving the project.

Even bigger challenge? Which programming language will we use

The team responsible for developing this first microservice consists out of a group web developers. So when looking for a programming language for the microservice, we went searching for a language close to their hearts and expertise. At that time a typical web developer at least had knowledge of PHP and Javascript.

What we’ve noticed during researching various languages is that almost all actions done by the catalog service will boil down to the following paradigm:

- Execute a HTTP call to fetch some JSON

- Transform JSON to a desired output

- Respond with the transformed JSON

Actions that easily can be done in a parallel and asynchronous manner and mainly consists out of transforming JSON from the source to a desired output. The programming language used for the catalog service should hold strong qualifications for those kind of actions.

Another thing to notice is that some functionalities that will be built using the catalog service will result into a high level of concurrent requests. For example the type-ahead functionality will trigger several requests to the catalog service per usage of a user.

To us, PHP and .NET at that time weren’t sufficient enough to us for building the catalog service based on the requirements we’ve set. Eventually we’ve decided to use Node.js which is better suited for the things we are looking for as described earlier. Node.js provides a non-blocking I/O model and being event driven helps us developing a high performance microservice.

The leap to start programming Node.js is relatively small since it basically is Javascript. A language that is familiar for the developers around that time. While Node.js is displaying some new concepts it is relatively easy for a developer to start using it.

The beauty of microservices and the isolation it provides, is that you can choose the best tool for that particular microservice. Not all microservices will be developed using Node.js and Elasticsearch. All kinds of combinations might arise and this is what makes the microservices architecture so flexible.

Even when Node.js or Elasticsearch turns out to be a bad choice for the catalog service it is relatively easy to switch that choice for magic ‘X’ or component ‘Z’. By focussing on creating a solid API the components that are driving that API don’t matter that much. It should do what you ask of it and when it is lacking you just replace it.

Many more headaches to come later this year ;)

Skipping jasmine tests- especially ones on partials (not the controller). Seriously, QA has automated test suites to test UI functionality. If it takes 30 mins to write the code and 3 hours to write the tests... it may just not be worth the effort when there already is automated testing.

Ugh I hate skipping them but you know how to test the UI? Use the UI.

While hand-testing comment-posting functionality messed up the migrations and damaged local db. Had to recreate the whole set up (users, posts, etc) in order to resume the testing by hand.

Should've written the tests ;(

When you change three lines in a PR with 100 changes that breaks the whole functionality, and it starts working flawlessly 😕 seems like testing PR before merge could have solved the doomsday

Is a company bad if it puts constant pressure on developers to quickly deliver bits and pieces of functionality the client desires with little attention to quality? The focus is then on pleasing the client at the most shallow level by providing a stream of quick fixes, only to be met with an equal amount of bug reports, even after the full testing stack by the testing team.

wait a minute... I thought Google's home page was supposed to be super clean...

Was testing some program functionality and downloaded this page... 300kb...

Working on a security testing tool that's purpose and use has been overstated by the staff engineer and product owner but no team wants to use it and everyone else in security second guesses if it should exist. Oh, also no documentation on how to use it, and you have to figure out how to use it. The tool has been developed and passed down from multiple people who each developed it differently and have all left the company now. No code reviews exactly exist so every functionality has been assumed to work my PO, SM and Staff Engineer, thus questioned when you bring up something that you're not sure works. Constantly redeploying to production at a timezone that's too early for your country but done to proviide minimal damage to the application for customers in case something goes wrong.

Upside is, you're leaving the team in a week and feel sorry for whoever is going to handle this next.

A philosophical question about maintenance/updating.

There is no need to repeat the reasons we need to update our dependencies and our code. We know them/ especially regarding the security issues.
The real question is , "is that indicates a failure of automation"?

When i started thinking about code, and when also was a kid and saw all these sci fi universes with robots etc, the obvious thing was that you build an automation to do the job without having to work with it anymore. There is no meaning on automate something that need constant work above it.

When you have a car, you usually do not upgrade it all the time, you do some things of maintance (oil, tires) but it keeps your work on it in a logical amount.
A better example is the abacus, a calculating device which you know it works as it works.

A promise of functional programming is that because you are based on algebraic principles you do not have to worry so much about your code, you know it will doing the logical thing it supposed to do.
Unix philosophy made software that has been "updated" so little compared to all these modern apps.
Coding, because of its changeable nature is the first victim of the humans nature unsatisfying.

Modern software industry has so much of techniques and principles (solid, liquid, patterns, testing that that the air is air) and still needs so many developers to work on a project.
I know that you will blame the market needs (you cannot understand the need from the start, you have to do it agile) but i think that this is also a part of a problem .
Old devices evolved at much more slow pace. Radio was radio, and still a radio do its basic functionality the same war (the upgrades were only some memory functionalities like save your beloved frequencies and screen messages).

Although all answers are valid, i still feel, that we have failed. We have failed so much. The dream of being a programmer is to build something, bring you money or satisfaction, and you are bored so you build something completely new.

Spent half a day working on some code to add some functionality. Ran into some binary assumptions and found workarounds. Got everything implemented and close to start testing things. Not a lot of code, but a lot of places that needed careful attention to detail. Started looking at the final code needed for initializing things. Found that all the code I wrote would not be needed if I just initialize some things differently. Realized I don't need all this code. The code is literally redundant.

git checkout <changed files>

Okay, now I understand the code better. I am ahead because I am not maintaining code I don't need. Half a day of reading the code helps me understand everything that is there.

Life is good. 😀

When you have testing team ho can trust everything you say is a functionality not a bug !

How the fuck you define a prototype in Android development?

Is it something like "here is the design showing all possible working and functionality, make a working app with all cloud calls integration in 7 days.

If its working as expected, we will just do some ui enhancements, replace your testing firebase with our own broken cloud, replace default pickers with some library or our own broken pickers and spend 30 days on all this plus the testing"

Is this what you define as a prototype? Like yeah the new intern will do the heavy lifting in all his prototype and then we will start the work on our end, in the meantime giving the intern another new prototype idea and scolding him for delay?

Since a friend of mine owns a domain for an open-source project and manages pretty much everything, including dealing with a db for registered accounts, I'm currently not really able to help when it comes to UI/UX things and frontend, besides the "main editor", which is like the core functionality of the project. I would like to set up smth like docker (on Windows 10 home, which is already not suitable, great start🤦) for some kind of pseudo-db all inclusive functionality thingy to be able to run a working example locally. Also a goal would be to switch to Typescript, include testing, to use webpack and to automate as much as possible.
Sad part is, I don't even know where to start and I'm also 100% sure that I will do almost everything wrong from research to implementation.😐

- we need to show progress to the business
- but rewriting this component to be generic AND implementing it on the whole website can't be completed in one sprint. This will require a lot of regression testing, modifications to existing functionality, etc. we need to split it in two
- that's disappointing

we were forced to write shitty patchworks for over 2 years and now everyone's surprised it takes time to replace with proper code -.-

#Suphle Rant 1: Laravel closing the gap

This is the first of a series of long overdue rants regarding Suphle, because I have had so so much to grumble about over the last ~2 years building it. A bit of introduction: I compiled a list of all the challenges I faced in my time as a salaried PHP developer. I also gathered issues complained about by other developers in a laravel group I'm part of, and decided to solve them at the framework level since they're avoidable. I also borrowed impressive features encountered in my time working with other languages and invented a new one, as well. I quit my job last July, still haven't get a new one yet cuz office workload kept conflicting with Suphle development. I concluded all work and testing on it back in August/September but it's yet to be officially released since the docs is still in progress.

Anyway, yesterday, I stumbled upon what is IMO the most progressive /tangible update I've seen in all my time following Laravel updates. It's called [precognition](don't have enough rep to post the PR link but you can search on their repo), and contains features that are actually beneficial to both developer and end user. It also turns out to be functionality that was part of Suphle's bragging rights. Their DX is still tacky but I'm devastated cuz it's a matter of time before they work it out. Makes me wonder what the quality of all I've built would be in a year if it doesn't become big enough to attract frequent contribution. I guess there's only so much one can do against a community.

Later that evening, I found a developer from my country on twitter who claims to be making a decent living. A little snooping around his profile informed me he's building his own back end framework but in NodeJS. I know with every degree of certainty that what he'll eventually do can't hold a candle against Suphle in overall functionality or thoroughness. Not a dick measuring contest but when your motive isn't significant innovation, you'll neither plan properly nor even know what exactly to build. You'll just reinvent the wheel as an academic exercise

Yet, I can't help but have that sinking feeling he's winging it, while making a windfall with his dozens of freelance projects. It kind of feels like I shortchanged myself, and Suphle's shelf life will suffer the same fate as a hobby project for 10 stars (which I don't even have yet!!). I reached out to him to rub minds together but he ignored. More pain.

I'll get over this and return to work on the docs, but from the look of things, the end isn't an appealing or expected /deserved one

In my initial days as a web developer, i was assigned a task, to implement a cart share functionality in an e commerce company.
I made the functionality and tested on my system.
Result: working good.

Pushed it to beta testing environment.
Resilt: working good.

Pushed to pre production environment.
Result: working good.

Pushed to live site.
Result: 😀 Error in live site..
So a call comes to me from my team lead..
Asks what was the issue...

Me: i dont know either.
....

After 3-4 hrs:
I found the reason.
My system, beta test env, pre prod env are all having latest php version (5.6 i guess)
But the live server had old version of php.

Me: laughed like anything.
I didn't know that these things would matter in such a great level.

Moral of the story:
Be one with the force (server in this case)

I really got to stop having near-blind faith in the project dependency management and the testing skills of people with multiple years of experience.

Production code of a new client uses a fixed 0.x.y version of a third-party library for over a year for a functionality that was only working stably a few major versions later... And somehow nobody ever noticed due to insufficient testing