101–110 of 369 posts
99.9% of the time they do, maybe you don't see them functionally and visually, but probably you aren't measuring security flaws, performance and specially ease of maintenance which goes unnoticed most of the time...
Some certainly are, many are not. To discern the two is very easy. You write a piece of code. If someone else or even yourself can still understand it after a month, then you're practicing the "best practices". Whereas, if you don't follow some "best practices" and they're still clear to others, they are just "developer preferences".
> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? We call ourselves software developers in Canada. According to Canadian engineering[1]: The "practice of engineering" means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising, or managing any of the foregoing, that…
It'll be interesting to see if they can ever manage to enforce it. I haven't heard of any cases yet since Microsoft challenged them and won.
> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? We call ourselves software developers in Canada. According to Canadian engineering[1]: The "practice of engineering" means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising, or managing any of the foregoing, that…
Any of them can be Software Engineers or not, because we call Software Engineers to the ones with the university career finished
In contradiction with the first paragraph, there are definitely fields of software engineering with external regulation, auditors, etc. I'm thinking of the banking sector and realtime critical software, like in avionics and such.
> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? We call ourselves software developers in Canada. According to Canadian engineering[1]: The "practice of engineering" means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising, or managing any of the foregoing, that…
Error: cycle detected. ^__^
Software is by its very nature systematic and quantifiable. Is the quibble with whether programmers are disciplined?
All software companies would meet the "failure or inappropriate functioning of the system would result in harm to … economic interests" criterion.
That friend simply didn't realize that "engineer" has different semantics with different historical evolution of word usage:
(1) "professional engineer" -- as in state license board and certification e.g. civil engineer
(2) "engineer" as a descriptive modifier -- e.g. "software engineer" and also some non-programming examples such as "audio engineer", "video engineer", "supply chain engineer": https://www.google.com/search?q=%22supply+chain+engineer%22
We could ask a similar question the friend asked: How can there be a "supply chain engineer" when there are no governing bodies for "supply chain certification" ?!?
It's because some people like to concatenate "engineer" at the end of a job role and others adopt the label and the usage gains wide currency. On the other hand, "dessert pastry engineer" hasn't really caught on so creating a fancier title doesn't always get accepted.
Back in the old days (1960s & 70s), the job titles of programmers on org charts -- especially at non-software companies like banks using COBOL, etc -- was "PROGRAMMER I", "PROGRAMMER II", etc. The "software engineer" seemed to be mostly popularized by software-focused companies like Microsoft, Silicon Valley. But now, even old companies like banks where coding is a cost-center instead of profit-center also have "engineer" in programming job titles.
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 sorts of validation on a form input and a database field (like with Tidy and Bleach in my case with Python). Can't do any on a plain text template file.
But "separation of concerns!"
For who? It's always been bad practice in my opinion to assume that not only do end users have on-staff development, or contract development, but that they have multiple tiers of it which need lines drawn between the duties of each. Who says everyone who needs custom software or custom web services is an IBM-sized conglomerate with multiple departments full of software developers? Why can't a mom and pop restaurant have a nice website and a nice phone app? Because they don't want to learn to use javascript, webpack, npm, git, and an IDE? Is that the only reason why?
The least accessible (in a physical sense) parts of web development are the parts that a customer might do themselves (CSS and HTML). I will not believe there is a good reason for that other than software developers trying to talk themselves into more jobs and more contracts.
The only objective thing for best practice is simplification. Problem with loose coupling, OOP etc... is that a lot of it sounds like "done" right but becomes complicated over time - even though it might be a good idea. So only "KPI" for best practice should be simplicity over time.
I've been working on something since approximately 2014 that I think finally has a reasonable chance of being correct (or at least useful ... for me). Now all I need to do is run a bunch of studies to see if this is actually a universal property or if it's just a bunch of bullshit that only makes sense to me.
But the point is that I don't want to use some weird self invented pseudo mathematical framework. I want there to be some obscure branch of mathematics that people already invented back in the 1800's that actually lets us define when some thing is complex and when it's simple. But as far as I can tell, it's just preference or poetics.
[
Okay, so there are a few things that sort of sound like they fit the bill, but when I looked into them I decided that they probably don't.
Cyclomatic complexity: This only works for if-statements (ie not for weird tangled OO object graphs or incomprehensible FP category theory operator soup) and some studies show that line count is a better indicator for defect rate.
Rich Hickey's Simple Made Easy talks are a gift to the software engineering community. But they're ultimately a poetic expression. You don't get to define one term and then pretend that you've solved how to write software. I view these talks as a very eloquent way of capturing the desire to create high quality craftsman like software. However, I don't believe that they're useful in a code review unless you need to appeal to pathos for some reason.
Kolmogorov complexity: This was really exciting to discover. However, I'm not really sure there's much here for programming. I guess you could use it to mathematically describe a boiler plate to apl spectrum. But I'm not sure you can use it to declare that any given point in the spectrum is better than any other point. Also, it doesn't really say anything about when mutable state is good or bad, etc. At best it's one metric out of many.
Information theory: Basically the same story with Kolmogorov complexity. You might be able to use this to decide that your variable naming is off, but there's so much more to good or bad software that this really can only be a single aspect at best.
]
But really, "best" and "right" are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn't apply. I was part of a discussion on a mailing list years ago, where somebody got flamed harshly when he mentioned using a global variable. He then explained that he was working on an embedded control system for cars and all the variables in that system were global. The team was well aware of the pitfalls of global state and used a combination of documentation, static analysis, custom tooling and elaborate testing to mitigate them. It was a considered design choice that made it possible to develop high-performance, hard-realtime software that could run on very limited hardware.