Hacker News Reader

Comment by userbinator | Hacker News Reader

The client can specify the length of the computer name. By specifying a name longer than 64 characters

What sort of programmer writes code to handle a protocol with a length field and yet uses a fixed-size buffer without ever considering the possibility of what would happen if it could be larger than the buffer...?

I've seen plenty of source code out there, written for educational/example purposes, where arrays to hold strings are declared with an arbitrary size and no justification why - and naturally, no consideration of this fact is made evident. It's a horrible habit to get into writing code like that, since it makes others, less knowledgeable, think it's acceptable...

View on HN

> What sort of programmer writes code to

The sort of programmer who's not passionate about how the code looks, or works, as long as it passes the (very rudimentary) tests which don't cover protocol violations or borderline cases.

The sort of programmer that didn't have any experience and directly went from Sandbox-Java to bare-metal kernel-code in his first project?

I don't want to disillusion you, but I know plenty of people with (at least part-time) programming jobs who don't care at all about all the new programming paradigms, programming languages, libraries, frameworks... boasted often here on HN. I'd say that a huge majority is pretty pleased with what they know, as long as it's enough to do the job.

And, frankly, economically it makes sense: How many plastic-routers are chosen based on their track-record regarding security? And how many "Security-Incident-Handling Stars" does any of the devices mentioned in the article have on Amazon.com? No one cares. The company and their programmers can just continue writing "almost working" code, and patch the security-incident-of-the-month when it surfaces.

> I'd say that a huge majority is pretty pleased with what they know, as long as it's enough to do the job.

> And, frankly, economically it makes sense

because they are treated as disposables by their companies, as far as I understand from all the comments from sysadmins and programmers here and at other forums.

Actually I'd consider myself in that group; most of my work is in Asm and C, with some C++, sometimes Java, and very occasionally do I do anything with Web technologies.

The difference, however, is that I do consider all possible inputs, think about how much space things take up, and generally try to cover the problem space. If there is a variable-length field, there will be a statement in the documentation/requirements which states any length restrictions, and what happens if that length is exceeded.

The sort of programmer that didn't have any experience and directly went from Sandbox-Java to bare-metal kernel-code in his first project?

I think this has much to do with it - those starting with HLLs that cover them with a safety net, letting them do stupid things without all that much consequence, may not develop the same type of thinking; but, even if this was written in something like Java, a Nullpo or IOOBE is unacceptable, and perhaps they would just patch in code to catch the exception and ignore it, not giving this case the proper thought it deserves.

To put it a bit more bluntly: when you're writing in Asm on a machine running DOS, and any bug is probably going to make you reboot, you quickly tire of hitting the reset button and learn to think more carefully about what you write. Although I've migrated from such an environment a long time ago, the habit has stuck.

> To put it a bit more bluntly: when you're writing in Asm on a > machine running DOS, and any bug is probably going to make you > reboot, you quickly tire of hitting the reset button and learn > to think more carefully about what you write. Although I've > migrated from such an environment a long time ago, the habit > has stuck.

I completely agree, a good argument for teaching programming "from the bottom up".

> What sort of programmer

I know we like to think all programmers are the best and brightest and most talented citizens of the entire world, but the truth is: most programmers have the dedication of fast food workers and as long as "it works for me," they'll ship it.

The projects people here are used to (modular, decomposed, open source, documented) are rare. The world is full of multi-million line code bases with little usable documentation (either no documentation, outdated documentation, or 8,000 pages of documentation) and comments not describing actual behavior. Plus, everything gets compiled using 300 recursive Makefiles written across 15 years in 8 different countries by people who only keep their job for 8 months at a time.

At least they stick with one tech longer than five minutes. The ADD-riddled folk that sometimes post on here, changing their tech stack based on the newness in milliseconds of the latest craptastic JS framework is astounding.

The kids have no cost of switching to something new because they probably don't know much already. As you get older, re-learning everything 6 months feels weird since any random 14 year old can know as much (or more) than you do about the new system. Your API-level experience gets invalidated rapidly, so it's almost better to start from scratch, which only the unknowing youths can do.

Then there's a whole "stake you claim" mentality. Want to be the best C person in the world? You can't. It's too wide spread. What to be the best Go person? Sure, fight that battle for your own glory since it's new and you can take part in everything.

Lack of education/experience also creates a great breeding ground for new, duplicate, half-implemented versions of things that already exist. The older a developer gets, the more they see things they already know re-implemented as completely new but with unfamiliar interfaces they'll have to re-learn again every 6 months. It's a huge waste of human capacity to always be "new new new" instead of creating a stable and reasonably extensible base to work from. But, at the same time, we don't want to be stuck on Perl 4 and CORBA forever.

There's a tradeoff between building new things for advancing the future versus building new things just because you think you're better than all the previous research/experience that has come before you. See the case of Cathedral v. Bazaar.

"Works for me" isn't the only reason to ship imperfect code. Time-to-market really matters in some applications. "Move fast and break things" is a motto for a reason.

The router companies shipping NetUSB routers are meeting a market need; people want to plug printers into routers and print from anywhere on their network. For many users and applications, low-quality code will work.

It's in the long term that high-quality work differentiates itself.

> For many users and applications, low-quality code will work.

Oh, don't pretend "quality" is just a proxy for "has pretty animations and makes the user feel warm and fuzzy."

The failure to ensure "quality" of this embedded router component has put millions of never-going-to-be-updated hardware devices in the wild at risk of 3rd party takeover, personal information leakage, installing proxies on them to send user details to hostile actors (monetary losses, blackmail), ....

Programming errors shouldn't be excused just because we always say "whoops! we'll do better next time!" But, since humans are objectively bad at something as complex as programming, we can't hold people accountable (who wrote it? an intern from 8 years ago? punishing them does no good). We can't hold organizations accountable (recall all the consumer routers!) because public policy doesn't think that way.

We're in a weird period of history where companies can get away with great computational damage with no repercussions at all. The market currently _does_ favor "just do whatever and try to fix it later (or not, whatever)," but that doesn't make it right.

we can't hold people accountable (who wrote it? an intern from 8 years ago? punishing them does no good). We can't hold organizations accountable (recall all the consumer routers!) because public policy doesn't think that way.

Contrast that with the completely different approach taken by the aerospace industry, where people and organisations are held accountable; and it has resulted in great reliability overall --- interesting discussion about that here:

https://news.ycombinator.com/item?id=9569077

We're in a weird period of history where companies can get away with great computational damage with no repercussions at all

In critical software for a plane it is literally a matter of life or death, and people are willing to pay much more for that level of quality; but if a consumer router gets exploited, what's the worse that could happen?

I think it is important to put the risk into perspective: this is bad, but it's not really a people could get killed sort of thing.

Reply on news.ycombinator.com