Comments by "Edward Cullen" (@edwardcullen1739) on "Continuous Delivery" channel.

This is why anyone ever says "we're not writing flight control software", I struggle not to lose my isht. You never know what the indirect consequences of a failure can be. Must be professional at all times.
1
Sounds like another day ending in y in the software biz 🤷‍♂️
1
@Altovch Surely, the issue then becomes one of architecture and unit sizes? The kind of thing that component-based and micro-service designs look to solve (though, I'm speaking completely generally as I totally appreciate that not every problem is suitable for micro-services)... Again, in general, chances are that there are parts of a system that are very stable so make good candidates for carving out to minimise the amount of rebuild and retest... Of course, this adds complexity to the build/CI process but then hey! Gotta give your DevOps something to do 😉
1
@username7763 These are hypothetical concerns: Python isn't a language for high performance, plus, most prigrammers can't write performant, thread-safe code anyway. And if you think the Python GIL is bad, have you ever looked at the Perl 5 way? Granted, haven't touched Perl in anger for 10 years (for a reason...) But my God! Talk about braindamaged! Dynamic typing is a feature, not a bug. When you understand how it works and how you can use it to your advantage, you would be less down on it.
1
@username7763 Most tasks are I/O bound and Python takes advantage of async I/O in the background where it can (both on Windows and Linux), so??? Again, you're talking about a specific problem that nobody pretends isn't an issue, except it actually isn't an issue, because you can bind a C library to do the hard work for you.
1
Wow, what a radical concept! Surely no one already came up with this idea - say 20 years ago - because if they had, "the QA team" would be a thing of the past, right?
1
This, so much, this!
1
Hi, I came to the same conclusion about a year ago, but have real problems expressing myself. NFRs are a hangover from the early days of Software Engineering, which was copied by academics from other fields of engineering. As we're maturing as a discipline, this kind of thing is becoming clearer. Everything that the system must do is a requirement. There are no distinctions beyond this. I split it into standards and requirements. Standards are the things that cut across and inform requirements, but don't necessarily directly translate into 1:1 into requirements. I'd love to talk to you about NATIVE.
1
@jimmyhirr5773 Hey, can't expect me to give the game away 😉
1
Couple of things: "Python is the second best language for any project." BDFL has stated "if you're worried about performance, why are you using Python?" In this sense, Python should be used for prototyping, to understand the problem and work out how to solve it correctly. Once you have a correct solution, translating that to a performant language is trivial in comparison (plus, you have a reference implementation to test against). Given we rarely get it right first time ("Plan to Throw One Away"), the only "performance" that matters, is getting to a correct solution. Not strictly a Python issue, but comments in code are just like unittests: done right, with the right intent, they are GoodThing™ and should be encouraged. Good comments give a different view of the code. I've had many people say "you don't need comments or documentation when you have the code", but if I just want to use your code, why should I be forced to spend my time delving into your code? (which may or may not be a pleasant experience in and of itself...) Documentation forms part of the user interface. If there is a numerical argument, I should not need to read beyond the doc comment to know what the acceptable range is. People make the argument that "comments don't get updated". I consider this a feature, not a bug. When there's a mismatch between stated intent in a comment and what the code does, then something, somewhere has gone wrong, potentially seriously so, therefore questions need to be asked. (And Mk1 re-education devices applied... 😉)
1
Sorry, but this just comes across as semantic jibberish. You know that the the original description of Waterfall was a critique, right? You also fundamentally misunderstand Agile. Agile is not the absence of specification, it's the development of specification closer to the time they will be implemented; when you're doing Agile, you should still have thorough requirements specification for the features you've implemented/are implementing, you just do them together. This differs from Waterfall, in that: 1. Doing waterfall implies up-front analysis of a problem in a changing world, where the time between analysis and implementation can be years. This leads to the problem of requirements churn, where "management" keep changing their minds as the (perceived) needs of the organisation change. 2. Developing the requirements and implementation in the light of what actually exists, rather that what "will". This works from both the business and technical perspective. You get a new requirement that requires fundamental re-design? If you've been Agile, you'll have implemented only what you needed up to that point and so the "loss" is minimal. SSADM/Waterfall is NO protection/guarantee against such technical redesign requirements. In fact, it was the frequency of these fundamental re-designs in Waterfall projects that contributed to the birth of Agile in the first place!
1
@roach1628 So does telling young girls that "if they go into STEM, they'll face a wall of misogyny and discrimination." Truth is, there is no more (and probably less) misogyny in STEM than in other workplaces. People like you - attitudes like yours - are the problem, not the solution.
1
1. If it's not automated, it isn't a test, it's an evaluation. 2. This sounds like a "I'm not paid to write tests" cope. If a test is a test, it is specific and repeatable - it has a pass/fail criteria. If it's specific and repeatable and runs on a computer, it can be automated. Automated could mean frame-by-frame comparison of a run (a mate worked on a game where they did just that 15 years ago!) But there's LOTS of things that can be automated - take Cyberpunk 2077 - the perks system is notorious for STILL being about 20% completely broken 6 months after release. These perks apply modifiers in specific circumstances. How hard would it be to write a test in-engine that spawned a player with a perk/combination of perks and a corresponding "gallery" of targets that then used an aimbot to attack them? After each attack, you inspect the target and player and ensure that the internal values are correct. Sure, this doesn't cover graphics BUT THAT'S THE POINT. You're automating the "mundane" parts of the game play so that human testers can focus on the parts of the game that can't be automated (too impractical) or don't have pass/fail criteria, like "does this feel good". This is a guess, but I bet Star Citizen's release cycle is almost certainly due to the lack of good test automation.
1
My recruitment motto is: "Computers don't care about your gender or melanin levels, so neither do I." Apparently, this makes me sexist and racist 🤷‍♂️
1
 @vitalyl1327 Whenever someone has written unit tests, I find it easier to debug their code. I am a fan of UTs 🤷‍♂️
1
@georgeonearth I guess you've never experienced a merge conflict then?
1
@BittermanAndy The friction for me has always been with management who fail to see that Agile is more than a software delivery approach. That is, Agile affects the whole business.
1
@BittermanAndy All part of the challenge 😁😉
1
I've long seen DevOps as a smart marketing term to backdoor the concept of Software Engineering, without actually using the words. Software Engineering, as a term, seems to be a massive turn-off to management types...
1