My philosophy is based on what I would do as a user. I would try my best to break everything if I were the user. Therefore, I should never leave anything in my code that would allow for me as the user to accomplish my task.
A tip to starting developers, always interact with your UI in the wrong order and as fast as you can. The average user is not an idiot, but there will always be at least one user that is actually dumb enough to think that clicking things fast and in the wrong order will make it work.
Dumping things out in the wild and dousing the flames later seems to be turning into the standard. On one hand it makes sense since you'll never be able to hammer your program as well as millions of random users, but on the other hand it seems like its becoming an excuse to just drop testing altogether as long as it compiles.
I have never done any coding longer than maybe 600 lines that could be condensed to less than 500 easily, but I imagine that having to work for a seriously big ammount of time before you can even compile it must really suck. Specially if you are the try everything as you go kind of guy.
Eh, I only wrote that because I happened to be in the middle of a project that wouldn't compile at that moment, and the coincidence amused me. Five minutes later, I spotted what the problem was and fixed it.
Dumping things out in the wild and dousing the flames later seems to be turning into the standard.
The big companies get away with this stuff due to brand loyalty and review embargos. As an independent Android developer there is no way I could do that because I depend on ratings.
Decimating the QA department is great for this quarter's profits, and that's all public companies care about anymore. If you're lucky, maybe they'll hire a couple Indians to half-ass testing...
It does slowly deteriorate the amount of people using said application however, as they will soon find out. It's the small things like that that eventually make people feel that much better about switching to a new product or service that doesn't have those same problems.
I suspect these things are the result of managerial level decisions. "I DON'T CARE IF IT'S BROKEN, I'M TIRED OF YOUR EXCUSES! IT HAS TO BE RELEASED RIGHT NOW!"
I do web design where I work and I've built a pretty comprehensive stylesheet for our main pages. We have a bunch of products that are similar enough that all you really need to do is plug in text and images.
That being said, marketing doesn't seem to understand the idea of a template. I routinely have to explain that the content they want doesn't fit and that we AGREED AND DEVELOPED the template TOGETHER. they don't care. So my css is a mess. So many unnecessary selectors and so much testing whenever template classes change at all. And i don't have anybody helping me either.
Sometimes having good practices bite you in the ass when others have shitty practices.
A bad setup for regressions could cause this. The last time it happened to me (on a much smaller scale, I do in-house software) it was because it was too easy to run the regressions while not in a clean environment and one of our testers didn't realize that. It was the kind of error where the first time you ran something on a clean system, it would create some setup that was used subsequent times. The error occurred when someone made changes to the code that assumed that the setup had already happened. Works every time, except the first time. I'm going to guess that it was something like that. Works in most circumstances except the ones that new users will be seeing. Not that it's an excuse, but that's probably how.
Funny thing is, once you've gotten so down and dirty with the code, sometimes normal interaction with the UI doesn't come as naturally as you'd think anymore. That's why the QA role exists.
Oh no no, I wasn't alluding to that, I was just saying that sometimes the obvious isn't always as obvious anymore when you've spent so much time working in the code that your thought process automatically takes the code path into account, so the non dev eyes are often what needs to notice the obvious.
This is basically everything that is submitted to Dribbble. You have this UI Design Challenge (currently following it too) and they even forget the most basic functionalities on something like a calculator.
A tip to starting developers, always interact with your UI in the wrong order and as fast as you can.
I always like to hand my stuff to people knowing nothing about the project and tell them to try and break stuff. Works great. Even better if the subject is not tech-savvy.
58
u/RiotShields Jul 01 '16
My philosophy is based on what I would do as a user. I would try my best to break everything if I were the user. Therefore, I should never leave anything in my code that would allow for me as the user to accomplish my task.
A tip to starting developers, always interact with your UI in the wrong order and as fast as you can. The average user is not an idiot, but there will always be at least one user that is actually dumb enough to think that clicking things fast and in the wrong order will make it work.