3 ms·

I think the quality standard is different. Front end has to "look good" and be "good enough to use". Little finnicky errors are often tolerated as a user can b

by rusk 8y ago

I think the quality standard is different. Front end has to "look good" and be "good enough to use". Little finnicky errors are often tolerated as a user can be expected to work around a certain issues. Since issues can be quickly spotted code hygiene and rigorous software quality practices aren't as important. Also, performance and resource utilisation aren't as important, to a degree anyway. Back-end, unsupervised, or high-performance code on the other hand is largely invisible to the end user. It has to run for long times without error and if something goes wrong can be tricky to get at, diagnose, and repair. These requirements demand a higher level of code-hygene. Coding standards, logging, documentation, automated testing etc. etc. which makes developing this kind of code much more expensive than you would expect for something that you ultimately "can't see" (unless something goes wrong). I've seen organisations struggle with this dichotomy where they're trying to do both without appreciating these distinctions. Product managers getting annoyed that it takes so long to get GUI changes in, while engineers getting annoyed that their (necessary) tech process overhead often gets shorted because "it doesn't add value". You can get away with taking short-cuts on the front-end, that you can't get away with elsewhere but ultimately this leads to a messy, unwieldy codebase with mountains of tech-debt and once you get to a certain point it makes sense to just throw it out and start it again. Though "starting again" is considered to be something you should never do [0] with front-end stuff it's a little easier to get away with because, like I say it's all visual, and a good bit easier to test and play with and tease out the subtleties. [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

godinaa 8y ago
I disagree. Rigorous code standards are just as necessary on front-end code as back-end. In my experience, no code review, poor design or documentation, and lax standards lead to jittery experiences. For example, people write complex blocking code that causes the page to freeze for moments while that processing is happening. People write event handlers that execute too often and slow user interaction.
- rusk 8y ago
  My point was though, that such issues can be quickly picked up just by using the application, and you can usually elicit the causal factors by prodding at it. Often times such issues in non-UI code can go for years without it being noticed. But broadly speaking yes I agree, but one or two of my line managers in the past would not.

by rusk 8y ago

godinaa 8y ago

I disagree. Rigorous code standards are just as necessary on front-end code as back-end. In my experience, no code review, poor design or documentation, and lax standards lead to jittery experiences. For example, people write complex blocking code that causes the page to freeze for moments while that processing is happening. People write event handlers that execute too often and slow user interaction.

rusk 8y ago
My point was though, that such issues can be quickly picked up just by using the application, and you can usually elicit the causal factors by prodding at it. Often times such issues in non-UI code can go for years without it being noticed. But broadly speaking yes I agree, but one or two of my line managers in the past would not.