[HN Gopher] Are software engineering "best practices" just devel...
___________________________________________________________________
Are software engineering "best practices" just developer
preferences?
Author : floverfelt
Score : 155 points
Date : 2021-09-30 13:59 UTC (9 hours ago)
(HTM) web link (floverfelt.org)
(TXT) w3m dump (floverfelt.org)
| jleyank wrote:
| Skimming all of these comments I think that creating software
| remains more of a craft than an engineering discipline. Not that
| that's a bad thing, in that it permits creativity. And for most
| cases, engineering-level rigor isn't worth the effort. As Tom
| West said in Soul "Not everything worth doing is worth doing
| well."
|
| Sadly, this approach seems to have been used in the interface
| software of my RAV4.
| gedy wrote:
| > the senior engineer had defined every single service class as
| an interface and then implemented that interface in an actual
| @Service. The logic from the senior engineer was that the
| interface represented the "contract" and the class the business
| logic.
|
| This is mentioned as bad thing, but having service interfaces
| really helped in a large Java project I worked, where we had to
| reimplement and extract some important code. Using the interface
| for the new code made it much simpler to use a radically
| different implementation, and also made devs think about what the
| real interface should be, vs just coupling to some
| implementation.
| KronisLV wrote:
| There is a large difference between dogmatically declaring that
| every single service needs an interface, versus just
| introducing them at the point where you actually need more than
| one implementation.
|
| I think that's the author's original argument - not that
| interfaces are bad in of themselves, but that cargo culting is
| problematic.
|
| Furthermore, starting with an interface oftentimes makes you
| create the wrong abstraction, however when you have a concrete
| implementation, in my experience extracting an interface
| becomes easier to do, though mostly thanks to excellent IDE
| tooling.
| floverfelt wrote:
| Exactly, it would've made total sense to pull it out into an
| interface in other situations, but simply felt like a
| preference here.
| cwp wrote:
| Eh, kinda. Calling something a "best practice" is basically an
| appeal to authority. It means, "this is the right way to do
| things, for reasons I don't have time to explain." There are
| times when that's appropriate.
|
| 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.
| theptip wrote:
| One thought to add here - when you appeal to an authority,
| which one is it?
|
| In the OP example, it seems the senior dev is saying "on my
| authority". And sometimes that is enough, especially if the
| senior dev can give examples of when not following this
| practice bit them.
|
| But sometimes there is a higher authority, such as "it's what
| is recommended in Google's SRE book", which is probably good
| advice if you are building a large SRE team. (Though as you
| say, not in all situations.)
|
| I think in the worst case, "best practice" can indeed be used
| to shut down discussions of a leader's preferences. But you can
| smell that out by asking for concrete examples, and asking how
| widely the practice is recommended.
|
| A good "best practice" should be justifiable and explainable.
|
| All that said, sometimes as the senior engineer you need to go
| with gut feel; "this design smells like it will give us trouble
| within a year" is the sort of thing I sometimes say. But I
| think it's important to be honest that it's a hunch, not a
| certainty in these cases, and discuss/weight accordingly.
| floverfelt wrote:
| Yep exactly! I think if you broaden the concept of
| "authority" beyond literal authoritative sources it gets even
| more murky.
|
| Are you appealing to the authority of speed? Compilation
| time? Readability? Functionality?
|
| I dunno, and it often (especially around readability) comes
| down to the developer's/senior engineers preference.
| Jorengarenar wrote:
| > somebody got flamed harshly when he mentioned using a global
| variable.
|
| Harsh bashing on global variables is such a dumb thing.
|
| Yes, they can be dangerous. Yes, many had problems due to using
| them. Yes, we should tell beginners to avoid globals.
|
| But there is no reason to ban them altogether. Experienced
| programmers should utilize them whenever it makes sense
| (instead of passing down a value of a local one to almost every
| function [sic]).
| nyanpasu64 wrote:
| Global mutable variables are generally a bad idea because
| they have nonlocal side effects which are difficult to
| mitigate, like aliased mutable pointers but worse. Extra
| _non-aliasing_ arguments and multiple return values are free
| of these issues, and a better tradeoff in almost all cases
| (unless you 're sure you'll never run 2 instances of a system
| in the same address space, _and_ you have specialized
| constraints possibly including embedded /safety-critical
| development and emulators).
|
| When experienced programmers utilize global variables
| whenever it makes sense, it tends to bite future generations.
| Windows's GetLastError is a mess (some functions set it on
| error but don't clear it on success), I'm not sure about
| POSIX's errno, and when threads were introduced, these
| variables had to be changed to thread-local state.
| kayodelycaon wrote:
| > When experienced programmers utilize global variables
| whenever it makes sense, it tends to bite future
| generations.
|
| Usually.
|
| There is one pattern I keep using in Rails to inject the
| current_user for the request into the model layer. At the
| beginning of a request, Thread.current[:current_user] gets
| set to the current_user. At the end of the request, it's
| cleared.
|
| For those unfamiliar, each Thread has its own Hash object
| and [] and []= instance methods to access it. It's a way to
| create global variables scoped to the current thread. To
| hide this implementation detail, I wrap this functionality
| in ApplicationRecord.current_user and
| ApplicationRecord.current_user= methods so no one
| accidentally uses :curent_user.
|
| The most common use case for this is to automatically set
| created_by and updated_by on a model, the same way
| created_at and updated_at are set.
|
| Cron jobs can do something like
| ApplicationRecord.current_user = User.cron_user if needed.
| Ideally, I would set this in a CronTask parent class so
| current_user is always available in the model layer.
|
| I always document these methods and explain exactly what is
| happening and why. Abstracting away from the implementation
| detail mitigates most of the problems with a global
| variable. Obviously, the Thread.current method does not
| work at all if you're using an event or actor driven
| architecture. Rails does a thread (or process) per request,
| so this works extremely well.
| lucumo wrote:
| > It's a way to create global variables scoped to the
| current thread.
|
| That's not a global variable; that's a thread-scoped
| variable.
|
| (It's also not (really) mutable. It gets initialized at
| the start of the scope and gets removed at the end of
| scope.)
| jerhewet wrote:
| > Yes, we should tell beginners to avoid globals.
|
| Welcome to Dependency Injection in .Net Core!
|
| "Those who cannot remember the past are condemned to repeat
| it." -- George Santayana
| Chris2048 wrote:
| But here's the thing: aren't most alternatives to global,
| some _other_ kind of global state anyway, but possibly better
| managed?
| throwaway889900 wrote:
| Singletons come to mind as being a better alternative in
| languages that can do that sort of thing.
| gpderetta wrote:
| Singleton is just a fancy name for a global.
| w0mbat wrote:
| People also bash singletons, so you can't really win.
|
| You can get issues with a singleton being accessed for
| the first time from multiple threads at once, for
| example, so you end up with more than one instance being
| created or a situation where one thread triggers the
| creation and another accesses before it has been fully
| initialized, depending on the code.
| lightbendover wrote:
| Almost assuredly better managed. There are no reasons to
| manage state on the global level apart from laziness.
| AussieWog93 wrote:
| Funny you should mention that. I've used ocornut's ImGui
| library in the past, with a single, hierarchical object
| that managed the entire GUI state.
|
| This approach caused whole classes of problems that
| affect regular GUIs to simply disappear, and it was the
| most performant, least buggy UI I've ever written by a
| country mile.
| ioseph wrote:
| Isn't Redux doing this exact thing?
| dragonwriter wrote:
| > Calling something a "best practice" is basically an appeal to
| authority.
|
| If presented on its own, but then, any conclusion presented on
| its own without supporting context and analysis is the same.
|
| > But really, "best" and "right" are highly situational
|
| A description of a best practice that doesn't provide a
| sufficiently precise description of the situation to which it
| applies as a best practice is generally inappropriate, unless
| it is the conclusion of an analysis of applicable best
| practices to a certain situation, in which case the scope is
| specified in framing the analysis.
|
| It is true that lots of things described as best practices for
| particular situations with supporting rationale and up getting
| detached from their logic and context and becoming cargo cult
| best practices.
| w0mbat wrote:
| Even worse are people that talk of "code smells", applying
| their personal opinion of style in a judgemental and often
| unjustifed way.
| swixmix wrote:
| Reminds me of US Generally Accepted Accounting Principles
| (GAAP). I don't need to be perfect, just consistently good
| enough.
| 908B64B197 wrote:
| > He then explained that he was working on an embedded control
| system for cars and all the variables in that system were
| global.
|
| Everyone should write Embedded at least once. It's a completely
| different world.
| asdff wrote:
| Identifying a best practice is actually not as hard as people
| realize imo (although it may take some time), and only becomes
| hard when you let emotion and sources of emotion come into what
| should be a rational decision making process (such as
| preference for a certain tooling for reasons like familiarity
| or popularity in the field today rather than outright
| advantages vs other tooling).
|
| To identify the best practice for anything, you start by doing
| a review of all the available practices in the field for a
| given problem you are working on. Then once you've reviewed the
| literature you can work out the pros, cons, caveats of each of
| these tools, and how these considerations affect your
| particular use case and your expected results. Then after doing
| that, the best practice out of available options will be
| readily apparent, or at the very least strongly justified, not
| by an appeal to authority or popularity or familiarity, but by
| looking at what the underlying technology actually does and how
| its relevant or not to your particular task at hand. In the end
| you will find the very best hammer available out of all the
| hammers people have made in this field for your particular
| unique nail.
| lucumo wrote:
| That sounds like a beautiful example of letting perfect be
| the enemy of good.
|
| Just like your design choices have trade-offs, is it
| important to realize that there's a trade-off between
| finishing sooner and making a better solution. Diminishing
| returns are usually very much in play with analysis.
|
| (I would also challenge the notion that every situation has a
| different "best practice". That's just creating a solution.
| "Best practices" are usually general advise that is
| applicable in most situations.)
| elboru wrote:
| Right, but have you ever worked in a place where no practices at
| all are being followed? Where there are hacks after hacks, giant
| classes with giant methods, no interfaces, static methods, bad
| names everywhere, you need to find a bug? good look, you want to
| write a test to avoid regression? Ok that would take you 5 times
| more time.
|
| I agree, following a "best practice" without understanding the
| "bad practice" that it's trying to prevent is silly. But just
| discarding best practices because no one understands the reasons
| behind is also silly.
| rewma wrote:
| > I agree, following a "best practice" without understanding
| the "bad practice" that it's trying to prevent is silly. But
| just discarding best practices because no one understands the
| reasons behind is also silly.
|
| I would argue that there is also a lot of value in following
| team-level best practices even if you do not fully grasp the
| rationale or understanding "bad practices". For starters, it
| ensures that the team's work complies with the principle of
| least surprise and follows a common and standard style, which
| helps with onboarding and forming a mental model of where and
| how all things are.
| floverfelt wrote:
| Yup, I 100% agree. The point of the post wasn't to bemoan
| practices, more just that it's frustrating to be told
| repeatedly that a certain thing is a "best practice" when
| really it's just what the developer who wrote it preferred.
|
| Software Engineers should just say "this is how we like to do
| things" and not pretend that there's a holy grail of
| correctness when really it's just what they like.
| dkarl wrote:
| > But just discarding best practices because no one understands
| the reasons behind is also silly.
|
| So what do you do with a "best practice" that doesn't make any
| sense to you? Do you just keep doing it forever because you
| can't understand why anybody would invent it in the first
| place? To take an example I'm familiar with, there's a good
| chance if you don't understand a Java OOP best practice it's
| because you've never encountered the problems it was designed
| to cope with. The OOP design principles that came out of the
| 1990s and became orthodox in Java around the turn of the
| century were built to solve the problem of scaling monolithic
| application development to teams of dozens or hundreds of
| developers. You would have dozens of people, imperfectly
| coordinated, hacking on a monolithic codebase for an
| application that was released quarterly (if that!) and ran on
| servers that cost more than the CEO's car. The coding style
| innovations of that era naturally focused on coming up with
| more and more ways to add layers of protective abstraction, and
| on training programmers to add those layers to their code _no
| matter what, even if it doesn 't seem worth it_ because 99% of
| the time, if somebody didn't understand that it was worth it,
| it was because they were inexperienced and hadn't lived through
| a horrific integration debacle that delayed the quarterly
| release by a month.
|
| In my opinion, if your problems don't resemble those turn-of-
| the-century enterprise monolith problems, then you shouldn't
| program in turn-of-the-century OOP style, and you should take
| "best practices" from that era with a huge grain of salt. You
| should only use them if you can see how your codebase will
| benefit from them.
|
| Even Java, the bastion of OOP conservatism, is acknowledging
| that "best practices" are relative by adding record classes.
| Record classes are first-class language support for violating
| the best practices that were drilled into generations of Java
| programmers!
|
| (There are people who _do_ have those turn-of-the-century
| enterprise monolith problems, for example, library developers!
| They ship their changes to hundreds or even thousands of people
| they 've never met, who don't keep up with project updates, and
| who don't budget time to deal with breaking changes. So a lot
| of the ideas turn out to be really valuable! Just not for, say,
| small teams building microservices.)
| jmull wrote:
| I think there is just some semantic confusion here.
|
| I think a "best practice" should be a practice that is good to
| apply across a certain problem domain (regardless of where you
| work or what dev team you are part of).
|
| And there are coding styles/guidelines which can apply only to a
| specific dev group or codebase. They can often be arbitrary, in
| the sense where it would be fine to do it in different ways, but
| one is chosen, for consistency (to promote
| maintainability/readability). They can be _one way_ to achieve a
| best practice.
|
| Day to day, it's probably fine to loosely call all these "best
| practices" since you apply them the same. But it is also
| sometimes useful to make the distinction, e..g, so you understand
| _why_ a certain practice is being used.
|
| The first example is a coding style, and a judgement call. The
| underlying "best practice" is to separate interface from
| implementation. There are various other ways to do that, of
| course, and need not be done like this. (Personally, I find this
| practice a little "enterprise-y", which I consider an insult.)
|
| The example about version control also depends on the process and
| practice of the dev group.
| christkv wrote:
| I consciously use good practices as it leaves the door open to
| discussion and is not a strong appeal to authority.
|
| The other one I'm not a fan is industry standard practice.
| fitzn wrote:
| 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 think about things.
| lou1306 wrote:
| Furthermore, there are far fewer physical constraints in
| software, so the range of possible designs is dramatically
| wider.
|
| (Actually I dare say that sotware itself has no physical
| constraints at all: software _artifacts_ and software
| _executions_ do.)
| JohnWhigham wrote:
| Which is why I don't buy the "software has only been around
| for 70 years so give it time" argument. Software has nothing
| to be grounded in like other engineers do with physics. It's
| most likely always going to be endless cargo culting.
| dtech wrote:
| It's more like mathematics. While it's true that everyone
| can invent their own maths, this is only really done in
| advanced academia for research. Almost everything in
| practical use is standarized. No-one is arguing about
| whether you need integration or what the right notation for
| differential equations is.
|
| This took time to achieve. You wouldn't be able to read
| Newton's papers easily, even though a large amount of high
| school mathematics is based on things he
| invented/discovered.
| choeger wrote:
| 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 data structures). And I don 't need to
| mention complexity theory, do I?
|
| Just because a huge part of the practitioners ignores the
| scientific base of our discipline doesn't mean it doesn't
| exist.
| TuringTest wrote:
| 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
| comes from it being a formal system. But its close
| relation with maths and physics, besides that they are
| all formal systems, is mainly because mathematicians and
| physicists were the first to create it; it's mostly a
| matter of tradition. There are ways to create, use and
| study software that are closer to language studies than
| they are to math, and those are legitimate comp-sci too.
| Non-formal aspects of building software, like which style
| guide to establish in your organization, are part of the
| discipline even if you don't use math to study them.
|
| 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 that 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.
|
| It is not surprising that managers gets to decide how
| software is built in their department. Software is an
| explanation of concepts with a particular style, and
| those who set the tone implant their quirks in it. You're
| building what the manager tells you to build, and end
| using the same language.
| Drew_ wrote:
| > 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.
| TuringTest wrote:
| Great example!
|
| How does research in software assurance treats the human
| side of behaviors and desires, which can't be formalized?
| Are there protocols that can increase reliability for an
| established purpose?
| Drew_ wrote:
| Many times there are authorities that have formalized
| protocols for systems involving people. For example, the
| FAA has prescribed thresholds where pilots should be
| alerted of possible failures when navigation system
| measurements have exceeded those thresholds. Other times
| thresholds like those can be found just through user
| testing and feedback. The goal there is to ensure safety
| without losing the confidence of the user or overwhelming
| them with information.
|
| There are a number of general Software Assurance
| protocols. I'm not super familiar with them, but DO-178C
| is one I hear about often which is a process specifically
| for assuring/certifying airborne systems.
| afarrell wrote:
| 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.
| shagie wrote:
| An old HN post -
| https://news.ycombinator.com/item?id=20912718 and its
| corresponding material -
| https://cse.buffalo.edu/~rapaport/Papers/phics.pdf looks to
| address some of that.
|
| Section 3 gets into the "what is computer science". 3.10
| through 3.13 get into the engineering aspect. Section 6.5
| puts it into historical context.
| xtracto wrote:
| > I suspect it is a mix of cognitive science, linguistics,
| and anthropology.
|
| Computer Science (more abstract) and Computing Science (less
| abstract) are branches of Science that have given a
| foundation to Software Engineering.
|
| The problem is that most of the programming and software
| development that happens nowadays (and what people pay for)
| doesn't use it.
|
| I compare it as Chemistry and Alchemy. We are still in the
| "alchemy" stage of software development. Sure, people who see
| themselves as "experts" are combining existing stuff to
| create new things. But there is a few set of experts that use
| the science expertise to implement systems.
| tdeck wrote:
| I'm a computer science and computer engineering major, and
| I've never once heard the term "computing science". Is
| there a context in which this term is regularly used?
| NikolaeVarius wrote:
| Math. Which seems that many practitioners are proud of not
| knowing
| katbyte wrote:
| Logic maybe but a very large amount of software written
| does not use much if any math beyond the very basics.
| mywittyname wrote:
| Lots of people in other engineering disciplines don't use
| math beyond the very basics either. A large amount of
| parts are designed in CAE software which handles most/all
| of the mathematics. And in some larger companies, the
| person designing the part and the person testing the part
| are on different teams.
| Epa095 wrote:
| Math provides no answer for a lot of the problems one
| encounter in day to day software development. It does not
| help you decide how much test coverage you need,it does not
| help you decide how to review, it does not help you figure
| out what features are desired, it does not help you
| collaborate with the juniors etc etc.
|
| I agree that math describes limitation to computer science
| and formalisation. But software engineering is more than
| computation.
| choeger wrote:
| How about math? Complexity theory, all kinds of logic,
| computational theory, category theory?
| Verdex wrote:
| Honest question. How does that help?
|
| Category theory: I suspect that category theory (well,
| really just abstract algebra) will tend to make software
| engineers better at writing code. However, on the other
| hand, the category theory operator soup that sometimes
| shows up in haskell, et al makes me think that too much and
| not enough restraint isn't a good thing.
|
| Computational theory: After 14 years of software
| engineering, I only needed to care about this once. It
| looks like the answer is try not to make loops inside of
| loops, use the standard library, know the bare minimum, and
| if all else fails then find a way to cheat with hardware
| (graphics cards, simd, massive distributed systems, asci,
| etc).
|
| Logic: So ... like type checking? Or prolog? I mean,
| knowing logic is good. But, like, where exactly do you
| expect the benefits to show up.
|
| Complexity theory: Are you talking computational
| complexity? If so then I guess my answer for computational
| theory (also what did you mean by computational theory
| then? like lambda calculus and turing machines? When does
| that help?).
| optymizer wrote:
| Computer Science?
|
| Edit: this is a discussion forum. The downvote button is not
| an agree/disagree button, it's to penalize irrelevant
| comments. If you'd like to disagree, please reply and state
| your thinking instead.
| edejong wrote:
| Well, if you make broad generalizations like that, then
| software engineering has mathematics as a foundation.
|
| Perhaps you don't want to make broad generalizations?
| floverfelt wrote:
| > cognitive science, linguistics, and anthropology.
|
| Would love to hear your thoughts on this, esp. the
| linguistics and anthropology piece.
| dr-detroit wrote:
| Undergrad CS profs are teaching everyone that theres "Nothing
| new under the sun."
| habitue wrote:
| 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 wrestle with, and software
| engineers largely don't. Your code doesn't need to obey the
| rules of gravity and chemistry and materials science, it just
| needs to _somehow_ accomplish the task.
|
| And you see those best practices in the places of software
| engineering where there are hard constraints: cryptography.
| high performance code. realtime systems.
|
| It's not just a senior engineer's opinion whether you should
| use ruby or C if you're writing the firmware for your race car.
| If you use md5 to hash user passwords on a major site, you'll
| be hung from the rafters.
| Drew_ wrote:
| > 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.
| habitue wrote:
| Sure, and civil engineering is really different from
| chemical engineering. But those are minor compared with the
| differences between physical engineering disciplines and
| software engineering.
|
| Software engineers:
|
| - cost of components is $0 (use one class or split into 2,
| there is no cost metric to decide)
|
| - physics don't apply to components (we can't use this
| doping agent because X or Y. We need to move the factory to
| an area of low seismic activity to improve yields etc..
| etc..)
|
| Basically, physical engineers have so many constraints,
| solving the problem is the hard part. Software engineers
| have so few constraints, usually solving the problem is the
| easy part, and we have time left over to argue about
| abstract cleanliness concepts like composition vs.
| inheritance and such.
|
| (Again, this is the rule, the exception is problems like
| "We need this service to do 2 million requests per second",
| and there we don't argue about functional vs. OOP, you do
| anything you can to hit the number)
| Drew_ wrote:
| Well I think this is just a case of easy Software
| Engineering vs hard Software Engineering where the
| requirements are hard to satisfy.
|
| Most of the industry does easy Engineering and that's
| what we talk about for the most part. The part of the
| industry that does hard engineering (the largest orgs,
| developers of mission critical systems like weapons) keep
| mostly quiet about how they solve their problems because
| that's a trade secret or highly classified.
| 8note wrote:
| Buildings are constructed correctly closer to 10% of the
| time, I assume. The ones built incorrectly still get used,
| just with lower lifespans and are more likely to run into
| issues.
| sidlls wrote:
| Civil (and other engineering) got better because there was
| motivation to improve that came from multiple directions:
| literal lives at stake, the pride of good craftsmanship,
| iterative or even grand steps forward in knowledge, etc.
|
| Software engineering as a discipline is dominated by appeals to
| authority ("Clean Code", "Google does it this way", "Djikstra
| said so", etc.) without any (or at least not much) attempt to
| ask why or whether. I think we'll automate away much of
| software engineering (likely with very poor, inefficient, and
| buggy implementations) before it matures enough as an industry
| to be actual engineering. Engineering (and the science behind
| it for that matter) advances from curiosity and a healthy
| skepticism, not the rampant ego-driven self-promotion that runs
| through SE.
| pjmlp wrote:
| 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
| zdkl wrote:
| Define "specifications" and "conform" in terms that I might
| hear from a non technical client.
| pjmlp wrote:
| That is what contracts are for.
| wheelinsupial wrote:
| The engineer is responsible for taking non-technical
| language from the client and turning it into technical
| engineering specifications. Why does this fall to the
| client in software?
| dtech wrote:
| This is a symptom of the lack of knowledge not a cause.
| Imagine you want to built a building but no one _really_
| knows how, then copying successfully completed buildings, and
| established construction engineers and companies is a pretty
| good idea. That 's what's going on in SE.
| habitue wrote:
| The difference is the feedback is pretty incontrovertible
| if you build a building and it falls down. If you use
| composition instead of inheritance, the evidence of whether
| you're right or wrong comes in the form of ... slightly
| faster refactoring two years later? Maybe?
|
| All of the stuff engineers argue about and that seem really
| subjective are the things where you just get very little
| feedback about who is right or wrong.
| julianlam wrote:
| I feel like I already spend 90% of my day gluing together
| various disparate APIs. Is this the logical conclusion to
| software development?
|
| I adore the craft-like parts of software dev, wouldn't trade
| it for anything.
| surement wrote:
| I can't imagine someone arguing that avoiding tight coupling is a
| personal preference.
| KronisLV wrote:
| I can.
|
| I currently work on a project that has about 1M SLoC in Java.
| Approximately 95% of the classes that have the @Service
| annotation are tightly coupled at the time of writing this.
| Yet, there are no issues with this approach.
|
| Why? Because loose coupling is a nuisance if introduced at the
| expense of more code, which is how interfaces are currently
| done in Java, as opposed to them being implicit, based on
| implemented methods within a class, like Go does it.
|
| In about 5% of the cases, we need more than one implementation
| and introduce an interface. In all the others, we don't. Now,
| what would happen if every single service would have an
| interface in front of it? The codebase would become far larger
| and it'd become more cumbersome to alter it.
|
| Furthermore, IDE refactoring tools make it a non-issue - just
| choose which methods you want in your interface and create one,
| doing so at the point where you are clear about which methods
| are implementation specific and which aren't. Most smart tools
| will even offer you to replace your concrete classes with
| interfaces where possible.
| oweiler wrote:
| Having an interface for a single implementation is just
| redundant. A class already has an interface - it's public API.
|
| Other than that I agree, most "best practices" are subjective and
| boil down to personal preference.
| floverfelt wrote:
| I feel like the responses to this comment are somewhat proving
| the point around most things being preference. ;)
| BadOakOx wrote:
| Having an interface let's you introduce versions or alternative
| implementations easily, this is important in a long run. It's
| much easier to handle the transitions, because you can have
| both versions in your code base and you can easily switch back
| to the old one if necessary. When you start with a class and
| you want to do similar thing, you either YOLO it and change
| everything at once, or you need to introduce an interface and
| replace every usage to use the interface to achieve a safer
| transition and you are back at the interface-class
| implementation with an extra pain.
| Jtsummers wrote:
| Interfaces serve two roles:
|
| 1. They are (usually) concise specification/contract for the
| implementation to follow, and for the client to use.
|
| 2. They permit substitution.
|
| These are, from my experience, the principle and most useful
| reasons to make use of "redundant" interface definitions.
| What's worse is when people want alternative implementations
| but only have a concrete instance, they subclass it and break
| all kinds of contracts making their square peg fit a round
| hole.
|
| This is less useful when you have ducktyping and consequently
| every lookalike is considered substitutable for each other.
| josteink wrote:
| > Having an interface for a single implementation is just
| redundant. A class already has an interface - it's public API.
|
| Depends on the language.
|
| And sometimes you want to enforce a public contract of _any_
| implementation (current and future).
|
| Personally for me, the biggest gain I see when writing against
| interfaces is that any class which expects a interface is
| already prepared for test-doubles, as opposed to classes
| written against concrete implementations which may even be
| initialised internally. Then just even starting to write a test
| becomes a so much bigger task.
|
| Of course, everything with moderation, sometimes even
| moderation itself ;)
| jayd16 wrote:
| I usually agree but sometimes you want to reduce the exposure
| of the public methods of the concrete class even if there's
| only one concrete implementer.
|
| For example, you might want to pass around a class and only
| expose the getters and not the setters.
| jakevoytko wrote:
| Developers end up at local maxima because a whole bunch of
| practices add up to a working system. It's a mistake to champion
| any single practice without understanding how it fits into an
| ecosystem: time budget, testing, language features available,
| efficiency, tolerance for errors, imposed deadlines, third-party
| technical ecosystem, etc. It's all about the system where they
| all work together.
|
| To truly suggest something as a best practice, you need to
| understand what it requires from the technical and social
| environment around it, and when it applies and doesn't apply.
| We're nowhere near that level of discipline as a field. This lack
| of discipline is why we wince when we hear that a startup is
| implementing something like voting machines: we know the
| financial incentives that lead to startups focusing on speed, and
| we can imagine the discipline that voting systems require. We
| know there's a mismatch between the social environment and the
| likely project management approach. But we're blind to the social
| and technical requirements that allow other practices to work
| well. When is it appropriate to use inheritance? Someone will
| inevitably say, "You shouldn't use it?" Why does it work so well
| in Rails?
|
| IMO it's how developers like John Carmack[0] and Martin Fowler[1]
| can make opposite arguments about things like the benefits of
| having code inline or in functions. These two opinions work in
| conjunction with their environments; maybe video game and
| aerospace coding requires budgeted performance requires
| mutability, so Carmack has to control how you interleave side-
| effects. Maybe enterprise-grade Java programming doesn't have
| much of a performance budget at all, or maybe he values isolating
| testable functions more, so Fowler can take other approaches that
| allow more "readable" styles and not worry so much about side
| effects (since there are few).
|
| [0] http://number-
| none.com/blow/john_carmack_on_inlined_code.htm...
|
| [1] https://www.martinfowler.com/bliki/FunctionLength.html
| faridelnasire wrote:
| Is there really a difference, if more friction for developers ==
| less productivity, less happy developers, and so on?
| [deleted]
| rvr_ wrote:
| I am all against standards and engineering boards defining what
| is right and what is wrong, but at the same time I also favor
| software developers being held civil and criminal
| responsibilities for the outcome of their work. It is pretty hard
| to have the second without the first, so here I am at a
| crossroads.
| alvis wrote:
| 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".
| floverfelt wrote:
| Right, but your definition of discernment is itself a
| preference for readability over conciseness. Another developer
| could say "if it works a month or a year later, then you're
| practicing a best practice."
| SideburnsOfDoom wrote:
| > Are Software Engineering "best practices" just developer
| preferences?
|
| Some are, some aren't. Some are good practices but the state of
| the art evolves and better practices are uncovered.
|
| And it's really had to tell the differences. it's a young field.
| KronisLV wrote:
| > You can't do it "correctly" if "correct" is "whatever the guy
| who's been here longer wants."
|
| To be honest, "correctly" is whatever actually works. But since
| we as an industry haven't been around for a long time and don't
| collectively know what actually works, it is simply the case that
| we defer to those who have comparatively more experience, so that
| we may get decent solutions now, as opposed to excellent ones
| later.
|
| It took the ancient civilizations hundreds if not thousands of
| years to perfect architecture to a reasonable degree, where it's
| possible to be fairly certain about the viability of most typical
| designs, as well as the tradeoffs that nonstandard ones might
| require.
|
| Personally, i think that we'll only be able to talk about what
| truly works and what doesn't once the industry cools down - when
| there are new JS frameworks once a month or once a year as
| opposed to every day (or for any technology, really). When there
| are very few breaking framework changes, because the frameworks
| would finally be stable. When the primitives around doing web
| development, interfacing with devices and everything else have
| been distilled to their most usable possible forms. When a
| developer doesn't need 10 languages or 20 frameworks to do their
| job, but can instead rely upon a few, after most others would
| have died off after a sort of singularity of languages.
|
| That's when useful certifications would be possible. That's when
| estimates wouldn't be guesswork. That's when the education
| systems could actually prepare people fully for working in the
| industry. That's when the development of projects wouldn't be
| such Wild West, but instead would be a process with far higher
| quality, a true engineering discipline even at the expense of
| projects taking longer to actually develop, much like you don't
| construct buildings in an ad hoc fashion.
|
| Now, whether that will happen in a 100 years, a 1000 years or
| never, is another question entirely.
| charles_f wrote:
| I hate the expression "best practice", it's so, so often used by
| someone to justify applying cargo cult without actually
| understanding why.
|
| "Hey why are you having a try-catch there, it seems like it's
| just gonna break our stack trace and we don't even graciously
| recover from it" - it's best practice
|
| "Hey why are you using model/view/controller folders?" - it's
| best practice
|
| "Why are you building microservices?" - best practice.
|
| I got out of a code base with stylecop's settings set to max and
| treated as errors. Trailing white spaces, mandatory comments on
| everything, etc. The only exceptions are file size and method
| size. Files are often in the thousands of lines, and methods can
| reach that as well. 10 levels of nested if/else. So we're in an
| unmanageable code base, but at least we don't have trailing white
| spaces.
|
| Most of the time it could be replaced by "tradition", "pattern",
| or "the way I've seen others do". If it's a tradition and most
| people agree to it, fine, might help with readability. If it's
| pattern, fine, tell me why it's applicable and helpful in our
| context. If you can't actually explain _why_ you 're doing
| something, maybe rethink it and educate yourself on the topic
| tester756 wrote:
| Same with Clean Code, SOLID, DD
|
| SOLID is especially funny because majority of developers
| doesn't understand / can explain it, let alone have read papers
| e.g [0],
|
| except maybe S letter, yet everybody acts like they do SOLID*.
|
| Or Clean Code's small function craziness or misinterpretation
| and going into "avoid comments" approach
|
| * - unless you ask for details
|
| [0] -
| https://www.cs.cmu.edu/~wing/publications/LiskovWing94.pdf
| tdeck wrote:
| Interesting, I guess SOLID must have been a buzzword from an
| earlier era, because while I've vaguely heard of it I had to
| look it up. Don't think it's come up in my 8 years of
| professional work.
|
| There's always an evolution of these methodologies and I
| often feel like in practice they're just a way to mix things
| up and make code health feel more interesting to those
| involved. Often people know there are problems with the
| design of their system, but they can't get buy in to fix
| them. These methodologies provide some authoritative
| justification for refactoring work.
| charles_f wrote:
| So the only caveat I would put on that: it's useful to have
| common language for things, my threshold is that you
| understand why things are this way.
|
| It's useful to tell someone: "you should have that thing in
| another class because it's clearly another responsibility",
| and have a debate on the responsibility itself ; or even on
| the merits of having a single responsibility per class.
|
| What is not useful is when someone will start making
| monofunction classes that are 10 lines long on the hotel of
| "smaller functions are better" and sticking to that because
| "it's a best practice" with no better argument.
|
| Basically my point is: if you understand what you are doing,
| great, use vocab all you want. But don't use it as a
| justification.
| russtrotter wrote:
| There's all kinds of non mission-critical software that gets made
| with little life/death consequence on _how_ it gets made. There
| doesn 't seem to be the same notion of the "bridge that barely
| stands" in software either since compute power can be thrown at
| something way cheaper than a rewrite. Thus, when it comes to the
| people that make software, there's a wild amount of
| interpretation on what "good" means and here we are.
|
| And if I can opine on your Spring Boot example, unit testing can
| _sometimes_ be easier for mock purposes if you have a set of
| interfaces (vs concrete classes) to work with.
| catern wrote:
| After reading this article, the theory that comes to mind is that
| "best practices" not just developer preferences - rather, "best
| practices" is cargo culting by mediocre programmers, trying to
| copy techniques that a really skilled programmer once employed to
| do amazing things.
|
| This is the part of the article that made me think this:
|
| >As I type this, I'm in a discussion about whether it's better to
| pass a few unnecessary parameters to simplify a bash script's
| internal logic or pass fewer parameters and make the bash script
| more complex.
|
| This sounds like they're on the verge of parameterized, object-
| capability design - passing in the paths to operate on, rather
| than hardcoding some internal logic to determine what to do. If
| you do this in the right places and at the right time, you can do
| amazing stuff, reuse scripts in totally novel environments and
| for novel purposes. At other times, it's not necessary. But I'm
| guessing neither side really knows how to use that to do amazing
| stuff.
|
| Some programmers don't have the skill to recognize when a
| specific technique is justified or unjustified. So, unmoored from
| technical reality, they just argue about cultural norms - blindly
| copy what someone else did once, which brought someone else
| success - cargo culting.
|
| That all sounds very mean, but if this is what's actually going
| on, I'm not sure what the solution is. Maybe more focus on really
| impressive and amazing concrete projects, rather than just
| individual practices in isolation?
| commandlinefan wrote:
| I think we'd be better off as a whole if we could agree on
| exactly what it was we were trying to get out of software best
| practices rather than arguing about what they are. To me, the
| biggest problem with all software I've ever worked on - since I
| started programming in 1992 - is how difficult it is to
| reproduce a scenario that a user reports. Making this as simple
| as possible seems to _me_ to be an incredibly important as well
| as relatively straightforward goal, but I have yet to find
| anybody who agrees further than in principle.
| abucius wrote:
| > rather, "best practices" is cargo culting by mediocre
| programmer, trying to copy techniques that a really skilled
| programmer once employed to do amazing things.
|
| and then when this does not work, they call themselves artists.
|
| i actually heard this quite a lot in all these years in the
| field - "coding is an art". it is for some, for most is just
| copy/paste from SO :)
| trav4225 wrote:
| I'm pretty sure that most people consider "software engineer" to
| be just a fake title that makes business cards look fancier...
| sort of like referring to a janitor/custodian as a "sanitation
| engineer".
| gambler wrote:
| Best practices in civil engineering are connected to outcomes.
| You know that something is a good practice if not doing it causes
| things to collapse or catch on fire.
|
| "Best practices" in software engineering are usually about
| internal development processes and don't have any verifiable
| connection to outcomes.
|
| In other words, we have two entirely different things labeled
| with the same name. People who commonly use the phrase "best
| practices" for software are literally trying to confuse you and
| generally are not worth listening to.
|
| That said, some things in software are worth analyzing to have a
| better process, but those things need to be examined within a
| specific context. If someone claims that you need to, say, create
| an interface for every class, they should be able to explain why
| and how it is relevant to your work. If people make claims they
| cannot explain by connecting them to meaningful outcomes, those
| people are, again, not worth listening to. They might be
| mindlessly parroting something they have heard without having any
| clue as to the meaning of the practice. Unfortunately, our field
| is full of "professionals" that do exactly that.
|
| Software is a pretty messed up domain that is frequently a self-
| licking ice-cream cone. (You write code to solve problems created
| by other code.) Because of that, it's often socially mediated,
| just like non-engineering fields. To establish anything for real
| in this self-referential environment you need to be able to have
| conversations about costs, tradeoffs and outcomes - within a
| specific context.
| [deleted]
| josteink wrote:
| It's best practice to apply best practices when it makes sense.
|
| The catch? Knowing when it makes sense requires experience ;)
| strulovich wrote:
| All the problems stated require more context:
|
| - extract an interface or not -> an interface can speed up
| compilation (under the right conditions)
|
| - pass more or less arguments -> how many call sites exist?
| What's the performance difference? Would it complicate testing?
|
| - testing -> depends on what you're building, when do you need it
| by, and how problematic a bug may be (and more)
|
| The reason it looks like some random preference is because over
| time we naturally gravitate (or been told to do) what works, and
| we keep choosing it heuristically since a thorough analysis of
| the problem is too costly or impossible.
|
| Civil engineering has a bunch of hard rules on have X slack here
| because people will die for such mistakes. But I suspect you use
| best practices for less high stake stuff (do we use this outlet
| configuration or this one?) (actual civil engineers are welcome
| to correct me)
| 3pt14159 wrote:
| Did structural engineering for a bit before coming back to
| software.
|
| More or less right about hard rules. They're not _truly_ hard,
| and it 's different in different countries. Some countries have
| performance based rules, others have descriptive rules (must
| have 35mm of concrete cover over reinforcement bars) but even
| in those situations you can usually get some sort of person to
| overrule the rule, it's just costly in both time and money, but
| sometimes its worth it.
|
| Take ultra high performance concrete for example. It's almost a
| different material compared to the normal stuff. But for run of
| the mill construction everyone kinda likes sticking to the
| rules because it's like outsourcing handling all the edge-
| cases. Kinda like using Postgres over writing your own
| persistence layer.
|
| As for hard rules in software, that would be tough. It's much
| more multidimensional and maneuverable than civil engineering
| is and we have less history dealing with it. Also, there are
| way more security concerns than civil engineering, which is
| mostly about safety concerns, where there are no arms races
| against you.
|
| We could still do it abstractly though. Favouring maxims and
| penalties over nitty gritty rules.
| wisienkas wrote:
| To some extend best practices are just developer preferences, but
| some best practices are also due to experience which has shown
| alternatives to attract problems down the lane.
|
| Personally I think the most important thing is to agree within a
| project, what style and what practices to follow, so everyone is
| going in the same direction. This should in my opinion make the
| code more maintainable and extensible, due to the reduction in
| cognitive overload for the developers involved.
| mkl95 wrote:
| There are probably a ton of definitions of what a best practice
| is in SE.
|
| When it comes to code, I like to think best practices are those
| that make code easier to change and understand, without
| significantly compromising performance.
|
| Developers who mainly target high performance with their code
| probably think my best practices suck, and so on.
|
| At a practical level, what really matters is consensus within an
| organization. Organizations where people hold incompatible ideas
| of what good engineering is are basically doomed.
| shados wrote:
| 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.
| [deleted]
| dmalik wrote:
| > 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 requires the application of
| engineering principles, and that concerns the safeguarding of
| life, health, property, economic interests, the public welfare,
| or the environment.
|
| To be considered a work of engineering, then, that a piece of
| software (or a software-intensive system) must meet two
| conditions:
|
| 1. The development of the software has required "the application
| of a systematic, disciplined, quantifiable approach to the
| development, operation, and maintenance of software."
|
| 2. There is a reasonable expectation that failure or
| inappropriate functioning of the system would result in harm to
| life, health, property, economic interests, the public welfare,
| or the environment
|
| [1] - https://engineerscanada.ca/news-and-events/news/when-
| softwar...
| kuratkull wrote:
| I write server-side software for a security system - anyone
| else can write a similarly complex piece of software to monitor
| grains of sand on the beach. So I am an engineer and they are
| not just because my software is used by some pre-described
| group of people?
| Kronen wrote:
| The second condition is a bit stupid, most failures or
| inappropriate functioning of the system in software development
| can be considered a harm in economic interests...
| allo37 wrote:
| 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)
| :).
| wheelinsupial wrote:
| 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 a way to become a P.Eng. in software
| engineering (and until 2018 in the US there was the P.E. in
| software engineering), so there is a way for someone who
| wants to be called a software engineer to legally obtain it.
| So why is there so much resistance?
| Drew_ wrote:
| Because there's a pretty clear difference between software
| engineering and simply just writing code and people who do
| the former pride themselves on that work and want to be
| recognized for it as an engineer rather that just some
| programmer.
|
| You would much rather be recognized as the person who
| devises the plumbing system for a building rather than just
| being a "plumber".
| wheelinsupial wrote:
| There is a formal qualification process to be called an
| engineer. If they truly feel that they should be
| recognized, then they can go through the process.
|
| Because they aren't going through the process the word
| and the recognition can't be that valuable.
|
| I feel there is a contradiction in here somewhere that I
| can't reconcile.
| mywittyname wrote:
| > So why is there so much resistance?
|
| Because,
|
| 1) a PE license is useless for software/computer
| engineering.
|
| 2) the FE exam covers a bunch of irrelevant material.
|
| 3) once you pass the FE exam, there's no real mechanism to
| advance because there are no apprenticeships available in
| computer engineering. And you can't take the PE exam
| without the apprenticeship.
|
| My college spent a lot of money getting an ABET
| accreditation for their CS/CE programs. As such, they
| pushed students really, really, really hard to take the FE
| exam. I went down the path to getting it and realized those
| aforementioned points. The study guide covered electronics
| theory that I had no idea about. It also covered silicon
| chemistry, which was only briefly covered at very high
| levels.
|
| So I'd be learning pretty complex topics on my own, which
| have no professional value. Then, if I wanted to take the
| PE exam, I'd have to find a job where I could apprentice
| for four years. And, as we know, sticking with a job that
| long is terrible for your lifetime earnings.
|
| So yeah, PEs are never going to be a thing in software
| unless they fundamentally change how engineers are
| licensed. Maybe if it was like nursing or law school where
| there's a big exam afterwards that you can take, and if you
| pass, you're licensed. But as it stands now, four years of
| apprenticeship after 4-5 years of schooling is ridiculous.
| wheelinsupial wrote:
| Thanks for providing the US PE perspective. There are
| definitely people practicing as PEngs and apprenticing as
| EITs up in Canada under both the software engineering and
| computer engineering disciplines. So there is some value
| up here to those.
|
| Undergrad covers irrelevant material such as humanities,
| social sciences, and communication that add cost and time
| to an education. Or at least that's the argument people
| enrolled in computer science majors where I graduated put
| forth.
|
| Again, the American perspective is useful. I had no idea
| you would be bound to one employer during the
| apprenticeship process. In Canada, employees are free to
| move around.
| mywittyname wrote:
| > In Canada, employees are free to move around.
|
| I think you can here as well, but the problem is finding
| an apprentice program in Computer & Electrical
| engineering is next to impossible. My school had one
| option for people looking for an apprenticeship. It might
| be better elsewhere in the country.
| WorldMaker wrote:
| Most companies already have the "apprenticeship" half-
| codified in "Junior Developer" versus "Senior Developer"
| distinctions or "Level Ranks" or other ladders like that.
| If you switch jobs mid-"apprenticeship" today in the
| software industry depending on who you interview with and
| how well you can negotiate you either "start over" at a
| low rank/level/job title or luck/bs into "skipping that
| step" and jumping to a higher rank/level/job.
| Standardizing that across the industry wouldn't
| necessarily be a bad thing for the industry.
|
| Similarly, PE licenses would be so hugely worth it to the
| industry if it saved _everyone_ time in "technical
| interviews", both interviewees and interviewers alike.
| How many collective labor hours as an industry are we
| wasting annually on "technical interviews"? For most
| classic Civil Engineering firms the "technical" part of
| the interview is almost entirely "Is your PE license
| valid and up to date?" "Yes." "Great, you're hired." The
| software industry would rather waste multiple hours (if
| not entire days) of wages of everyone involved instead,
| and it's rather sad when you think about it.
| allo37 wrote:
| 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".
| wheelinsupial wrote:
| On the upper end (probably even in the middle) software
| developers earn more than licensed engineers. I'm pretty
| sure your mom can brag about her child the developer
| making 3x what her friend's child the engineer makes.
|
| There are engineers who end up moving to software for
| just this reason.
|
| Software is super important and becomes more so over
| time. I'm not sure why being proud of being a developer
| isn't enough and why it has to end up with wanting to use
| the term engineer.
| allo37 wrote:
| Yeah, titles are a strange thing. There are a lot of PhDs
| out there earning bupkiss, but they're still "doctor"s,
| and that carries a certain respect.
|
| I agree it's mostly BS and doesn't make much sense, but I
| could say the same for much of reality...
| psyc wrote:
| I aggressively refuse to call myself an engineer. Programmer is
| fine. Developer is better, because programming is only a piece
| of it. Y'all can call yourselves whatever you like, but inside
| I'm thinking you retconned an industry insider euphemism into a
| non-existent sub-type of engineering, by protesting all the
| ways you apply rigor to what we do.
| plandis wrote:
| Well crap, I guess I'm going to have to burn my diploma that
| clearly says I'm an electrical engineer.
| mywittyname wrote:
| What of those who graduated from engineering programs taught
| at engineer colleges?
|
| Lots of people in other engineering disciplines build stuff
| with less rigor than is used to build software. Maybe load
| test it in Fusion 360 before sending the file to be milled.
| And lots of software companies test their stuff quite
| rigorously.
|
| People who write software have imposter syndrome. Other
| disciplines are not building things better than we do. For
| every Google there's a Ford, and for every scrappy startup
| there's a scrappy machine shop.
| urda wrote:
| > What of those who graduated from engineering programs
| taught at engineer colleges?
|
| We are the actual Engineers. For US-Based IT workers, that
| means a degree from an ABET [1] backed institution with a
| traditional undergrad and graduate programs.
|
| Anyone else calling themselves an "engineer" while doing IT
| work are not.
|
| In addition: Readers need to remember this isn't reddit and
| downvoting comments with facts you do not like is not
| appropriate for Hacker News. It's is depressing this
| reminder needs to be added here for facts as it appears a
| few readers here have forgotten already.
|
| [1] https://www.abet.org/
| isbvhodnvemrwvn wrote:
| I would trust someone graduating with CS degree from non-
| ABET accredited Stanford rather than someone from ABET-
| accredited CS program of Athens State University.
| cobbal wrote:
| "It's not real engineering if someone can't get hurt" seems
| like a strange definition to me.
| milkytron wrote:
| That's because it is a strange definition.
|
| If you work on the software in a self driving system in a
| car, that makes you an engineer. If you're working on
| software for a space satellite with no occupants... that's
| not an engineer?
| jaywalk wrote:
| Well, the failure of a satellite would definitely result in
| harm to property and economic interests, so it sounds like
| you would still be an engineer in that case.
| tester756 wrote:
| Dropping customer's database would indeed cause a lot of
| harm
| jaywalk wrote:
| Agreed. Seems like the definition might actually be wide
| enough to count the vast majority of software developers
| as engineers.
| bonestamp2 wrote:
| Yes, I think we sometimes use the term "Engineer" a little too
| liberally in the US. For example, sometimes the janitor of an
| office building is called a "Custodial Engineer" which often
| just gets shortened to "Engineer". I remember the first time I
| heard a coworker say, "I'll call the engineer to have the
| thermostat adjusted". I thought that was overkill, but then a
| guy in overalls showed up and it made a little more sense.
| chana_masala wrote:
| Was your colleague from the UK? A number of trade professions
| in the UK are referred to as Engineers, such as for the
| boiler etc.
| skipants wrote:
| And yet, in Canada, every Software Engineer I know works no
| differently than a Software Developer.
| 8note wrote:
| They can sign and stamp things though, which is a difference
| on the work your company can do
| chana_masala wrote:
| I believe I heard this in the Pragmatic Programmer: engineering
| is the practice of applying scientific understanding to real
| world problems. Or more succinctly, engineering is applied
| science. So software engineering is applying computer science
| to solve real world problems.
| 908B64B197 wrote:
| I've met Canadian Software Engineers who referred to themselves
| as Software Engineers...
| Kronen wrote:
| We call Software Developers to coders and then, Consultant or
| Software Architect to the ones who design the systems. In
| between you have Analysts.
|
| Any of them can be Software Engineers or not, because we call
| Software Engineers to the ones with the university career
| finished
| mLuby wrote:
| > "The 'practice of engineering' means any act ... that
| requires the application of engineering principles"
|
| 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.
| agentultra wrote:
| 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.
| auxym wrote:
| Microsoft lost their appeal in Quebec
|
| https://www.oiq.qc.ca/en/media/pressReleases/Pages/default.a.
| ..
| agentultra wrote:
| That's interesting, thanks for sharing!
|
| INAL; it seems, to me, difficult to enforce. You're not
| allowed to call yourself an engineer but you can still
| practice as one as long as you call yourself a developer.
| What's the difference? In practice... very little.
|
| Most developers I know do all the things professional
| engineers do.
|
| Unless the government wants to step in and say that you're
| not allowed to release software without a professional
| software engineer at the helm I think it's trivial. Unless
| a company pays the insurance of an engineer and faces
| severe penalties for disregarding their direction I don't
| see the point of hiring a professional software engineer.
| Companies will simply hire developers rather than deal with
| trifling matters like _liability_.
|
| And we'll continue to see avoidable security breaches in
| the wild for ever and onward because of it. The financial
| incentives are behind "move fast and break things," rather
| than "protect the public interest."
|
| (Mind you I think we should have more of the latter and I'm
| all for liability for the things we create as long as we're
| in control of our future... I'll take the exam if I can be
| brought in with my 20+ years of experience)
| belval wrote:
| It's a bit like saying that you are a doctor, nurse or a
| lawyer (attorney?). In Canada these are protected titles
| that can only be used if you are part of a professional
| order that has oversight over your activities and can
| audit your work at basically any time. There are some
| tasks that can only be performed if you are certified and
| pay the annual fees.
|
| Where this falls apart is that "Software Engineering" is
| a real discipline recognized by the organization that
| handles engineering programs in Canada, however there are
| no "reserved tasks" so a lot of Software Developers have
| a Software Engineering degree but can't call themselves
| that because they (rightfully in my opinion but still)
| refuse to pay the annual membership fees (about 600$)
| since their professional order is actually not equipped
| to audit software engineering work.
|
| Hopefully that helps a little.
| 908B64B197 wrote:
| In this case, I think the enforcement wasn't on the
| people using the tittle. Rather it was on Microsoft
| "granting" someone the tittle of "Engineer".
|
| "Microsoft Corporation announced in May 2001 its
| intention to stop using the term engineer in Canada in
| the title Microsoft Certified System Engineers - MCSE."
|
| Going against the individual professionals for using the
| tittle might have been harder. Some are probably real
| engineers or have received the certification but don't
| necessarily advertise themselves as engineers...
| xav0989 wrote:
| I believe that Shopify will change your job title from
| Engineer to Engineering Technician (or something of that
| nature) if you don't have your professional engineering
| certification.
| dmalik wrote:
| At Shopify I've worked with people with pinky rings and
| they are still called developers :)
| ska wrote:
| A pinky ring and a P.Eng signify very different things.
| In Canada some of (all of) the accreditation groups are
| very sticky about who is called an "Engineer", regardless
| of degrees you have or don't.
| Hamuko wrote:
| Are civil engineering "best practices" just legal preferences?
| NikolaeVarius wrote:
| They are built on top of a ocean of blood
| loloquwowndueo wrote:
| It's called "building code".
| shagie wrote:
| One of the books I picked up to settle an argument about best
| practices once...
|
| A Practical Guide for Policy Analysis by Eugene Bardach. (
| https://us.sagepub.com/en-us/nam/a-practical-guide-for-polic...
| ) and
| https://en.wikipedia.org/wiki/Eightfold_path_(policy_analysi...
|
| Legal practices often follow from established best practices
| rather than the other way around.
|
| There are many _practices_ that solve a problem. Some of them
| have an intrinsic "better" to them. Of those, when trying to
| solve a problem you look at all of them. The one that fits your
| needs best is then the best practice.
|
| > Don't be mislead by the word _best_ in so-called best
| practices research. Rarely will you have any confidence that
| some helpful-looking practice is actually the best among all
| those that address the same problem or opportunity. The
| extensive and careful research needed to document a claim of
| best will almost never have been done. Usually, you will be
| looking for what, more modestly, might be called "good
| practices."
| bdavisx wrote:
| IIRC, the book Code Complete talks about best practices and
| contains links to studies when they apply to those practices. I
| might be wrong, it's been a while since I read the book and I
| can't get to it right now.
| intrepidhero wrote:
| Vernor Vinge uses the term "Programmer-Achaeologist", which feels
| appropriate to any time we're doing software maintenance. If I'm
| truly creating something new I'd go with "Software-Alchemist"
| since the practice feels much more in line with the efforts of
| alchemists to fumblingly come to grips with actual chemistry than
| with modern engineering.
|
| After reading about practices at JPL during the development of
| Curiosity, and the earlier work on Apollo (just two examples) I
| do think there is such a thing as an engineering practice of
| software development. I just don't think most of us are using it.
| andy_ppp wrote:
| Make the simplest thing you possibly can, write lots of software
| tests and keep in mind that your code is a piece of communication
| to the next developer, like a story. Everything else is just
| vanity or preferences.
| gchamonlive wrote:
| Lots of small, simple things can add up to a really complex and
| not very much maintainable result if you are not careful
| pjmlp wrote:
| > My housemate the other day asked me something to the effect of
| "How can Software Engineers call themselves engineers when
| there's no rules, governing bodies, or anything to stipulate what
| true Software Engineering is?"
|
| There sure is, that is what countries that have Professional
| Engineering titles have.
| nine_zeros wrote:
| A LOT of coding style, abstraction style, function vs inline is
| just preferences. This is what makes code reviews hard. Both the
| author and reviewer can easily fall into the trap of trying to
| "correct" the other person - without realizing that they are
| merely forcing preferences on the other.
|
| That said, it is ok to write down some preferences as a team/org
| standard that everyone can follow.
|
| Just don't make the job a lawyers attempt at software
| engineering.
| afry1 wrote:
| I hope at least that we're in a phase of the profession where
| we're "discovering" the actual best practices.
|
| There have been a lot of best practices that have been
| hypothesized over time: OOP, functional programming, unit
| testing, generative testing, formal analysis, strict typing, weak
| typing, etc.
|
| And all these as-of-yet unfounded hypotheses are important!
| You've got to have a theory of how something works before you can
| prove that it does. Hopefully we can start to devise those
| proofs.
| julianlam wrote:
| We're definitely still figuring out what the best practices
| are. In my relatively short career as a software developer,
| we've already flipped back and forth between separation of
| concerns is important when it comes to views, styling, and
| logic. (Frontend dev)
|
| Gone are the days when we threw together a php, html, and
| JavaScript in one file... wait, or is it?
| afry1 wrote:
| Give it a couple years, it'll come back around!
| alfonsodev wrote:
| best practices are programming style convergence, which helps
| estimating software in my opinion.
| StillBored wrote:
| Well the choices should be based on data, does method 1 or method
| 2 result in code which functions longer without needing to be
| fixed, or updated.
|
| There _IS_ data about some of this, but the results frequently go
| against the opinions of various people, so they are discounted.
| And then there is the problem that the industry as a whole has a
| tendency to run away from old/stale/well understood/etc
| technologies in support of untested new products. Which is how
| you get the cool language churn. You can just look at the last 20
| years of server side web development, php, ruby, python,
| javascript, were all the "best choice" at one point or another,
| only to be pushed to the sidelines when they were discovered to
| be sub-optimal in some way.
|
| So, its like the C/java/etc brace problem. There were a fair
| number of actual studies showing that matched brace styles seem
| to result in fewer bugs back in the 1990's, yet overwhelmingly
| the opensource community rejects that in nearly every single
| project regardless of language. Why? Presumably its just personal
| preference going back to the old days of 80x25 tty's where
| whitespace was at a premium, same as the 80 column limits many
| projects employ.
| JohnFen wrote:
| I've always used "best practices" as a nicer way of saying
| "commonly accepted". It's not really developer preferences --
| there are a number of best practices that I don't prefer as a
| developer.
| andrekandre wrote:
| it feels like though, whats "commonly accepted" changes quite
| rapidly though doesnt it?
|
| i think we probably need a more rigorous definition or else
| people will keep using "best practice" to justify what is
| actually a preference, and i think thats where conflicts start
| to happen within teams/orgs.
| lincpa wrote:
| It's "best practices" of Software Engineering that "The Grand
| Unified Programming Theory: The Pure Function Pipeline Data Flow
| with Principle-based Warehouse/Workshop Model".
|
| It makes development a simple task of serial and parallel
| functional pipelined "CRUD".
|
| https://github.com/linpengcheng/PurefunctionPipelineDataflow
| snidane wrote:
| "best practices" = "common practices" in practice.
|
| Not necessarily best. Best practices you get when you apply a
| darwinian approach in your org and try out several techniques
| before selecting the best. What is called best practices too
| often is a name for "we've done it this way since the beginning".
| npteljes wrote:
| >How can Software Engineers call themselves engineers
|
| I always wondered the same thing, even now, az a so-called Lead
| Software Engineer. Frankly I call myself a programmer and that's
| it, maybe a "manager of sorts" now that I'm a "lead". I don't
| want to assume what others are doing, maybe engineering level
| work, but I'm rather an overpriced jack of all trades myself, who
| happened to have a nicely paying trade as a hobby, and an
| agreeable personality to sell it.
|
| Architect is another glorified software position. Millenia of
| architects pushing the limits of human technology, often bearing
| huge responsibility for their plans, just so that later I can
| come in, advise my client to use the AWS vendor lock-in vehicle,
| and call myself an architect.
| valeness wrote:
| Are there not also mediocre traditional architects? Why are you
| comparing architects that push the boundaries of human
| achievment with the most mediocre of software architects who
| just advise people use AWS?
|
| Words change over time and it's not like programmers AREN'T
| pushing the limits of human technology. What is much more
| advanced than your cellphone right now? Or the software that
| drives the Super Colliders? Or the software that runs an MRI?
|
| I agree that our industry mis-appropriates the title
| "Engineer", but there is no reason to be so dismissive either.
| thereddaikon wrote:
| "The parallel he drew was to another friend who's a Civil
| Engineer. His friend had to be state certified and build
| everything to certain codes that stand up to specific stressors
| and inspections.
|
| I gave him the usual answer about how Software Engineers deal
| with low stakes and high iterability compared to Civil Engineers,
| but, honestly, he has a point."
|
| I've argued for awhile now that Software Engineering with a big E
| should be licensed and regulated the same as any other
| Engineering discipline. Not all software is low stakes and fast
| changing. In fact I'd argue the most important software is never
| that. software for control systems, avionics, cars etc are very
| high stakes and have no reason to iterate beyond what is needed
| to interface with changing hardware. I think if software
| engineers had to be licensed to work on such things then those
| 737s wouldn't have fallen out of the sky and Tesla wouldn't be
| allowed to beta test self driving cars on public roads.
|
| To those who ask what do you now call software engineers who
| don't work on those things, you are programmers. Or if you prefer
| a less formal term, coders. Engineer is a powerful word and I
| don't like how the we the IT industry have appropriated it for
| less critical tasks.
| sime2009 wrote:
| In a way there are standards for software but those standards
| are not expressed in software terms.
|
| Firstly, most software is harmless. If it goes wrong people may
| be annoyed, but no one is harmed. But if I write software to
| control an aircraft, then it would have to abide by aviation
| standards. If I write financial software then I would have
| financial regulations to follow. Same for medical devices. So,
| there are standards for software but they are indirect and
| expressed in terms of the wider domain in which it runs.
| thereddaikon wrote:
| While that's true, those standards don't really fully account
| for the needs of proper software engineering practices IMO.
| You can say aircraft code follow aerospace standards yet
| those standards didn't stop Boeing from making a system that
| overrode pilot input while only relying on two sensors. It
| also didn't stop Boeing from launching a space capsule that
| didn't have the thrusters mapped properly. Nor did it prevent
| Lockheed from shipping GPS code that caused the navigation
| system of the F-22 from crashing when it crossed the
| international dateline. Standards and norms aren't the same
| thing as a building code. Civil Engineers have a code they
| must meet at minimum for the things they build. There are
| ways that certain things must be done and they have to sign
| off on every project. We don't see that with equally
| important software. For some reason if a bridge collapses and
| it was found that it was designed wrong the engineer goes to
| jail but if a plane crashes because its autopilot had design
| flaws the developer doesn't.
| westurner wrote:
| Critical systems:
| https://en.wikipedia.org/wiki/Critical_system :
|
| > _There are four types of critical systems: safety critical,
| mission critical, business critical and security critical._
|
| Safety-critical systems > "Software engineering for safety-
| critical systems" https://en.wikipedia.org/wiki/Safety-
| critical_system#Softwar... :
|
| > _By setting a standard for which a system is required to be
| developed under, it forces the designers to stick to the
| requirements. The avionics industry has succeeded in
| producing standard methods for producing life-critical
| avionics software. Similar standards exist for industry, in
| general, (IEC 61508) and automotive (ISO 26262), medical (IEC
| 62304) and nuclear (IEC 61513) industries specifically. The
| standard approach is to carefully code, inspect, document,
| test, verify and analyze the system. Another approach is to
| certify a production system, a compiler, and then generate
| the system 's code from specifications. Another approach uses
| formal methods to generate proofs that the code meets
| requirements.[11] All of these approaches improve the
| software quality in safety-critical systems by testing or
| eliminating manual steps in the development process, because
| people make mistakes, and these mistakes are the most common
| cause of potential life-threatening errors._
|
| awesome-safety-critical lists very many resources for safety
| critical systems: https://awesome-safety-
| critical.readthedocs.io/en/latest/
|
| There are many ['Engineering'] certification programs for
| software and other STEM fields. One test to qualify
| applicants does not qualify as a sufficient set of controls
| for safety critical systems that must be resilient, fault-
| tolerant, and redundant.
|
| A _real Engineer_ knows that there are insufficient process
| controls from review of very little documentation; it 's just
| process wisdom from experience. An engineer starts with this
| premise: "There are insufficient controls to do this safely"
| because [test scenario parameter set n] would result in the
| system state - the output of probably actually a complex
| nonlinear dynamic system - being unacceptable: outside of
| acceptable parameters for safe operation.
|
| Are there [formal] Engineering methods that should be
| requisite to "Computer Science" degrees? What about "Applied
| Secure Coding Practices in [Language]"? Is that sufficient to
| teach theory and formal methods?
|
| From "How We Proved the Eth2 Deposit Contract Is Free of
| Runtime Errors" https://news.ycombinator.com/item?id=28513922
| :
|
| >> _From "Discover and Prevent Linux Kernel Zero-Day Exploit
| Using Formal Verification"
| https://news.ycombinator.com/item?id=27442273 :_
|
| >> _[Coq, VST, CompCert]_
|
| >> _Formal
| methods:https://en.wikipedia.org/wiki/Formal_methods _
|
| >> _Formal specification:https://en.wikipedia.org/wiki/Formal
| _specification _
|
| >> _Implementation of formal
| specification:https://en.wikipedia.org/wiki/Anti-
| pattern#Software_engineer... _
|
| >> _Formal verification:https://en.wikipedia.org/wiki/Formal_
| verification _
|
| >> _From "Why Don't People Use Formal Methods?"
| https://news.ycombinator.com/item?id=18965964 :_
|
| >>> _Which universities teach formal methods?_
|
| >>> _- q=formal+verificationhttps://www.class-
| central.com/search?q=formal+verification _
|
| >>> _- q=formal+methodshttps://www.class-
| central.com/search?q=formal+methods _
|
| >>> _Is formal verification a required course or curriculum
| competency for any Computer Science or Software Engineering /
| Computer Engineering degree programs?
| https://news.ycombinator.com/item?id=28513922 _
|
| From "Ask HN: Is it worth it to learn C in 2020?"
| https://news.ycombinator.com/item?id=21878372 :
|
| > _There are a number of coding guidelines e.g. for safety-
| critical systems where bounded running time and resource
| consumption are essential. These coding guidelines and
| standards are basically only available for C, C++, and Ada._
|
| awesome-safety-critical > Software safety standards:
| https://awesome-safety-
| critical.readthedocs.io/en/latest/#so...
|
| awesome-safety-critical > Coding Guidelines: https://awesome-
| safety-critical.readthedocs.io/en/latest/#co...
| glanzwulf wrote:
| I get your friend, and there's another point he can make: Imagine
| a world with self taught Civil Engineers.
| lanstin wrote:
| Oh yeah the last bridge collapsed, but that is a known issue.
| It is fixed in this bridge, trust me.
| pdpi wrote:
| That's sort of the Tacoma Narrows Bridge story.
| walshemj wrote:
| Blame the contractor is what you normally do in this case :-)
|
| I once built a system reverse engineering a program used for
| soil analysis to see why one of our bridges fell off its
| suports.
| a_conservative wrote:
| Can you tell us more? This sounds oddly fascinating.
| rajin444 wrote:
| To make the comparison fair, in that world civil engineers
| would also have the ability to change the laws of physics.
| dntrkv wrote:
| Or you can just compare them to software engineers that work
| on critical software like launch systems and nuclear
| reactors.
|
| Software can be just as reliable when there is a need for it.
| Thing is, 99% of the time you don't need those extra 9s.
| rajin444 wrote:
| Yeah, that's a very good point! I imagine if civil
| engineers could change physics, they'd lockdown what you're
| allowed to change for critical systems. And like you said,
| systems that don't need the 9s can experiment and learn.
| BiteCode_dev wrote:
| And the bridge collapsing would usually not kill people but
| strip all their clothes.
|
| Also you can start a bridge in your garage.
| dkersten wrote:
| The clients also usually don't want to pay for a stable
| safe bridge because the collapsing one is good enough.
| BiteCode_dev wrote:
| Pretty much. IT as a field is a toddler. But it makes so many
| people happy we don't care it's still at the anal stage.
|
| Maybe in a century techs and standards will stabilize.
| gambler wrote:
| _> Pretty much. IT as a field is a toddler._
|
| It's exactly as old as nuclear engineering.
|
| If it's a toddler, it's because of the mentality of the
| people involved, not because there was no time to figure
| things out.
| dtech wrote:
| nuclear engineering is a direct combination of applied
| physics, civil engineering and mechanical engineering, all
| having a long history.
|
| SE started out from mathematics, but the hardest problems
| are not related to it. We're only pretty good at nailing
| the things directly from mathematics like algorithmic
| complexity or distributed system guarantees.
| dntrkv wrote:
| It's almost like we have different standards for different
| types of engineering.
|
| The devs writing code for the next social media app operate
| under very different standards than the ones writing code
| for nuclear reactors. And that's ok.
| zapataband1 wrote:
| Pretty sure this is because most of our public investing
| goes towards spying programs instead of more funding for
| places like NIST.
|
| Not to mention funding for governments that actively sell
| exploits to other nations. Standards seem to be left up to
| the industry. I saw the Kubernetes hardening guildelines
| from NIST a while back that was cool.
| BiteCode_dev wrote:
| Which was left in the hands of a small elite from the
| beginning. I don't think reddit could have been born that
| way :)
| agentultra wrote:
| In some cases, perhaps, but the _state of the art_ is always
| evolving and a lot of it is informed by how people practice
| software engineering in the wild.
|
| _Professional Engineer_ is a modern concept. In the United
| States it started in 1907. Sure we have been building irrigation
| systems for thousands of years but it wasn 't regulated by
| governments until recent history.
|
| Until then it was a practice guarded by guilds and seen as a
| craft.
|
| Software isn't without its own history. The mathematicians and
| logicians had been working on it long before the first computing
| machine was built. We've known how to compute values for
| thousands of years.
|
| Are we still in the craft/guild phase of the discipline? I don't
| think so. There are professional engineering organizations around
| the world that are certifying software engineers. If that is all
| that is required you can apply today.
|
| The missing piece is that it's not required by governments around
| the world to have any professional affiliation or certification
| to practice programming professionally. Some argue this is a good
| thing as it keeps the playing field level. Others argue its bad
| as it enables profit-motivated companies to cut corners that harm
| businesses and users.
|
| But as far as best practices go, as long as there are enough
| people practising them across the industry, then it's not simply
| a _preference_. A good guide on this is the SWEBOK [0] published
| by the IEEE which attempts to catalogue these practices in a
| living document that gets updated as the _state of the art_
| develops.
|
| [0]
| https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K...
| strken wrote:
| Aren't best practices things like "don't roll your own crypto if
| you can avoid it", "store your code in version control", or
| "write down migrations as well as up migrations"? These are all
| choices where the right option has been absorbed into the craft.
|
| Civil engineering best practices are written in blood, but I
| think software engineering best practices can be stretched to
| include sweat and tears too.
| memco wrote:
| I found this video on the topic very compelling: Intro to
| Empirical Software Engineering: What We Know We Don't Know *
| Hillel Wayne * GOTO 2019:
| https://www.youtube.com/watch?v=WELBnE33dpY
| Kronen wrote:
| > At the end of the day, you wind up in a lot of fairly pointless
| arguments about tech stack and coding conventions that 99.9% of
| the time don't make a bit of difference to the final product.
|
| 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...
| mytailorisrich wrote:
| The issue here is that people abuse the term and call many things
| and anything a "best practice".
|
| An actual best practice is based on objective criteria and
| experience, and can be shown to lead to better outcomes over the
| alternatives.
|
| If that's not the case, then it is just a preference, indeed.
|
| For instance, version control is a best practice. It objectively
| improves software development. So is unit testing, etc.
| sprafa wrote:
| Software engineering seems partially creative partially technical
| - so on the creative parts, yes absolutely teams should self
| define their preferences. Scrum vs agile vs whatever else IMO
| should be a team/org preference. However like someone else said
| some engineering has to be liable for criminal prosecution in
| some cases. So you need some practices to be enforced.
| julianlam wrote:
| Sure, so who defines which parts are highly technical? We can
| all be in agreement that things like cryptography should use
| well known and vetted libraries, whereas something like a REST
| API interface can be a little more relaxed with adherence to a
| standard, but where do we draw the line?
|
| I do not want to live in a world where my code must conform to
| a Java Bean factory class. I align more with the skunkworks
| style of development.
|
| I once work on contract on a project where everything was
| abstracted to hell and back. We spent 90% of our time trying to
| figure out where references pointed to in the code. Never
| again.
| postalrat wrote:
| Best practices create a shared experience that can help get you
| out of trouble when that practice was a bad decision.
| mywittyname wrote:
| > How can Software Engineers call themselves engineers when
| there's no rules, governing bodies, or anything to stipulate what
| true Software Engineering is?
|
| So the world had no engineers before the creation of governing
| bodies? That doesn't sound right to me. Thus, I think this
| person's definition needs some tweaking.
| julianlam wrote:
| Not quite, a governing body is what stipulates who can be
| called an engineer and who cannot (at least this is the case in
| Canada.)
|
| Certainly those who did engineering-like work existed before
| governing bodies, you just never really knew whether they were
| any good, because there was no minimum set of competency
| defined.
|
| Ironically, one might say this is what software development is
| like right now! It is both a blessing and a curse, the
| accessibility of modern software development is what makes it
| so great, pitfalls and all.
| StatsAreFun wrote:
| The two aren't mutually excusive. What I mean is, you can develop
| a preference for doing a software engineering task according to a
| best practice. Getting into the habit of using one or more time-
| tested practice(s) will only benefit you over time.
|
| But, more fundamentally, what the author could have responded to
| their friend is: "Yes, we do have a code of ethics and
| professional practice standards[0]. We do have well-researched
| best practices and a rich standardized body of knowledge we can
| use[2]. We do have formally adopted standards through IEEE, ISO
| and IEC[1]."
|
| I do get the sentiment behind the question though and personally
| wish we were more formally trained and held more rigorously to a
| professional set of standards. It does diminish the term
| "Software Engineer" as a engineering field when we use the title
| so loosely but (on some level) expect the same level of respect,
| pay and status as other engineers.
|
| [0] https://ethics.acm.org/code-of-ethics/software-
| engineering-c... [1]
| https://en.wikipedia.org/wiki/ISO/IEC_JTC_1/SC_7 [2]
| https://www.computer.org/education/bodies-of-knowledge/softw...
| floverfelt wrote:
| I did say that to be fair, I just omitted it from the post.
|
| The question was more of a jumping off point for my thoughts on
| the practices vs. preferences question.
| StatsAreFun wrote:
| Fair enough! Thank you for posting the article and getting
| this discussion going, by the way.
| Sohcahtoa82 wrote:
| > _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 verbose.
|
| Getters and Setters? You probably don't need them. Classes _can_
| have public member variables.
|
| Java programmers seem to have the hardest time understanding
| YAGNI.
| bitwize wrote:
| > 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 verbose.
|
| That's the 'D' in SOLID -- dependency inversion. An object's
| dependencies should be defined in terms of abstract interfaces,
| not concrete classes. The verbosity is just boilerplate, and it
| would appear in any statically typed language if you're
| following SOLID principles.
|
| > Getters and Setters? You probably don't need them. Classes
| can have public member variables.
|
| Getters and setters are part of the JavaBeans spec for being
| able to load and configure arbitrary beans. If you're writing
| JavaBeans, as many EJB or Spring application developers are,
| you'll use getters and setters.
| avgcorrection wrote:
| > Getters and Setters? You probably don't need them. Classes
| can have public member variables.
|
| We do need them if the objects interact with a lot the
| libraries that we use. Libraries that we didn't make. They
| expect get/set.
|
| I agree that getters/setters are very overrated. I tend to make
| public-final fields when I can. Most of the time I can't
| though.
| floverfelt wrote:
| 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.
| shagie wrote:
| > Getters and Setters? You probably don't need them. Classes
| can have public member variables.
|
| The getter / setter debate and public fields is about exposing
| the internal implementation of the object (and thus making it
| unchangeable without breaking other code) and being able to
| reason about where the internals are used (if you _do_ need to
| change them).
|
| For example, if I've got a java.util.Date exposed as a public
| field and someone uses it, I can't change that later to a
| java.time.LocalDateTime unless I change all of the things using
| it. If this is a library that others are using it may mean a
| cascade of unknown changes.
|
| If, on the other hand, the Date was exposed as a public Date
| getDate() { return date.clone(); } then I don't have to worry
| about it. When the internals are changed to LocalDateTime, then
| Date getDate() { return
| Date.from(local.atZone(ZoneId.systemDefault()).toInstant()); }
| and everything will still work.
|
| I _don 't_ have an issue with the infrequently used "default
| package private" level of field visibility where only classes
| in the same package can see that field as that limits the range
| of the changes to the classes within single package (in a
| single project).
| Jtsummers wrote:
| Getters and Setters also permit you to specify that something
| can _only_ be retrieved or assigned, but not the other. This
| is non-trivial in most programming languages so having this
| as a common pattern is useful. Though I like C# 's properties
| versus seeing a bunch of getFoo and setFoo methods running
| around, if Java had provided the same or a similar capability
| there would probably be no controversy. It's the noisiness of
| the Java solution that seems to irk people more than the
| concept.
| avgcorrection wrote:
| > Getters and Setters also permit you to specify that
| something can only be retrieved or assigned, but not the
| other.
|
| Only retrieved? `final` and set the fields through the
| constructor.
|
| Sure someone could implement setters-only if they wanted
| that. Except I've never seen it and get/set are always used
| instead. Just one layer of indirection for no benefit.
| Jtsummers wrote:
| That's not equivalent. You may want a field to be updated
| by other actions. That is, its value is derived from the
| other properties of the system. You _could_ recompute
| those on each request, but that 's potentially costly.
| You could also recreate the entire object with each small
| field change. That's also very costly.
|
| Consider a collection class which has a size field.
| `final` would be the wrong thing to use. If you expose
| the size field but make it final, well, it's immutable
| and your entire collection is either lying or also
| immutable. If you expose the size field but it's not
| final, then anything can alter it. Consequently, a getter
| (the concept of one at least, see C# again for a cleaner
| approach than what Java did historically) is useful and
| then when another element of the interface is used
| (adding or removing elements) the size field can be
| updated appropriately. The next time it's retrieved, it's
| correct and you don't need to recompute it.
|
| This kind of thing can be a consequence of many other
| systems, a collection is just sufficiently universally
| understood that it's a good example of the concept.
| shagie wrote:
| Java now has records which handles the creation of getters
| (and since its an immutable, it doesn't have any setters).
|
| https://blogs.oracle.com/javamagazine/post/records-come-
| to-j... and https://dzone.com/articles/what-are-java-
| records
|
| I'm really looking forward to using the local records
| defined mid stream for bundling the information to the next
| part.
| avgcorrection wrote:
| Apparently your field was used both for some internal
| shenanigans as well as a public field through the get/set
| indirection. Then you changed the field but kept the old
| public behavior. I wonder whether (1) that dual purpose
| internal/public role was wise to be begin with, and (2)
| whether that change of the internal logic of the getter might
| have just papered over a more significant change.
|
| It might be good if a change just breaks client code. The
| client expects just to get/set something: they might not
| expect that some update migth add arbitrary logging or
| internal logic (like setting this value will _also_ set
| another value, but we won't tell you).
|
| Most of the get/set stuff that I see are for value objects
| with either no or little business logic. Simple value objects
| _should_ just expose their implementation.
| shagie wrote:
| The backing implementation of what supplies the DTO
| shouldn't be an issue for the client / other part of the
| application if the contract that the DTO provides remains
| the same.
|
| If that contract is the underlying field implementation,
| then that means that those fields are frozen and cannot
| change.
|
| If that contract is instead methods, the underlying field
| types can change (for example from a Date to a
| LocalDateTime) while the method contracts remain the same
| and new method contracts are added to expose more
| functionality for other clients / application modules.
|
| In particular, this was code written in the Java 1.7 days
| and it was Date (and all the mess with java.util.Date and
| java.sql.Date) while in 1.8 java.time was provided which
| allowed the underlying implementation of the object to
| cleaned up without changing the contract of the methods
| (things wanting a Date still get a Date).
|
| Yes, changing from a Date to a Calendar (because of the
| aforementioned java.sql.Date mess) to a LocalDateTime were
| significant changes -- but the clients didn't notice
| because the methods they were using remained consistent.
|
| The deeper you expose the client contract into the guts of
| the object, the more difficult it is to change when a
| change is needed.
|
| Now, if you're just passing DTOs around between classes
| within a single package or local to one library that don't
| leak - feel free to do whatever is needed. I suspect that
| records will solve a lot of the boilerplate DTO code,
| though passing a record outside of a library boundary gives
| me a bit of unease because it means that changes to the
| record will be breaking changes to the clients.
| [deleted]
| web007 wrote:
| Short answer: No, they're not.
|
| Longer answer: I'm confused by the examples given. Nothing there
| is a best practice IMO, they are only opinions.
|
| This writer is confusing "use git" or more basically "use version
| control" with the how's and why's underneath. Everything beyond
| "use it" is an opinion, with multiple "best" options depending on
| your desired workflow or requirements.
|
| Same for Java - the senior explained why this version of "best"
| is best for them, but the real best practice of "define your
| interface as a contract" is hidden behind these opinions.
|
| Contrast this with the civil engineer used as an example, who
| might say "use a safety factor of 3x rated weight for all
| fasteners" as their best practice. Using fasteners rated at 2x is
| a violation of that, but using screws vs bolts vs adhesive are
| all opinions and depend on the particulars and preferences of
| whoever is doing the work.
| alistairSH wrote:
| I've never had the title "Software Engineer". It's always been
| "Software Developer". And that feels appropriate. I write
| business software. Nobody dies if it fails. The monetary damages
| are generally small (in absolute terms) and problems easily
| rectified (relative to fixing a failed bridge).
|
| I would expect a software engineer to be working on safety-
| critical systems. Power grid control, military applications, etc.
| And I hope there's a massive amount more rigor applied to their
| work than there is to mine.
| gedy wrote:
| I'd say that a lot of devs do have a hard time distinguishing
| "best practices" vs "the way I like to code". It's also tough
| because many of the motivated devs who can push these initiatives
| through need help with the sometimes subtle difference.
| Jensson wrote:
| Software engineering best practices are stuff like version
| control and automated tests. Many teams still don't have those
| and they ought to have them. "Squashing commits" isn't an example
| of best practice even if some people try to say that.
| hyperman1 wrote:
| There is value in predictability, even if it stems from someone
| else's preferences.
|
| Current home wiring requires you put wires in the wall at (I
| think) between 10 and 20 cm from the border, and a small number
| of cm inside the wall. This means you only have to check that
| zone, and can use detectors, to find the wires.
|
| My home is from the 1950's. Some wires go diagonally from top
| left to bottom right at the _other_ side of the wall. We had
| great fun finding out where they were hiding.
|
| Even if the new wires waste a lot more wiring and PVC tube, I
| vastly prefer them when redecorating or drilling holes.
| floverfelt wrote:
| 100% that's true! I'm not saying developers having preferences
| and everybody abiding by them is a bad thing, more just that a
| lot of what constitutes "best practices" are often preferences
| and we should call them that.
| only_as_i_fall wrote:
| 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.
| anthonygd wrote:
| I'm not sure if there's anything 95% of developers are on
| the same page about.
|
| From what I've seen, every company has a different idea of
| what _best practices_ are. Generally comes down to what
| some influential developer likes.
| mindcrime wrote:
| _From what I 've seen, every company has a different idea
| of what _best practices_ are._
|
| And that's fine. "Best practices" don't necessarily need
| to be universal in scope. Read the Knowledge Management
| literature and you'll see plenty of discussion of the
| idea of scoping "best practices" to in terms of "site
| best practice", "company best practice", "industry best
| practice" and so on.
|
| There's also a lot of discussion about using different
| language other than "best practice" exactly to
| acknowledge that "best practices" aren't always _BEST_
| practices, if you get what I mean. Calling them something
| like "recommended practices" or "proven practices" or
| similar lingo gives a way to denote things that are
| recommended at least locally, without having to claim
| that they are either universal in scope, or absolutely
| "best" in any sense.
| floverfelt wrote:
| 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.
| only_as_i_fall wrote:
| 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.
| erdo wrote:
| I agree, at least in my experience of android development,
| "Best Practice" often means: what I read on Medium, or what
| Google said.
|
| It's for people who aren't confident enough to admit to
| simply having a preference, or knowledgeable enough to be
| able to explain it
| AdrianB1 wrote:
| In many countries this is coded (mandated by standards), it is
| not a best practice.
| tannhaeuser wrote:
| 1950's onwards they used ribbon cables close to surfaces for
| household wiring. It _was_ best practice, just not today 's.
|
| As a freelancer jumping projects, I can't help but see
| parallels, in that you've really got to study code bases wrt
| the time of authorship to understand their particular
| idiosyncrasies.
|
| In the 2010's, people believed in "REST" without considering
| the context in which these concepts were introduced (eg thin
| browser UIs, or generalizations thereof as a baseline).
| Customers, even highly capable devs, flaunt their REST best
| practices, yet see HATEOAS as optional and pretentious, failing
| to see the entire point of loose coupling and discovery, and
| engaging in zealotry about squeezing parameters into URLs
| instead. Or pretend to, to stop pointless discussions with
| mediocre, bureaucratic peers.
| jasode wrote:
| _> "How can Software Engineers call themselves engineers when
| there's no rules, governing bodies, or anything to stipulate what
| true Software Engineering is? The parallel he drew was to another
| friend who's a Civil Engineer. His friend had to be state
| certified "_
|
| 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.
| pram wrote:
| Even in infra, those jobs used to be called
| Operator/Administrator. Now everything is also an engineer,
| with increasingly baroque acronyms prepended (DevSecOps the new
| hotness)
| PedroBatista wrote:
| Yes and no.
|
| Given the context of the authors ( and this also includes
| employment context, socioeconomic and personality factors for
| everyone involved ), the best practice is something that has been
| "proved" to work well.
|
| So no, it's not just a preference, but in practical terms many
| times it's a preference that some people agree it worked ( in
| their context ).
|
| And let's not even talk about the "best practices" and
| technologies created just to sell you something. I think by now
| it's not a secret that most "developer evangelists" or even
| "famous" developers are just people doing sales and marketing,
| some of them don't even realize it such is their ego trip.
| flongo wrote:
| 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.
| Verdex wrote:
| Serious question. Can humanity define what it means for
| something to be simple or complex? It seems like we all have an
| intuition that such a thing should exist. However, most times
| when I talk to people about it, the conclusion I reach is that
| they're talking about what is familiar or unfamiliar.
|
| 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.
|
| ]
| Smeevy wrote:
| I agree with the author, but saying "best practice" in a group
| discussion is frequently used to make someone's position sound
| more official. "Industry standard" gets used the same way. Some
| people think that saying these things is like pressing an "I get
| what I want" button.
|
| I have to fight the urge to ask for citations whenever I see
| someone pull out one of these chestnuts. Rather than be
| contentious, I just think about whether or not their argument
| _needs_ the extra oomph of authority that they 're trying to give
| it. My hope is that not rewarding disingenuity reduces its power.
| tsuujin wrote:
| This is a pet peeve of mine, but it's so ingrained into dev
| culture that it seems impossible to stop. We could have a
| little bit of intellectual integrity and at least say "good"
| instead of "best" but we won't.
|
| We also use it to argue for opinion over empirical data points.
| E.g., tabs vs spaces. The "best practice" is some arbitrary
| number of spaces because "alignment"; this ignores entirely a
| substantial argument for tabs in the form of accessibility--you
| can make a tab whatever width you want, so if you're visually
| impaired you don't have to modify the code to read it and re-
| format it to the "best practice". TLDR; tab indentation
| followed by space alignment would actually satisfy everyone's
| needs, but it's totally off the table because "best practice"
| is spaces.
| jenscow wrote:
| "Standards" cover what the system does. "Best practices" cover
| how it's done.
|
| Best practices (generally opinions based on reasoning): language
| choice, KISS/DRY/YAGNI, linter rules, unit tests, static vs
| dynamic linking.
|
| Standards (de-facto, at least): ISO, RFCs, PCI, and whatever is
| relevant for the industry the solution is for.
| lgeorget wrote:
| 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.
| floverfelt wrote:
| Yeah, I told him that, but by and large most developers don't
| work on those problems.
| RNCTX wrote:
| 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 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.
| jgalentine007 wrote:
| Question- if you're using eval() and bleach, won't your
| security be totally dependent on bleach not having a
| vulnerability?
| RNCTX wrote:
| 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/
| stillbourne wrote:
| Right now I am working on converting a front end application
| written in angualar/typescript using a monorepo technology called
| nx.dev into a micro-frontend architecture. All the teams that
| have been contributing code to the project never bothered to use
| nx in the way that it was intended and disabled linting for the
| entire project. The thing is if people had followed the linting
| rules it would have made my life 1000x times easier because now I
| have to take a scalpel to the monolith they've made and break it
| down into smaller parts. Linting rules would have told them to
| respect module boundaries and warned about circular dependencies.
| Now I have to clean up the mess.
| sumtechguy wrote:
| That falls clearly into one of my best practices 'look at the
| logs they are trying to tell you something'. But like all 'best
| practices' it can be take too far. So now you have tons of
| logging but can not actually tell what is going on because
| there is too much noise.
|
| I had something similar once I turned up all the logging on all
| the projects under my control. Suddenly 'there are tons of
| errors'. 'Yeah they were there the whole time because we
| ignored them'. Sort of like what happened with linux earlier
| this year. Turned up logging and suddenly everything is broken.
| It already is broken. You have just been ignoring it.
| overgard wrote:
| Engineering is the wrong classification. I think the problem is
| it's new enough that people try to relate it to other
| disciplines. Coding is just its own thing.
| letwhile wrote:
| I don't see the point of this. As an engineer you get a task and
| then pick a solution from a bag you have, that is not optimal,
| but fulfills the constraints you got. Time and money, features,
| accuracy, speed, waste, etc.
|
| Where is the difference with software? You get the same kind of
| constraints and need to build something from libraries and custom
| code, that fits all of them.
|
| There may be more constraints for a skyscraper than a small
| garage, and there are more constraints for airplane software than
| a website. You can't write flight controllers in javascript, the
| same way you cannot build your airplane out of toilet paper.
| There are also more constraints for airplane software than for
| your backyard garage. It only depends on the regulations in the
| field. Most of the times software doesn't have the potential to
| harm people, like houses and bridges have. So you have less
| regulations.
|
| If you want to build a bicycle, there is no right solution
| either. You could benchmark it by weight, like you could
| benchmark software by memory usage.
|
| Most engineering products only rely on best practice and the way
| the company does it since years, from experience. There is no
| "right" solution, neither in civil-, nor in software-, nor in
| engineering in general.
___________________________________________________________________
(page generated 2021-09-30 23:01 UTC)