Should a programmer always write code that validator produces no errors?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

• 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.

Answer 4

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.."