3
$\begingroup$

I took a course on web page development. The lecturer said that one should always write web pages such that validator produces no errors.

I also know a person who has studied economics and business. He said that perfectionism is bad, one should do the work good enough that customer is satisfied.

So what do the computer scientists teach about this? How much perfectionism is needed in programming or web development? Is it needed to write always code that follows the standards or is sometimes nonperfect code acceptable?

$\endgroup$
4
  • 4
    $\begingroup$ This is really more of a software engineering question than a CS question, and what people teach probably varies widely. Of course, it depends. Classic quote: "cheap, fast, good: pick two". If your company needs a large feature in a week, and delivering it quickly is the critical factor, you'll almost certainly have to cut quality corners and take on technical debt. $\endgroup$
    – ggorlen
    Aug 4, 2023 at 20:19
  • 1
    $\begingroup$ Do you and your neighbor drive the same make of car? No? So which one of you bought the wrong car then? This is the core issue with your question, you are assuming that there is one correct opinion that applies universally. This very much is not the case. $\endgroup$
    – Flater
    Aug 7, 2023 at 5:46
  • $\begingroup$ This question could be further contained by defining "validator." My first thought was validator.w3.org and/or jigsaw.w3.org/css-validator — in which case I'm inclined to say "yes, there should be no errors." But this fact isn't clear from the question. $\endgroup$ Aug 17, 2023 at 23:43
  • $\begingroup$ @ggorlen it is soon, cheap, lots of features. Pick 2. (However, lots of features often leads to not good, but that is another story.) $\endgroup$ Aug 27, 2023 at 21:40

4 Answers 4

3
$\begingroup$

This depends on the purpose of the code. If it is code for your own use and you can accept and tolerate errors then being a bit sloppy about correctness is fine.

But for public facing code, such as that supporting a web site all care should be taken to eliminate errors other than things like simple spelling errors in user facing text. But if the code supports the behavior of the site then it should be as error-free as you can make it. But even those simple spelling errors have an effect on your reputation.

The analogy with economics/business doesn't hold up as those are human endeavors with the possibility of divergent views about what is correct and so "perfection" is only in the eyes of one beholder. Programming, on the other hand, is a technical pursuit in which the standards are much clearer.

Moreover, errors in a web site can potentially open the site and its underlying servers to attack. This would be especially important if any user identifiable information is maintained on the server, but also if you desire continued operation under your own control.

If a validator indicates errors then you should determine why and how to correct them. Being sloppy about accepting errors has cost people and companies both in money and in reputation. Get it right.

$\endgroup$
1
  • 3
    $\begingroup$ "Programming, on the other hand, is a technical pursuit in which the standards are much clearer." I don't see how this argument can be made by anyone who has worked in programming outside of academia. Software development is stereotypically rife with cases of non-technical management setting boundaries that force corners to be cut. Software development pretty much always kowtows to the economics/business of how a company is run. That is not to say that one shouldn't strive to write quality code, but striving to do so and claiming it is inherently done are two very different things. $\endgroup$
    – Flater
    Aug 7, 2023 at 5:53
4
$\begingroup$

I would say that this is cultural decision rather than an objective one. It really doesn't matter that much when you're working alone on a small project that no one's livelihood depends on. But when you're working with people over a long period of time, and there are real stakes to errors or loss of productivity, this becomes an important decision. And in this sense, for a long-term project, I would define 'yourself in 6 months' as a different person.

I would agree that perfectionism as such is bad, but that's almost a tautology, since the word "perfectionism" has negative connotations. The term I'd recommend instead is "pragmatism", which I'd define as such - we want to build our systems in such a manner that will provide the most long-term benefit for the least effort.

This is clearly a tradeoff, and the particular point on this scale which we would consider "pragmatic" will vary strongly between projects. For example, when you're looking to build a web application to quickly capture an emerging market, you should absolutely "move fast and break things", since the benefit from the system depends so strongly on time-to-market, and in any case, the code is likely to be rewritten many times, as you iterate on the product to find that elusive "product-market fit". But on the other hand, if you're coding for a space mission, and you know that any code change after launch, if even possible, would have a non-negligible likelihood of bricking the system and causing a hundred million dollar loss, pragmatism will absolutely lean towards dealing with every single validator issue.

In general, in every project, this should be a conversation between all stakeholders, on "what pragmatism means to us". Or in other words, which types of issues we are willing to live with, and which types of issues are high-risk and likely to cause us more trouble later than the cost of dealing with them early. And then once the decision is made, I would encourage the team to put that into code as linter settings (preferably in a shared pre-commit hook in the source control system). These linter settings would define which types of issues will block a change from being integrated, and which ones are actually ok. And even then, teams can decide to "silence" a particular linter issue, but that would then need to be an explicit decision.

To sum up and circle back to your question, this is the manner in which I would teach this - the value of validator/linter warnings is a cultural issue for a particular team working on a particular project, which aims to pragmatically reduce the risk of project failure and wasted effort, and should be defined as code itself, which can then evolve as the project itself evolves.

$\endgroup$
2
$\begingroup$
  • Web-browsers vary when processing code that is not valid.
  • Web-browsers have varying quirks.
  • Web-browsers are lax at telling you that the code is not valid.
  • You have no control on which web-browser your users use.

More generally,

  • Adding more code to a working but not correct code base can break it in unpredictable ways. This can take a long time to find the cause and fix.
  • Running the validator is cheep, or can be (hook automated tests on to save or commit: the earlier the better).

Therefore, run your code through a validator.

Or hire a very large technical support team to take customers phone calls, and to tell them to use xxxxxxxxx web-browser. And, allocate more time/people(beware MMT) to write the code.

$\endgroup$
1
  • $\begingroup$ Just today I ran some html generated by ASP.Net through a validator to find a spurious attribute that was causing an html-to-PDF generator to fail. So, validators can be helpful. I had not used one before, but I knew they existed. Otherwise, I might never have found the needless in the htmlstack and couldn't have finished my project. $\endgroup$
    – Scott Rowe
    Sep 15, 2023 at 1:11
1
$\begingroup$

As others already said, it highly depends on context: If your company specializes in prototypes and proof-of-concept, perfection (in certain aspects) is unnecessary and not productive. If you can fix a rare error by turning it off and on again it, why spend weeks or months debugging that one special case. Of course, you can't do that everywhere, think planes, medical devices, power plant etc.

Let's have a closer look at the statement "perfectionism is bad, one should do the work good enough that customer is satisfied". On the surface it seems like a reasonable statement, why do more work than necessary? If you look a bit closer, you'll see that it doesn't hold up or is too simplified to be useful:

  • First of all, what if "the customer" demands perfection? For example, in regulated fields like medical or aviation, you have to deliver (close to) perfect code, otherwise you just don't get approved.

  • Then, there is a number of companies who are quite successfully distinguishing themselves from their competitors by not just being good enough but as close to perfect as possible. (And others don't even satisfy the customers needs but the product is so cheep that no one complains).

  • Software engineering is also notorious for having a large discrepancy between what a customer 'wants' and what a customer 'needs', so using customers as requirement engineers might backfire. (If you customer says he needs 'Blockchain' or 'AI', there is a high chance that he actually needs to be laughed at). You as the developer should do the cost/benefit etc. analysis of what level of perfection is required.

  • Only looking at the end product, fails to see the whole picture. You can develop a product in two ways: First-time-right or a number of iterations. Both might lead to the same result, but the way there may differ vastly depending on the cost of each iteration, number of iterations and the cost to actually get it right on the first try.

So back to education, what is being taught (from my experience)? Perfection would be nice, but usually not achievable. There is no such thing as a bug free software, and then teach you methods to try and reduce number of bugs. There is also the mandatory "cost to fix a bug increases exponentially over time"-slide, indication to fix your bugs as early as possible. But what if your software is never intended to reach a maintenance state? Then you have the type of error or warning. If my 5000 lines of C code compile with 2 warnings, I will make very sure to get rid of these warnings or make sure they are REALLY not a problem. If my 50 lines of Verilog produce 200 Warnings, I don't actually care.

TLDR: My teachers have taught me and I always told others "well, it depends.."

$\endgroup$
1
  • $\begingroup$ You said regarding customers, "there is a high chance that he actually needs to be laughed at." I'm imagining Klingon developers here. Great hearty laughs, followed by friendly back slaps that knock them across the room. In a better world... "This is a good day for DRY, ha ha ha!" "Watch out for bugs!" $\endgroup$
    – Scott Rowe
    Sep 15, 2023 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.