#GENERATE PROVE ME WRONG MEME SOFTWARE#

#GENERATE PROVE ME WRONG MEME SOFTWARE#

I’ve talked to enough fellow software engineers to know I’m not alone. The fix was relatively easy, and the consequences of the bug were low, but this experience has been a recurring theme in my career building software.

That concern I had about overriding default terms and conditions, the thing I was told would never happen? Guess what was happening? Guess who was blamed for it, and who was asked to fix it? When I saw the details of the defect, I laughed out loud. Months later, just a few weeks before the software was to go live, a tester on the client side had found a defect, and it was assigned to me. Who the heck was I to question anyone, much less a senior executive of a company that was paying us money to build this product? I shrugged it off and promptly forgot about it. The ability to override the default terms and conditions was explicitly requested by the same person. This was a senior executive who had been at the company for years, knew the company’s business processes, and was chosen to oversee the software for a reason.

His exact words were spoken with complete and total confidence I naively asked the client, “Should I remove the input that allowed a user to override the right terms and conditions?” The response I got has been seared inside my brain ever since. It would violate one of the features explicitly agreed on in the business requirement that had the client’s signature. A user would pick one product type, which would generate the appropriate terms and conditions, but further along the workflow it would allow the user to pick a different product type and predefined terms and conditions. There was conditional verbiage that depended on the type of product being purchased, as well as which US state the customer was located in due to legal requirements.Īt some point, I thought I found a potential defect. I was tasked with generating dynamic terms and conditions. The main purpose of the software was to configure custom products on ecommerce sites. It’s not a bug, it’s feature…no wait, it’s a bugĮarly in my software career, I was placed on a project midstream in order to help increase the velocity of the team.

This article will talk about the relationship between requirements and software, as well as what an AI needs to produce good results. The hardest part about creating software is not writing code-it’s creating the requirements, and those software requirements are still defined by humans. The real problems are usually centered around what the software is supposed to do. Once you get the hang of the syntax, logic, and techniques, it’s a pretty straightforward process-most of the time. As someone who’s spent 15 years creating software from the specs these folks create, I find it hard to take all the worrying seriously.Ĭoding can be a challenge, but I’ve never had spent more than two weeks trying to figure out what is wrong with the code. They imagine all the business execs and product researchers will bypass most or all of their software developers and asking AI directly to build exactly what they think they want or need. With all the articles about just how amazing all the developments in AI have been, there’s plenty of hand wringing around the possibility that we, as software developers, could soon be out of a job, replaced by artificial intelligence.

Generate prove me wrong meme