Funny Excuses that Devs Give

Devs are very brilliant and also they come up with super weird reasons when you catch a bug in their work. I’m a dev too and it was absolutely hilarious to see that I myself use the same excuses sometimes. I came across a meme and I forgot to screenshot it. I remember a few points from it. If you are a web dev, I’m sure you could relate to most of these excuses. Give it a read also a thumbs up if you could relate to any one of these points 🙂

  • It worked yesterday – Yeah, it was the compilers birthday yesterday and hence it compiled the code perfectly. Today it’s not in the mood to compile and hence it is throwing the error. Maybe you should try running the program when the compiler is in good mood.
  • Caching – Did you hard refresh? Did you clear your cache? I think the cache in your browser can’t be cleared, please use a different computer. Let me clean your cache, I’m an expert in clearing. I think the program is cached in the cloud, let me clear that as well.
  • That is weird! – Yes, that’s weird, you expected it to run, but when the QA runs it, it becomes weird. Guess your program is allergic to other people who wanted to see your code working.
  • How is that possible?? It never occurred to me – Exactly, How is that possible?
  • That is an issue with the 3rd party library that we are using – Lemme raise an issue in GitHub. Hopefully they will fix this issue within this year until then we’ll push this bug to the backlog.
  • What is the version of Chrome that you are using? Is it v79.0.3945.117? – No, It’s v79.0.3945.116. That’s exactly why you are getting this error. Could you please update your chrome?
  • I’ve not touched the code in weeks – Yeah, it could be some junior dev trying to figure out what exactly this piece of code does.
  • Did you restart your computer? – Bugs get accumulated if you don’t restart your computer everyday. So just restart and run the program. The error would be resolved (And most of the time it works!! Don’t know how.. )
  • Even-though it doesn’t work, how does the UI feel? – Like crap 🙂
  • The user wouldn’t do it that way – You QA people how do you find some creepy steps to reproduce the bug. Once I had a bug reported that occurs only when you perform certain steps after 37 seconds (seriously??).
  • This is very minor, the user wouldn’t even notice it – Absolutely yes, the user won’t notice if the login page doesn’t show up 🙂
  • Finally, the most used excuse – It works on my machine!! – Yeah, we’ll ship your machine along with the product so that there is no error thrown.

Those were the most common excuses that a dev would give to the QA or the manager. Hope that most of us would have used these or heard people using these. If yes, hit like, share it with your fellow colleagues who give excuses like these. For more tech related posts follow this blog. This is SamuelLawrentz, do connect with me on LinkedIn for more updates.

Happy Coding!

Software Quality Factors & its trade-offs

Common Factors of Software Quality

Modifiability

Efforts needed for modification, fault removal or for environmental change.

Stability

Risk of unexpected effect of modifications.

Testability

Efforts needed for validating the modified software.

Usability

Ability of the software to be easily operated by a given user in a given environment.

Performance

Response time for given throughput.

Availability

Combination of Maturity, Fault tolerance and Recoverability for certain point in time.

Main Factors and Sub Factors of Software Quality

Main FactorsSub FactorsQuality Assurance Method
MaintainabilityChangeabilityModifiability
 StabilityStability
 TestabilityTestability
UsabilityOperabilityUsability
EfficiencyTime BehaviorPerformance
ReliabilityCombination of Maturity, Fault tolerance and RecoverabilityAvailability

Trade-offs between Software Quality Factors

  • Inappropriate use of resources can reduce availability. For example, holding a particular resource for a long time without using it may cause resource starvation and an inability to handle additional concurrent user requests.
  • Lack of documentation may delay management and future upgrades in the software.
  • Increased memory consumption may result in reduced performance.
  • Increased database server processing may result in reduced throughput.
  • Complex applications with many processing permutations are not tested consistently, perhaps because automated or granular testing cannot be performed if the application has a monolithic design. Design systems to be modular to support testing.
  • If the code base is large or complex, the refactoring of the codes will be difficult.
  • Lack of tracing ability will leads to difficulty in modifiability.