Comments by "Traveller" (@traveller23e) on "Continuous Delivery" channel.

To be honest I now try to minimise abstraction for the sake of abstraction. If a piece of your logic is naturally separate absolutely put it in a separate class, but that class probably doesn't need an interface and factory/manager classes to initialise it.
8
Also even if they did always produce valid code it would be essentially equivalent to constantly taking the first result on stack overflow. It might _work_, but you're likely to be misusing libraries and leaking memory all over the place.
7
@puntoycoma47 Basically a clever algorithm in the IDE (either integrated or provided by a separate engine via some plugin system) that looks at the code and detects some set of errors and warnings. The limitation is that the algorithm is only as clever as the amount of effort put into creating it and can be limited by language design, so for example a lot of them have poor or nonexistant null-dereference checks, but they do tend to be good at finding obvious issues as well as (usually) figuring out whether or not the program will even compile.
7
fast code is what led the PR I'm reviewing to be stuck in the open stage for months as the dev responsible went from hastily patching one critical bug to the next after a poorly managed piece of development leading into a premature golive.
5
IMO if you don't both have behavioural specs and a performance target and accurate calculations or tests to see if you're within it, you're not engineering. I don't mean unit tests necessarily, it could just be a test suite you run on the final product but at any rate they certainly should be run in the predetermined production environment.
3
A problem I've seen recurring in the projects I've worked in is business logic has not been very clearly defined/recorded. When reading code it's nice to be able to tell if some value or check was a business decision or a (possibly no longer needed) technical solution to some problem. It may be fine when the code was written last week and you can ask the guy from business, but when you're debating rewriting a complex mess it's a real issue.
2
In the case of Tesla and similar, the answer seems to be "the dude sitting behind the wheel not paying attention because all the promotional material said 'self-driving'".
2
Do you have any advice for how to handle colleagues who write unneeded interfaces and other boilerplate and defend it with "it's needed to maintain separation of concerns and is good clean code"? I used to have a colleague who did this all the time, but I'm fairly junior and probably ten years younger than him and perhaps because of that he never had much time for my arguments that in the monolithic architecture having exactly one class of that interface didn't really make sense when there weren't any externalities to mock away. Maybe I've misunderstood something fundamental about unit testing (sadly I've never been in a project that put much focus on it) but as I see it with a modern IDE replacing all calls of an internal class with an interface is really trivial so no need to plan ahead for that eventuality, and there were frequent cases where adding a method to a class really meant adding passthrough methods to two interfaces and the corresponding classes.
2
@aSfuLk To be fair to juniors, it can be pretty dang hard to tell. I recently had someone ask me what I thought my level was and I genuinely didn't know what to say...if you look at job postings a lot of "mid-senior" postings require 3-5 years of experience and "senior" postings are frequently requiring 5 years or so. Doesn't seem like a very sensible division in the context of a career totalling around half a century long.
2
@TheRealWindlePoons Though depending how much they trusted the system, the explanation they came up with might just have been that they hadn't noticed before without the high-tech solution.
1
@davidmartensson273 VS's "TAB to insert xyz" feature is horrendous, you never know what TAB is going to do the next time you hit it.
1
@BigWhoopZH Take a look at NixOS for instance
1
For some roles this is 100% the right thing to do. Unfortunately in my company I frequently have to write drivers with no proper spec, just a "protocol" file which is a "trust me bro" level of commitment that all parties totally looked over or at least vaguely discussed the contents. We never know if the thing works until golive, when the client is expecting it to just turn on. We sometimes are able to do a test with a PLC but the PLC in question is essentially just a perfect simulation of what the machine would do if it were powered on but on standby/idle/inactive mode.
1
@leesoftwareengineer If it makes sense to separate the concerns architecturally than maybe, however when you have a class fundamentally linked to the place it is used it is unlikely you'll have multiple devs working on that same section of code at once (if they are, maybe a pair programming approach would be better). An interface only makes architectural sense if there are multiple fundamentally independent implementations. As for practical considerations, popular testing frameworks at present do require interfaces for mocking, though it may not be strictly necessary (I've considered writing one that didn't but haven't gotten around to it). This however only requires classes that need to be mocked, for which there are two potential reasons: firstly you may have external dependencies (e.g. user input, DB query...) but you could also have a situation where you are trying to unit test a separate piece of code and don't want to wait on a long-running algorithm when you know what it will output. In both cases it normally would make sense to isolate the problematic piece from the thing you actually want to test, but that doesn't mean that you should create an ISomeInternalModel interface out of instinct.
1
@DaverSomethingSomething That just sounds like project management imo
1
 @Mnementh-ub8md Tech is evolving, yet many times the latest and greatest is just a rehash of old technologies and patterns.
1
As I see it there's a strong connection to the airline industry. When an airliner goes down or anything serious happens, there's always an investigation and a final report, many of which find that new safety features need to be introduced. The pilots are almost never blamed, and even when they should have done something differently the report will contain a recommendation about increased training or the like. If we really care about software working properly, we need to have a similar framework with mandatory test procedures, documentation, and the like proving to some "critical software system safety board" that our software works. We could also have licences and special training programs required for devs working on such systems. Naturally this isn't necessarily a good thing for all programs. When I play a dumb flash game in the browser I don't expect it to work perfectly, but for large systems backing bureaucratic processes it would go a long way towards guaranteeing better results albeit at a high price.
1
@JelMain Lol you remind me of a former manager of mine. A lot of software these days don't replace manual work, at least not work that's been done manually sometime in the last 50 years, so knowing the job "the old way" before designing a system isn't always a feasible methodology. Right now I'm in a project building a system that was outsourced in part because the business people up top don't know how to program and/or don't have a grasp of all their business rules. And knowing how to use the software we produce would be virtually useless as the general procedure is "click the button and wait for the magic to happen". Programming is not all coding. And there's a reason programmer is a job description in and of itself.
1