I used to work at a company that placed a lot of people on a project that was written in C#, these people had no experience of C#. The project was for a government/public sector project. I am not surprised at all that these things happen.
I'm sorry, but you can't blame C#. It's like a surgeon blaming a unfamiliar scalpel manufacturer for a surgical mistake. This could be one of those if-it's-not-in-the-Acceptance-Criteria-,-even-if-it-makes-all-the-sense-in-the-world-,-don't-do-it kinds of things. Or, someone didn't do their due-diligence when writing them up.
not blaming c#, blaming the company on putting people with no skill in c# on a c# project
Kinda washes. But bad design is bad design no matter the language. Having to deal with a unfamiliar language is a distraction for sure, but that's a productivity not a quality issue.
Of course it is, if your unfamiliar with a language and you can't expect the deadlines to be met with perfect design? a lot of time wasted on learning, which leads to rushed/panicked work and ultimately bad design. I don't think putting anyone with programming skills on any role is a solution or okay. You're assuming everyone has a great knowledge of programming and you end up putting some people under unnecessary stress. This could all be resolved by hiring/putting people on the team with the right skills.
It still doesn't matter how unfamiliar with a language one is. UI blunders are language agnostic. In fact, they're programmer agnostic. Even an expert in C# wouldn't necessarily be responsible for a UI decision. As programmers, we design software to accomplish a job and that doesn't always include usability. While some programmers are better at catching this stuff and maybe even have an eye for UI, most of the time (particularly with UI), we are told what the UI is supposed to look like. On the other side of things, I often catch UI blunders like this and am told to shut up an color. A non-technical person should have reviewed this an identified the potential problem.
"Uh hey... I realized that we asked for this, but is it really such a great idea to store the hydrochloric acid in an unmarked mountain dew bottle in the fridge next to the mountain dew?"
This was a management failure, not a programmer failure.
Thats a very romanticised view, especially when it comes to big contracting companies. I was on many projects where things needed to be done yesterday and there was minimal input if at all from a design team. Yes this is a management problem. However if your unfamiliar with a language and you have to hit a deadline and you're unfamiliar with how to create different ui components you're going to build you know. In this instance a drop down menu with two options. Often people reviewing these UI's aren't design/UX savvy, and just think "does it work", and it gets through.
These people are as stressed as each other and are pressured to get things done. There is a difference between being unfamiliar and not knowing anything at all about a language.
You're example is a little exaggerated, so lets keep to the point. A drop down menu might seem okay to some people and not to others, point proven by this article. I am willing to bet that this was done to get the job done, not to be perfectly designed. My example was to illustrate that people in charge of these contracts don't care to much about quality but how fast they can get a job done. If they have hot bodies on seats, then they can work on this project, not caring what they are skilled in.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.