Comment by endymi0n | Hacker News Reader

Comment by endymi0n | Hacker News Reader

Oh my.

First off, most people would disagree in the first place whether coding is a „craft“, a science or even an art. He‘s saying craft (which is taught by other craftsmen), but what he probably means with his certification is college/uni.

Now I‘ve seen some of the worst sins of coding ever done by CompSci „master crafters“, with PhDs producing the cherries on the cake, with Java classes having longer names than the 80 character line limit.

And I don‘t even mean the designed-by-engineers frontends with UX level „crime against humanity“ (hello, early Hadoop).

I mean actual backends where CompSci education should shine, but even very smart people don‘t grasp the inherent cumulated complexity of massive systems. Because creating complexity is what you learn at Uni, rarely removing it.

Log4J wasn‘t a bug. It wasn‘t a backdoor. It was working as specified.

Look, this stuff is hard, one way or the other. I don‘t think we need even more gatekeeping and cover-your-ass to keep out the smart people who fail at university because they challenge the status quo and an outdated curriculum.

For sure. The problem isn't the people, though they definitely can be part of it, the problem is the process.

We never get a chance to reflect critically on our product. Imagine if an architect always would have their first draft constructed, without consulting a structural engineer, or the municipality or even the clients. They can't because if they did their company would either run out of money while they are at the drafting table, or a different company will build another shoddy but functional building faster and outpace them.

This is how software gets made, not necessarily by unqualified engineers, after my degree and 15 years of professional experience I feel my first draft on a software project has a reasonable chance of standing up in the high winds. But hasty and incomplete processes.

Agile like processes are an improvement, at least there is allotted time for improvements and corrections while the apartment building is still 1 story before and the customer can at least walk around a fully furnished apartment before we slam the other 99 on top.

We never get the chance to have our code audited when it is done, but before it is pushed to production. Best we can do is have a test suite with good statement coverage.

That being said, if we improved this situation software would be only marginally better. As awful as some of these problems are, they can slumber in software for decades before causing any harm, and frankly the amount of harm is quite limited.

> We never get a chance to reflect critically on our product.

Much of the Internet is built on publically available code, so anyone absolutely has the chance to critically review those projects and products. It's not clear how more gatekeeping would be an improvement; in fact, it would most likely make things worse.

I meant we don't get a chance to spend time on reflecting critically. What I was thinking of specifically is how many people that depend on Log4j have actually read the Log4j source code and reflected on whether its complexity was a security risk to their product.

How many people could go "Hey boss, we're gonna take 2 developers and spend the next two sprints moving our code base away from the industry standard logging framework because it has too many features".

> Much of the Internet is built on publically available code, so anyone absolutely has the chance to critically review those projects and products.

Sure:

- "Search for thing that do X"

- "npm install thing"

- "drinking cofee while it install 1000 deps"

- "it works"

- "end of critically thinking about this".

Why do you assume he's talking about colleges? This brings in a whole tangent about PhDs. CS PhDs shouldn't be expected to be software craftsmen any more than physicists should be expected to be extremely good carpenters. There's a little overlap in the skill-sets, but not much...

And in addition, you can be a master-coder but still suck at building products that solve your customer's problems.

No, no. A better comparison is like asking a physicist to be an engineer, and they should be reasonably good at that, though are usually lacking breadth of field. A CS PhD only reasons about things you can conceivably do on a computer, so being confused by a computer is a bad sign.

I disagree, for multiple reasons.

You can see the examples that were brought up here. Function name lengths, log4j, dealing complex systems. The first two definitely have nothing to do with CS, the last could be I guess, depending on the overall architecture, but lots of complex systems are just piles and piles of simple cruft. That's not a CS problem.

I don't think engineering is the right analogy here. A better one would be: Physicists exist, so do electrical engineers, and so do electricians. Physicists do discovery, electrical engineers do design, and electricians do implementation. And unsurprisingly, the electricians are the most likely of the three to require a license to do their work. Most programmers do implementation work.

Finally... No, I don't think a physicist would be a good engineer necessarily, particularly in this context. I mean, there exist branches of engineering that are more like physics -- yes, a physicist should be able to turn into an antennas guy, I guess. But I don't see why a physicist would be good at making designs out of digital building-blocks.

I'm not sure you're qualified to be commenting on this. Physicists, electrical engineers, and electricians all do discovery, but not all of them, and when they do, in different capacities.

There's definitely a lot of ways that physicists and scientists in general don't make good engineers. But a physicist has a good shot at being a reasonable engineer, after getting over the fact that they don't actually know everything and rules of thumb and physical models have to be created taking into account the complex emergent behavior we see in reality.

Same thing for CS PhDs and software engineering. They should be set up to undertake these things well. Not being able to do so is a mark against them. They don't immediately understand the complex emergent behavior of modern computer systems but neither has any SWE.

But all you’re saying boils down to the best practices being questionable, not that actually formalizing them into a proper craftsmanship wouldn’t make sense if we actually made better best practices.

You may talk about gatekeeping all day, but at the end of the day we do want the code in our pacemakers, cars and drones to be written by people following stringent standards, such that we have some idea of the quality.

The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards.

> not that actually formalizing them into a proper craftsmanship wouldn’t make sense if we actually made better best practices.

This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices.

If you think that's hyperbole on how this stuff works, it is not.

Furthermore, why would we assume people who enjoy debating best practices know actual master craftsmen?

> The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards.

The fact that said standards have been tried, and you don't know about them is a very strong argument against them.

> This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices.

This bureaucracy already exists, across myriads of RFCs, language design committees, FOSS groups, GitHub issues, Gitter servers, listservs. This process already exists, it just bumbles along inconsistently from community to community, company to company, project to project. And perhaps it should, because no size fits all. But it does exist and any attempt at formalizing them would not cause the start of a bureaucracy to exist, because such bureaucracies are in abundance in software development already.

If you define a bureaucracy making best practices so broadly as to capture GitHub issues, then the term becomes meaningless.

The sense the OP is trying to argue for (rather unsuccessfully) is a government bureaucracy that forbids people from deviating from those best practices. This is "serious", you see, whereas a competitive market of ideas leading to the organic development of best practices (what we have now) is "trivial".

The problem with that idea is that although it pleases people who associate government control with seriousness, the evidence it actually leads to better outcomes is mixed at best, and negative at worst. Regulatory capture is a real problem in many industries, and the attempt to fix things with regulated "best practices" can often be short term hacks that also inconveniently render more robust long term fixes illegal (finance has a lot of problems like this).

In the software world you can look at things like MISRA-C or FIPS to get a taste of what everything would look like if we don't keep systematically pushing back against these misguided people.

I don’t think government control is necessary. Much of what the OP is talking about can be undertaken by industry standards, or just by enough software engineers and software firms agreeing upon it, whether through a body like an IEEE or unofficially like how Agile spread in popularity.

We agree then! But the article author disagrees:

"Software practitioners should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice software engineering."

The article very clearly argues for government control of who can be a programmer or not (who is doing the revoking, otherwise). That would be destructive, fatal to innovation and totally counterproductive.

Sure, though this discussion doesn't have to be limited to the OP's constraints.

The issue with standards is that they only capture a very, very small part of the problem.

Let‘s look at the results: NASA probably uses some of the most rigorous development and testing methods in the world, but I‘d still rather trust my life to the flight control software of SpaceX who doesn‘t give a damn about education.

The banks losing data mentioned by OP are way more rigid in their hiring and certification standards than a Stripe for example. Who would you rather trust on security?

My point is: I’m all for better code, but Culture trumps certification and standards every single time.

> NASA probably uses some of the most rigorous development and testing methods in the world, but I‘d still rather trust my life to the flight control software of SpaceX who doesn‘t give a damn about education.

Why? Have there been any NASA manned accidents that were caused by software? There's certainly been big historical bloopers in the past involving unmanned probes, like getting metric and imperial mixed up, but doubtless NASA software quality is better now. And what is your basis that SpaceX doesn't care about education, while NASA does? Are you a hiring manager at either?

> The banks losing data mentioned by OP are way more rigid in their hiring and certification standards than a Stripe for example. Who would you rather trust on security?

Is that true that banks are more rigid in those standards? Or Stripe is more lax?

There are only three deadly incidents to choose from, thankfully, and it happens they were caused by other kinds of (presumably licensed) engineers. Software incidents include a flight computer failure during the landing of Apollo 11. Another incident caused reset of their navigation computer, requiring them to recalibrate it using a tangible sextant. If we go a little beyond literal NASA, it’s not hard to find computer failures. Aside from the infamous 737 Max, we have the loss of a B-2 on takeoff, which costs the same as a space shuttle. (Thankfully the pilots ejected.) Then the famous story of the Patriot missiles’ first deployment. If I actually Google this, will I find no more?

If we're just talking about aerospace at this point, hasn't the F-35 flight software been notoriously buggy

> Software incidents include a flight computer failure during the landing of Apollo 11.

How did flight computer fail during Apollo 11 landing? If you mean guidance computer and famous 1201 and 1202 errors, those were not failures, but were caused by hardware bug they left unsolved on purpose.

That's your choice, but in a space mission or in a self-driving car I'd rather not be a casualty of move fast and break things.

> better best practices

Really? No, seriously, where will this end? Now we need better BEST practices?

I mean. This "best practices" wagon is just a nonsense. My impression is some people don't want the burden of thinking, so they want something to memorize. And blame when things go wrong - which they inevitably will, as in any and all "crafts" and "professions".

Engineering, medicine, etc, are all full of examples of failures. Is this evidence they should get rid of certifications and all bureaucracy? No.

Is software failures an evidence we should have more bureaucracy? No, it's evidence we need to think more and memorize less.

Then perhaps the best practices shouldn't be rules for rote memorization, but better approaches towards thinking and reasoning about code. Maybe this field could use more discipline in how it approaches not just creating code but reading code. What is the use of thinking if it's not guided by methodology? Didn't many of us study computer science?

Programming science does not exist.

And yet, programming claims to be guided by computer science.

Universities claim programming is guided by computer science, because they love sticking the label "science" on non-scientific things.

The average working programmer probably doesn't care whether their work is considered a science or not. Certainly I feel like the ROI on reading CS papers in my own career has been quite low. They have a habit of sounding useful and impactful until you finish reading them and realize there's a pretty major catch. I have a degree named "computer science" but it's questionable whether it was really scientific, given that science is usually defined as a study of the natural world. There's nothing natural about computer programming, outside of perhaps complexity theory. You could argue that maybe at the edges deep learning is blurring into a study of naturalistic phenomena, but you have to be careful, otherwise you reclassify pure maths as a science and I think everyone agrees that it's a separate thing.

Computer science is only vaguely related to programming, in roughly the same way that the travelling salesman problem is related to actually travelling salesmen.

(I personally hold that there are only three CS courses relevant to daily programmer life: graph theory, complexity analysis and state machines. Everything else is at best situational.)

But in practice, "best practices" are always set by some sort of stagnant bureaucracy, often some sort of quasi-union organization that demands fees and spends all its time trying to keep newcomers out of the profession in order to protect the salaries of those already inside it. Worse still, it can lead to dysfunctional behavior industry-wide that has no competitive path to fixing it.

Look at what's happened to medicine. Huge numbers of people have had their confidence in doctors seriously damaged over the past 2 years because they keep saying things that are patently nonsense, like "oh your period vanished for 5 months immediately after taking a vaccine, it must be a coincidence" (this happened to a friend of ours). Why do they say these things, well, because if they go against the party line on vaccine injuries they can lose their license:

https://trialsitenews.com/doctors-sanctioned-for-speaking-ou...

That sort of action has nothing to do with best practices and everything to do with power structures. The software equivalent would be something like, "if you imply Java is not the best language to build enterprise software in, you could lose your license" or "if you write forum software that doesn't run every post through this officially approved AI for misinformation, you can lose your license". It doesn't look like bugs magically disappearing. I'd expect the rate of bugs to go up, actually, as standards ossified and became irrelevant (see: FIPS).

What stagnant bureaucracy instituted Agile across the industry, or mandated the widespread adoption of Node, or React, or any hot trending technology of the decade? Ad hoc best practices or chosen tools get picked up all the time without a power structure demanding it.

Maybe the compromise isn’t to institute formal licensing, but rather pay more attention to and give more support to industry bodies such as the ACM/IEEE.

Best practices come as an accepted way of doing things. It means not reinventing the wheel for every project.

Of course best practices can only work for problems that have already been solved. There are plenty of problems that need innovative thinking and unorthodox practices. The more brain power you can dedicate to solving those problems, the better.

Reply on news.ycombinator.com