Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

151–160 of 369 posts

Re: Are software engineering “best practices” just developer preferences?

#151
A big issue in this industry is that folks do things like if no one else had done them before, reinventing the wheel continually. It feels like it evolves fast, but really, it's going in slow motion, because we're constantly starting over.

It doesn't matter if someone, or a group of people, spent years researching a topic: even given an extremely similar situation with similar resources and constraints, an engineer right out of school will still feel compelled to try and solve the problem anew.

Part of the issue is that we're very bad at identifying constraints and context, and thus it's really hard to apply pre-existing solutions. Eg: people trying to apply concepts developed by large FAANG-style companies in a startup.

Part of it though, is sheer arrogance. Everyone feel like they know better. There's also a bit of "playing programmer" going on: folks do a lot of things because they find them more fun, even if it was somehow objectively a worse solution (and they knew it). Because software engineers are in such high demand, people above are afraid to drop the hammer. Concept such as team or individual autonomy are put above the global maximum of the business. This autonomy and freedom is justified by saying it drives innovation, but you're not innovating if you're constantly starting over. For example, while modern languages do have some cool new features, we also keep reinventing the tooling, editors and debuggers around them, which drives progress in those areas to a crawl.

All around, there's a balance between solidifying some concepts, vs continuing to innovate. Right now we're leaning a bit too hard toward chaos, and the industry would benefit a little from letting things mature.

Re: Are software engineering “best practices” just developer preferences?

#152

> Java is infamous for its verbosity. [...] This paragraph highlights something I've been saying for ages. Most criticism of Java needs to be directed towards Java programmers and not the language itself. The language allows you to simply make a class. You're not required to make an interface and then make a class that implements it, and yet, Java programmers do it anyways and then criticize the language for being ve…

Yeah, I'm actually a pretty big fan of Java programming. It gets a lot of hate on HN for things that have been mostly solved or can be solved if you implement it a certain way.

Re: Are software engineering “best practices” just developer preferences?

#153
post #151

A big issue in this industry is that folks do things like if no one else had done them before, reinventing the wheel continually. It feels like it evolves fast, but really, it's going in slow motion, because we're constantly starting over. It doesn't matter if someone, or a group of people, spent years researching a topic: even given an extremely similar situation with similar resources and constraints, an engineer r…

[deleted]

Re: Are software engineering “best practices” just developer preferences?

#154
post #4

Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and solved problems abound---and even then we still get it wrong sometimes. Whereas, software engineering is maybe 70 years old (generously)? So, there is much to learn and a lot of "baseline" knowledge that has yet to be established. I think it's a good way to th…

Also, there isn't that much in the way of scientific grounding. Mechanical engineering has physics as a foundation. Chemical engineering has chemistry as a foundation. What is the scientific foundation of software engineering? I suspect it is a mix of cognitive science, linguistics, and anthropology.

> cognitive science, linguistics, and anthropology.

Would love to hear your thoughts on this, esp. the linguistics and anthropology piece.

Re: Are software engineering “best practices” just developer preferences?

#155

Earlier quoted context omitted.

Doesn't that kind of imply that everyone's opinions are equally valid? If 95% of your profession is on the same page with a certain practice then I'd argue it's really not reasonable to go against the grain without a very good reason. I think "best practices" strikes a good balance between things that are personal preferences and things that are laws.

Yeah it does. Software is basically a mental model and different people have different mental models of the world so we make up languages/practices/etc. that fit those models. The point of the examples I gave (and a lot of browsing HackerNews) seems to suggest that 95% of the profession is not on board with our most basic practices around unit testing, version control, etc.

Maybe we just disagree about what constitutes best practices. I can't speak much about Java land, but I wouldn't describe rebasing in general as a best practice without further context. If you're working on a team that always rebases feature branches then your preference for not rebasing doesn't seem valid to me.

Re: Are software engineering “best practices” just developer preferences?

#156
post #112

Earlier quoted context omitted.

Some of us call ourselves "engineers". It just depends whether you want to pay the order for the privilege of having the title (and pretty much no other tangible benefit in 90+% of cases) :).

Genuine question. What is so important about the word "engineer" that people not licensed to practice it want to call themselves engineer? In Canada, I studied in a mechanical engineering technology program that lead to an engineering degree if you stayed on for 4 years. It was hammered into us that we weren't engineers until after you graduated and went through the professional licensing process. In Canada there is…

Calling yourself an "engineer" involves licensing fees, continuing education, and the most fun of all - a university degree.

Some jobs require you to be a member, but most of these jobs aren't in software.

So most software people I know just use adjacent titles like "developer" or "designer". It's essentially the same job - just without all the extra responsibility.

The word "engineer" has a certain social clout to it, though. Hard for your mom to brag to her friends if your title is "developer".

Re: Are software engineering “best practices” just developer preferences?

#157
post #108

As I read this I'm building a distribution of a web framework that eliminates block templates and will only have one page template (for the head HTML). I'm gonna have CSS generation and upload built in the CMS as well (tailwind or tachyons only). I'm sure there will be howls of "you can't let them put code in the database!" Why not? It's their (the customer's) database and their web service, after all. You can do all…

Question- if you're using eval() and bleach, won't your security be totally dependent on bleach not having a vulnerability?

Sure.

Kinda like how storing web templates in files is totally dependent on the people who upload them not putting crypto miners in the linked javascript(s) [1]. Or totally dependent on PAM not having a vulnerability [2]. Or totally dependent on SSH not having a vulnerability [3].

In terms of libraries and utilities I can give PAM and SSH a pass for fixing these things long ago. In the case of restricting a customer's access to the mechanism that renders their thing in favor of the option of "trust this guy who uploads things instead" you've got a much tougher sell about why that's better.

1. https://www.fortinet.com/blog/threat-research/the-growing-tr...

2. https://www.cvedetails.com/cve/CVE-2002-1227/

3. https://www.cvedetails.com/cve/CVE-2002-0083/

Re: Are software engineering “best practices” just developer preferences?

#158
post #28
post #4

Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and solved problems abound---and even then we still get it wrong sometimes. Whereas, software engineering is maybe 70 years old (generously)? So, there is much to learn and a lot of "baseline" knowledge that has yet to be established. I think it's a good way to th…

Eh, I mean we've been building computer chips for approximately the same amount of time as computer software, and it's pretty clear chip engineering is more like civil engineering than software engineering. I would guess many of the best practices in bridge building in the modern day were developed in the last 70 years. I think it's that engineers of physical things have many more hard constraints they have to wrestl…

> Eh, I mean we've been building computer chips for approximately the same amount of time as computer software, and it's pretty clear chip engineering is more like civil engineering than software engineering.

Is it actually anything like civil engineering? To my knowledge chip engineering revolves around yield. There's no such analogous concept in designing buildings that can only be reasonably constructed correctly 70% of the time and attempting to reuse the bad buildings for other projects.

Re: Are software engineering “best practices” just developer preferences?

#159
post #97
post #68

Earlier quoted context omitted.

What about we apply this to software engineering? > If a builder constructs a house for a man but does not make it conform to specifications so that a wall then buckles, that builder shall make that wall sound using his own silver. - Code of Hammurabi, 1755–1750 BC

Define "specifications" and "conform" in terms that I might hear from a non technical client.

That is what contracts are for.

Re: Are software engineering “best practices” just developer preferences?

#160
post #61

Earlier quoted context omitted.

That's simply not true. Software is grounded in mathematics. Most people just try to ignore that fact for convenience. There are, for instance, famous books written about which errors can be proven to be absent in your program and how (vulgo typechecking). There is a huge amount of research about data structures and their internal logic (and at least one, very weird observation about the meaning of the derivatives of…

As an oficially qualified computer scientist, I can say that software is grounded in mathematics, but this does not imply what you're thinking. *All* formalisms, including mathematics, are in the end nothing but an incredibly precise language to talk about ideas in your head. Programming languages are created for communication, so this is specially true for them. The fact that code has an extremely precise semantics…

> Formal proof is a convenient way to check that your detailed, precise assertions are consistent with your initial axioms. This doesn't prove at all hat there are no errors in your code, only that there are no contradictions in what you are saying. Your specification could still be wrong, and then you could still be saying the wrong thing in terms of what you intend to say or achieve; and the formalism won't help.

Software assurance is still a somewhat nebulous process and I'm partly involved in some research around it and proving that a program is logically sound is indeed only a small piece of the pie and hardly gets you anywhere valuable.

FizzBuzz is provably logical, but that doesn't mean you can load FizzBuzz onto a space shuttle and expect it to fly correctly.

Post reply on HN