13 ms·
Are software engineering “best practices” just developer preferences?
- glanzwulf 5y agoI get your friend, and there's another point he can make: Imagine a world with self taught Civil Engineers.
- lanstin 5y agoOh yeah the last bridge collapsed, but that is a known issue. It is fixed in this bridge, trust me.
- walshemj 5y agoBlame 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 5y agoCan you tell us more? This sounds oddly fascinating.
- pdpi 5y agoThat’s sort of the Tacoma Narrows Bridge story.
- rajin444 5y agoTo make the comparison fair, in that world civil engineers would also have the ability to change the laws of physics.
- BiteCode_dev 5y agoAnd the bridge collapsing would usually not kill people but strip all their clothes. Also you can start a bridge in your garage.
- dntrkv 5y agoOr 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 5y agoYeah, 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 5y agoPretty 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 5y ago>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.
- BiteCode_dev 5y agoWhich was left in the hands of a small elite from the beginning. I don't think reddit could have been born that way :)
- dntrkv 5y agoIt’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 5y agoPretty 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.
- dtech 5y agonuclear 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.
- fitzn 5y agoSteven 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.
- dr-detroit 5y agoUndergrad CS profs are teaching everyone that theres "Nothing new under the sun."
- habitue 5y agoEh, 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_ 5y ago> 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.
- oweiler 5y agoHaving 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.
- josteink 5y ago> 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 5y agoI 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.
- BadOakOx 5y agoHaving 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 5y agoInterfaces 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.
- rvr_ 5y agoI 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.
- SideburnsOfDoom 5y ago> 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.
- deleted 5y ago[deleted]
- josteink 5y agoIt’s best practice to apply best practices when it makes sense. The catch? Knowing when it makes sense requires experience ;)
- wisienkas 5y agoTo 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.
- Hamuko 5y agoAre civil engineering "best practices" just legal preferences?
- NikolaeVarius 5y agoThey are built on top of a ocean of blood
- loloquwowndueo 5y agoIt’s called “building code”.
- shagie 5y agoOne 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-policy-analysis/book255357 https://us.sagepub.com/en-us/nam/a-practical-guide-for-polic... ) and https://en.wikipedia.org/wiki/Eightfold_path_(policy_analysis) 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."
- nine_zeros 5y agoA 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 5y agoI 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 5y agoWe'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 5y agoGive it a couple years, it'll come back around!
- mytailorisrich 5y agoThe 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 5y agoSoftware 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 5y agoSure, 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.
- sprafa 5y agoIt’s a difficult question and I’m not qualified to answer it as an amateur tbh.
- postalrat 5y agoBest practices create a shared experience that can help get you out of trouble when that practice was a bad decision.
- mywittyname 5y ago> 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 5y agoNot 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 5y agoThe 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-code/ https://ethics.acm.org/code-of-ethics/software-engineering-c... [1] https://en.wikipedia.org/wiki/ISO/IEC_JTC_1/SC_7 https://en.wikipedia.org/wiki/ISO/IEC_JTC_1/SC_7 [2] https://www.computer.org/education/bodies-of-knowledge/software-engineering https://www.computer.org/education/bodies-of-knowledge/softw...
- floverfelt 5y agoI 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 5y agoFair enough! Thank you for posting the article and getting this discussion going, by the way.
- gedy 5y agoI'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.
- hyperman1 5y agoThere 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 5y ago100% 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 5y agoDoesn'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 5y agoI'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 5y agoFrom 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.
- PedroBatista 5y agoYes 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 5y agoThe 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 5y agoSerious 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. ]
- lgeorget 5y agoIn 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 5y agoYeah, I told him that, but by and large most developers don't work on those problems.
- stillbourne 5y agoRight 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 5y agoThat 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.
- gedy 5y ago> 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 5y agoThere 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 5y agoExactly, it would've made total sense to pull it out into an interface in other situations, but simply felt like a preference here.
- elboru 5y agoRight, 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 5y ago> 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 5y agoYup, 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 5y ago> 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.)
- surement 5y agoI can't imagine someone arguing that avoiding tight coupling is a personal preference.
- KronisLV 5y agoI 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.
- deleted 5y ago[deleted]
- KronisLV 5y ago> 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.
- mbrodersen 5y agoI think you will find that there is a large set of ways to solve the same problem equally well. So arguing about the best way to solve the problem is a waste of time.
- KronisLV 5y agoIn many cases this is only because of unnecessary duplication of languages and frameworks. People wonder about whether they should create their back end in Ruby or PHP. People wonder about whether they should create their front end in Angular or React. People wonder about whether they should use MySQL or PostgreSQL for persistence. They wonder about which of the many OS distributions they should use for hosting their application. But perhaps that's the true waste of time - maybe we shouldn't need multiple approaches to each problem. Maybe we'd only need one, which could then be the sole focus of the industry. The tooling would be incredible if there would be just one workflow to support. The technologies would be tightly integrated, since that's where all of the effort would go. And there could be models built around the language and frameworks to such a level that any usages of antipatterns could be immediately identified and even fixed automatically. If you ask me, the millions of man-hours that have been spent on creating a brittle and fragmented landscape of tools that don't work well and make developer's knowledge obsolete in a few years while also urging people to do CV driven development are the real waste of time. Of course, that's the reality that we live in but maybe for the developers in 500-1000 years it won't be that way.
- russtrotter 5y agoThere'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.
- trav4225 5y agoI'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".
- strulovich 5y agoAll 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 5y agoDid 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.
- dmalik 5y ago> 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-software-becomes-a-work-of-engineering https://engineerscanada.ca/news-and-events/news/when-softwar...
- gr__or 5y agoThe wonderful Hillel Wayne has two great essays on the "Engineer"ing question: https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/we-are-not-special/ https://www.hillelwayne.com/post/we-are-not-special/
- agentultra 5y agoIt'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 5y agoMicrosoft lost their appeal in Quebec https://www.oiq.qc.ca/en/media/pressReleases/Pages/default.aspx?communiqueid=18 https://www.oiq.qc.ca/en/media/pressReleases/Pages/default.a...
- bdavisx 5y agoIIRC, 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.
- pjmlp 5y ago> 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.
- thereddaikon 5y ago"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 5y agoIn 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 5y agoWhile 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.
- agentultra 5y agoIn 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_Knowledge https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K...
- strken 5y agoAren'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.
- alistairSH 5y agoI'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.
- Smeevy 5y agoI 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 5y agoThis 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 5y ago"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.
- overgard 5y agoEngineering 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.
- jakevoytko 5y agoDevelopers 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.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... [1] https://www.martinfowler.com/bliki/FunctionLength.html https://www.martinfowler.com/bliki/FunctionLength.html
- alvis 5y agoSome 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 5y agoRight, 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."
- catern 5y agoAfter 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 5y agoI 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 5y ago> 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 :)
- gambler 5y agoBest 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.
- alfonsodev 5y agobest practices are programming style convergence, which helps estimating software in my opinion.
- StillBored 5y agoWell 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.
- Kronen 5y ago> 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...
- jasode 5y ago>“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 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 5y agoEven 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)
- RNCTX 5y agoAs 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 5y agoQuestion- if you're using eval() and bleach, won't your security be totally dependent on bleach not having a vulnerability?
- RNCTX 5y agoSure. 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-trend-of-coin-miner-javascript-infection https://www.fortinet.com/blog/threat-research/the-growing-tr... 2. https://www.cvedetails.com/cve/CVE-2002-1227/ https://www.cvedetails.com/cve/CVE-2002-1227/ 3. https://www.cvedetails.com/cve/CVE-2002-0083/ https://www.cvedetails.com/cve/CVE-2002-0083/
- cwp 5y agoEh, 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.
- swixmix 5y agoReminds me of US Generally Accepted Accounting Principles (GAAP). I don't need to be perfect, just consistently good enough.
- RNCTX 5y agoOr Tesla/Uber/etc, in which rules don't apply to you so do whatev
- theptip 5y agoOne 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.
- intrepidhero 5y agoVernor 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.
- JohnFen 5y agoI'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 5y agoit 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.
- JohnFen 5y agoI don't think that it's changed that much over the decades of my career, really. The words used change, but the concepts seem reasonably stable. New batches of commonly accepted practices come into play with new technologies, though, and most of the "hot" technologies today are still so new that the "accepted practices" unique to them have still not settled down. So, yes, in that space, they change rapidly because they don't yet really exist.
- lincpa 5y agoIt'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 https://github.com/linpengcheng/PurefunctionPipelineDataflow
- npteljes 5y ago>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 5y agoAre 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.
- mkl95 5y agoThere 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.
- Sohcahtoa82 5y ago> 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.
- floverfelt 5y agoYeah, 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 5y ago> 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 5y agoGetters 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.
- jleyank 5y agoSkimming 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.
- jmull 5y agoI 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.
- charles_f 5y agoI 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 5y agoSame 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 https://www.cs.cmu.edu/~wing/publications/LiskovWing94.pdf
- charles_f 5y agoSo 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.
- shados 5y agoA 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 5y ago[deleted]
- letwhile 5y agoI 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.
- Jensson 5y agoSoftware 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.
- web007 5y agoShort 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.
- memco 5y agoI 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 https://www.youtube.com/watch?v=WELBnE33dpY
- christkv 5y agoI 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.
- faridelnasire 5y agoIs there really a difference, if more friction for developers == less productivity, less happy developers, and so on?
- snidane 5y ago"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".
- andy_ppp 5y agoMake 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 5y agoLots of small, simple things can add up to a really complex and not very much maintainable result if you are not careful
- andy_ppp 5y agoSo what I think you’re trying to say here is paraphrasing the (apocryphal?) Einstein quote, “as simple as possible and no simpler”. I agree, you need to design the software to be as simple as possible, that might include building some quite complex abstractions but again the net total should be the code ends up overall being simpler.
- gchamonlive 5y agoIn a nutshell. Getting "as simple as possible" right is the art, and many times we can only really know we went too far with oversimplification (or overengineering) in retrospect.
- marsdepinski 5y agoIn your example, read the spring manual. You need the inference to help spring generate proxies for your service class. You could use cglib to remove this requirement but it's the way the spring API has been for ages. Also using an interface let's you easily mock things out and write dummy test implementations. Pretty valuable.
- mobjack 5y agoI read about spring's best practices and think some are unnecessary boilerplate code without any real benefits. I get the theory, but in practice, the benefits are just theoretical. You could reimplement interfaces for your tests, but it is easier just to use a mocking library.
- rajacombinator 5y agoThe phrase “best practice” is a sure fire way to signal “I don’t know what I’m talking about.” A lot of times these best practices are really good ideas. But misapplying them by rote can be more dangerous than ignoring them.
- bmy78 5y agoAs someone who has a liberal arts background, software engineering has a lot more in common with writing than most admit. Sure there is grammar and syntax but good writing can be as varied from William Shakespeare to Stephen King. Same with software writing.
- Zababa 5y agoI feel like at this point, comparaison between software engineers and civil engineers should fall under the "does not gratify intellectual curiosity" category. I haven't seen anything interesting said about this topic since the article series "are we really engineers?" https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/are-we-really-engineers/. > 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. That's a great conclusion.
- deleted 5y ago[deleted]
- poulsbohemian 5y agoThe biggest issue I saw with "best practices" in my career is the failure to take into account who it claiming it to be a best practice, and in what context. I saw too many junior developers read a rando blog article, then get a non-technical / semi-technical manager excited about something that made their life easier, even though it was by no means a good practice for the context at hand. Or alternatively, believe some vendor carte blanche when they tell you their product somehow follows a best practice. The overarching problem is that yes, there is software engineering going on in the world, but most organizations are not willing to do engineering. I don't blame the technical staff - they often have good intentions - but rather the typical business is not willing to pay the cost in time or money to do long-lasting engineering practices. This is one of the things not enough of us think about in our career choices - am I going to a place that practices fire drills or engineering?
- Lich 5y agoSpot on about reading a random blog or article. I think many engineers at work are under pressure to deliver, and are looking for quick solutions. They do a search and see a Medium post related to their problem written by someone who says they are an “<platform> developer at <company>”, and for some reason most readers see these authors as an authority in their domain (because why else would they be writing about it? /s), and just accept the blog post’s practices or conclusions. Once read an article a long time ago about Android’s async task , and some blog post claimed it should only be used for operations less than one second. I looked at the official documentation and while it did mention that it should be used for short operations, no where did it mention it should be less than one second specifically (unless I missed it). I saw the same advice mentioned by many other devs who referenced that same article.
- cptaj 5y agoManagers excited about a new tech idea are probably the most destructive thing in the industry.
- noidesto 5y agoAs are managers that conform to archaic tech when better options exist.
- Iv 5y ago"So what are these rituals for?" "Some are purely ritual, but some are there so that we can guard this dimension from horrors that live within!" "Uh, I guess we should at least do the latter?" "Oh? You can tell the difference? That's great!" -- Girl Genius
- hyperpallium2 5y agoWithout empirical evidence, who knows what they are?
- ChrisMarshallNY 5y agoCodified Software Best Practices have been around for decades. Steve McConnell (Code Complete, Rapid Development, etc.)[0] used to be the Best Practices Editor for the IEEE. It’s just as the author mentioned; no teeth. Companies are happy to pay for slapdash work (thus, undermining the drive to do good work), and employment tests often don’t really have much bearing on real-world engineering. I’ve spent decades refining techniques and habits that I think work quite well. I occasionally write them down[1], which I find helpful in understanding them better. [0] https://stevemcconnell.com/ https://stevemcconnell.com/ [1] https://littlegreenviper.com/miscellany/ https://littlegreenviper.com/miscellany/
- capn_duck 5y agoLots of Java Frameworks (definitely Spring) will generate wrapper classes for your code to handle things like method level authorization, pre/post method logging, Exception transformation. This is generally termed "Aspect Oriented Programming". This is exactly whats going on with Spring's @Service annotation. In order for you to still be able to call your methods even though the class will be some sort of proxy at runtime, an Interface is required. It may seem silly but it all makes perfect sense when you understand whats going on. Edit: Surprised I haven't seen this mentioned in any other comments. I had thought this was pretty common knowledge, at least amongst people with Java experience.
- hernantz 5y agoThere are no solutions, only tradeoffs
- throwawayx5e 5y agoA lot of "best practices" are developers who make code complex in order to attain some level of architectural purity for its own sake. An example of this I recently experienced was trying to understand and debug what should have been a simple integration app, but where a ton of injected commands and queries were used to implement the functionality. Following the logic was painful as the code was completely atomized for no particular reason. Worse, real-world concerns, like proper logging, were ignored. I hate to call this an "autism tax", but perhaps there's something to the term: many intelligent developers, especially left unsupervised, tend to pursue highly abstract solutions, to what should be straightforward problems in order to satisfy a compulsion for order and symmetry.
- scotty79 5y agoPretty much. Just averaged over sufficiently large number of devolpers. And since the developers are the one that the code is read by then it's perfectly reasonable.
- Apps4Life 5y agoThe answer is not binary
- Apps4Life 5y agoThe answer is not binary.
- 29athrowaway 5y agoWhat code would you rather maintain: // A const int giraffe = 1 + 1 + 1 + 1 + 1; // B const int number = 5; At some moment, you will meet some disagreeable person that will say they are the same and it doesn't matter which one you pick. A is similar to Roman numerals. We all know that Roman numerals are no longer used for most purposes and were replaced by the numeral system we currently use. Not only the new numeral system is more convenient for various reasons but it allowed people to advance math further. So A is better than B in that sense. Then, A uses an identifier that doesn't represent its value. We can also say it's bad because of that reason. You can try to seek ways to compare and improve code. Not all of them will be effective, but at least you will be trying. That is better than being that disagreeable, nihilistic guy that thinks that everything is subjective and relative and won't agree with anything you say. You have to learn how to treat your code with respect and prevent it from becoming a tech debt dumpster. There is code that is objectively bad. And you will know when you try to maintain, debug or profile it, or when you have to explain it to someone else. Or when it keeps breaking over and over again and many defects are connected with it. Or when it becomes a product limitation and you have to apologize to customers about it.
- qazpot 5y ago> I was working on a Spring Boot REST API a few months ago and the senior engineer had defined every single service class as an interface and then implemented that interface in an actual @Service. The interfaces weren’t extended by multiple classes, this wasn’t an external library or a dependant, and there were no plans to implement additional classes later. Reason I avoid working in Java and especially the "senior java engineers". > The logic from the senior engineer was that the interface represented the “contract” and the class the business logic. This is basically religious dogma
- wiennat 5y agoI am doing this and it helps in mocking the interface in other classes tests.
- jpatte 5y agoIt doesn't make much sense for people who always heard and thought that "an interface just lists the public methods and properties of a class". In that view the classes always come first and the interfaces are unnecessary boilerplate. However if instead you assume that "a class is just an implementation of an interface", then everything changes. Now the interfaces come first and classes are required to materialize them. In that paradigm objects only communicate with interfaces, never (or almost never) with other classes unless a specific implementation is required. Which is why an interface is always defined for a class even if there is no plan for other implementations of it. Rather than a "contract", think of an interface as the description of a job. If you ever need to write a safety procedure, does it make more sense to write "In case of fire, call John; John happens to know how to extinguish a fire." or "In case of fire, call a fireman."? "Fireman" is an interface. "John" is a class implementing that job. It might be the only class in the codebase that implements it, but that is no concern of the caller. They just want that fire dealt with.
- topkai22 5y agoI had a principal engineer who wouldn’t use the term “best practices”. Instead, he called them “proven practices.” I’ve adopted that term myself, because it is much more accurate- there is a body of knowledge on how to build software well, but it’s a tool kit not an instruction manual. There also really is software engineering that goes on- I work in an org that does extensive analysis, testing, and validation of firmware before it is rolled out. It’s a real thing. That being said, so is cranking out a CRUD web app with zero testing to make our PMs data collection tasks easier. It’s all on a continuum. The key trick for software “engineering” versus just development is knowing where in the continuum a given project needs to be and what tools are appropriate in that context.
- cratermoon 5y agohttps://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
- thanhhaimai 5y agoThere are people on both side arguing that "best practices" are good and bad. But that's not the point. Best practices are necessary. The value of "best practices" rests not on whether it is good. Its value is that there is an enforced standard across a business/organization. The existence of a standard (and recommended way) helps smooth out the execution/operation. In software engineering, that means easier refactoring, easier migration, easier tooling development, easier training, easier for people to move around within an organization instead of moving out... I'd recommend any organization to find, install and periodically improve their "best practices". Just the virtue of their existence is a net positive to the business.
- irjustin 5y agoYes...?? And what's wrong with that? "Best Practices" means - given this problem set, these other engineers have tried a number of ideas and put together a framework, idea, code, whatever that represents a *good enough* solution. There is no such thing as literal best, greatest, perfect. We're all just balancing tradeoffs in the "best" way we can. For teams, consistency is more important than cleverness. If something needs to be "clever" then it is important enough to become consistently used because if the person who built the "clever" thing leaves, it becomes expensive to maintain it. That's what "best practices" are, they are a consistent set methods that enough people have tried them that allows you to "stand on the shoulder of giants" and focus on more critical problems.
- sowbug 5y agoThe best best practices I've heard usually have stories behind them. Someone did or didn't do X, and bad thing Y happened. Therefore we do or don't do X in the hopes of avoiding Y again. The danger is that X keeps happening without the story of Y also being passed along; otherwise it turns into the Five Monkeys problem (https://intersol.ca/news/organizational-culture-and-the-5-monkeys-experiment/ https://intersol.ca/news/organizational-culture-and-the-5-mo...). I'm not disagreeing with the author's friend's point. But at least if there's a story attached to the practice, then it's less of an appeal to authority and more of collective wisdom that can continue to evolve.
- midnightclubbed 5y agoSometimes those historically best practices become outdated but clung onto as doctrine by programmers who let experience get in the way of evolution. What may have been true 10 years ago may no longer be accurate or important but is still held up as a best practice today. If allowed to evolve then we are all good but finding the correct speed of evolution (and helping everyone evolve at a similar speed) is harder than ideal. Flip-side of that is the organization or programmer that blindly chases the new.
- darig 5y agoThe opposite is also true... the "worst practices" or "never do this" are often the best-fit solution.
- sjatkins 5y agoOr lowest common denominator, stuff you want get in trouble for doing, pablum?
- m463 5y agoIt doesn't really matter to me... (as long as tabs stops/indent are 4)
- amrx101 5y agoIf the entire Object Oriented and design patterns and Martin Fowler fan boys could read, they would be very angry.
- steveBK123 5y agoNo, they are management's developer preferences.