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

  1. I've been really struggling with this in DevOps for a long time - everywhere I go, I end up on a "team" of individuals, working on disparate work streams, with very little day-to-day collaboration. Sure, for simple admin stuff, this is fine, but when you have to do something complex / implement something new, I often need to spend much longer on knowledge transfer (partly because of the junior nature of my colleagues). This is something I'm going to take a much harder line on as I think it really would be a Silver Bullet for so much; in the DevOps context, this would mean more like one person doing, the other documenting, which is at least a line I can try to placate the bean-counters...
    19
  2. I have some experience with low code development with one of the large (largest?) low code platforms, in a legal context. The best summary I have, I credit to a colleague: "It's great for rapid prototyping." From my perspective, it was just like any other tool in engineering: you end up replacing one problem with another; you're shifting the complexity around, rather than fundamentally reducing it. Biggest problems we had was around architecture and lifecycle management. Unlike (usually) .NET or Java (or dynamically linked C/C++), when the platform needed updating, the application needed to be rebuilt - and therefore retested. There were also architecture problems - because the app had been developed by non-programmers, they didn't have the understanding/appreciation/experience of how GOD AWFUL ORMs can be and the dangers of accidentally slurping vast quantities of data over the network. There were also other issues - bugs that couldn't be diagnosed and corrected by someone who understood lower-level HTTP/HTML and Java (yes, me... And I loathe Java 😂) Another MAJOR downside was the cost - the infrastructure was EXPENSIVE, plus we had lawyers writing software... Essentially, we ended up with untestable, poorly functioning software, written by amateurs that was extremely expensive to develop and run... And a bloody nightmare to maintain! It was great for the lawyers, because they had the sense of involvement, control and progress (all the things lawyers are predisposed to), but the cost of delivery was insane - it would have been FAR cheaper to employ a couple of good/experienced devs full-time and use cheaper infrastructure (even public cloud...) Like I said, it would be good for prototyping: let the lawyers sketch-out something that kinda does what they want, but then had it over to experienced devs to "build properly".
    16
  3. It also focusses your attention on the most important part of the design - how easy it is to use the API. Having to write tests first forces you to EYOD (Eat Your Own Dog food).
    13
  4. I find the contrary - the worse the code (the more I need to hold in my head at once...) - the more beneficial pair-programming is as you can share that burden and you have someone to validate what your thinking.
    11
  5. "Real Agile has never been tried." Well, at least in any place I've ever worked 🤣
    9
  6.  @dinadanalcedines628  My experience is that all too often people without genuine understanding of the software development process (what one would call a genuine "software engineer") end up in charge. These "management types" are immune to concepts such as "measure twice, cut once", "spending three weeks setting-up proper, reliable, CI/CD pipelines and processes will save time going forwards" and "unit testing development faster in the long-term as it makes debugging easier". (There will ALWAYS be bugs...)
    5
  7. Well, when you've had an entire system grind to a halt because a single space was in the wrong place, I call "perfectionism" being "good at my job"...
    5
  8. There are two states in which we should be operating: 1. Complete trust, so there's no need for pull requests. 2. Building trust, so we should be working very closely together to ensure we're learning each other's strength and weaknesses: i.e. pair programming. If you think about it, pull requests don't make a lot is sense, except for open source.
    5
  9.  @skylark.kraken  Notwithstanding that every working copy is a branch, every commit a merge... less experienced developers will more often mess up and take longer to complete complex merges... There are secondary benefits to the frequent integration approach - protection against device failure and interruptions, for example. I think the point here is less in the branching itself and more in totality of the approach; small changes, backed by automated tests... Smaller changes means less to go wrong / less to fix if there's a problem...
    4
  10.  @cugamer8862  "Hundreds of feature flags," is a straw-man that demonstrates you did not understand (or maybe even watch) the approach proffered. No test is extraneous - if you mean feature flag checks, if they're extraneous, you have written bad (redundant) code and should be better. If you mean unit tests or the like, why are you writing tests that you don't need? That's on you buddy. Your response implies that you believe feature flags are inherently bad. Feature flags are incredibly useful, but, like anything, they can degenerate if not managed appropriately. I've been in at least 2 environments where feature flags were integral to the development and deployment process. The two that jump-out were "big" companies.
    4
  11. You actually write code 8 hours a day? Where's your thinking and design time? "Talking in your ear" sounds like you don't like the people you work with, more than you don't like pair programming...
    4
  12. Dave is right in that TDD forces one to think of the problem differently. This isn't a problem for me, because I don't mind learning every last detail of the systems and tools I'm using. Most devs aren't like me. They want to write software and learn as little as possible about things like operating systems as possible. This isn't the dunk it sounds like - my obsessing can get in the way of delivery - I'm just describing why TDD works for me and how I am different from other devs I've worked with.
    4
  13. They needed complex merge strategies because of poor architecture?
    3
  14. I'm okay with branches or no branches... As long as anyone who says "let's use Gitflow" has their keyboard and/or fingers removed 🤣
    3
  15.  @grigoriypiskun6091  Forking is for public projects. In a business context, Forking is ALWAYS the wrong thing.
    3
  16.  @ModernSoftwareEngineeringYT  "The user is always wrong." I get really... irritated... when devs shirk their responsibilities for some aspect of the software development process. We're supposed to be the experts, so if we didn't guide/check, then how can we be surprised when we "don't get what we need"? I think the OP's response is the same you get when devs make excuses for not doing TDD "I'm here to write code, not tests"; it stems from poor education - mis-framing of the job. The job of a developer (or "software engineer") is to "deliver, as efficiently as possible, working software that meets the user's needs", but too many developers ("coders") see their job as "writing code" - I particularly liked your breakdown that showed devs are entirely or jointly responsible for each aspect of the software development process. This is no different to the role of doctors in medicine - the role of the doctor is to ensure patients receive the correct care. Doctors can't blame nurses for "failing to give the right medicine" if the doctor didn't specify it correctly; they can't blame nurses for the patient dying if the doctor never checked that the patient was receiving the correct care. The answer to me seems to be to beat this view into junior devs as early as possible, ideally pre-university. Of course, we still have the problem of too many "software managers" who don't understand what software development actually involves, but, one problem at a time... 😁
    3
  17. In software, there's nothing as permanent as a temporary solution. I deliberately use the words "hack" and "bodge" to make people uncomfortable when they ask me to do this.
    3
  18. Inclusion isn't always good. Anyone who has to use SQL and understands the development history of the language knows that inclusion can be a bad thing... Not anti-women, anti-blindly applying an idea.
    3
  19. ​ @RU-qv3jl  Ah... The mythical "surely someone, somewhere is doing it right". I too have never encountered one of these unicorns 😂😭😭😭
    3
  20. "Whitespace indentation" What, something that every professional developer worth his salt does as a matter of course? Are you serious? Coming from C, the asymmetry (no closing braces) took me about 2 weeks to get over, so I have sympathy for those who struggle with this, but my god! Complaining about indentation? Have you ever worked with other programmers?!?! Static typing can be useful, but this argument is a crutch for poor documentation and communication between teams. Also, if module boundaries are pain points, then simply treat arguments as "user input" and act accordingly. Even when you have static typing, you still need null reference checks and complex inputs will need validating anyway, regardless of typing, so, where's the difference?
    3
  21. Software development is a collaborative exercise. No individual can effectively produce and maintain software of meaningful complexity.
    3
  22.  @TARJohnson1979  With Tom on this. History only tells you how you got here, not how to go forwards (though, it may offer hints). People put too much stock in "history". I've had devs reject things like whitespace/line ending normalisation because it "breaks the history". Their logic being "we should perpetuate BAD, unreadable code, for the sake of history". (Also, let me introduce you to the diff option that ignores whitespace differences...) Ironically, the argument being put forward is both "history is important" and "history isn't important"; you want a *good*, "clean" history, but you ALSO think squash commits - that erase history - are a GoodThing™. My sense is that, in practice, there are 2 things that really matter: diffs between points-in-time (one of the few strengths of Clear Case IIRC) and blame... Sorry "annotation". In short, I think people worry too much about this aspect of VCS. Write your code, make sensible commit comments and let the weirdos (like me) sweat over the minutiae of VCS management 😂
    2
  23. Right, okay, I see. I replied to OP about his support for GitFlow, because branching is a way to handle merge conflicts. When you replied to my generalisation, that constant merge issues indicates poor architecture, I missed that it was a "there's no blanket rules" (which I'd taken as self-evident/had said already - maybe on a different thread, so... I plead "Senior Moment" 😅) Because I just assumed high level of participants, I assumed me saying "there's exception to different rules...
    2
  24. ​ @MikeStock88  Scrum works in its own terms. It's just that no one does it properly... which probably indicates that it's flawed - "not real Socialism", etc. I believe Scrum tries to solve a problem at the wrong level of abstraction.
    2
  25. Ah... The old "Cascading hydric acid" approach we all know so well!
    2
  26. AKA "Requirements Churn". When you know what you're implementing, it's generally straightforward, but when you have to guess or continually change direction...
    2
  27. This is very true. This is why so many older devs just start working for themselves...
    2
  28. Is your boss a software engineer or a "software manager"? My guess would be the latter. (Though, not all "software engineers" seem able to comprehend the value of TDD...) This is an endemic problem in the industry, sadly, as it's really difficult to get someone to understand the value of things like TDD if they've never had to fix code someone else wrote. (One of the most overlooked benefits of unit testing/TDD is that when you have some it makes identify and verifying bug fixes much quicker...) If you don't get a positive response, I'd recommend not over-egging, just try to do your best to implement best practice in the tasks you're given. This can be extremely tricky, so you may need to compromise until you've got enough experience to move-on. One thing is for certain: in your next interview, ask if they do TDD. If the answer is "no", then your answer should be "thanks, but no thanks" - because you'll only be dissatisfied in the role anyway. This is the hardest thing to do when you're starting out, but trust me, the people you WANT to work for are the people who will appreciate that question/response.
    2
  29.  @Zacpowerr  Good plan. Look at it as an opportunity to practice the art of persuasion - asking questions is a good starting point 😉
    2
  30. I'd say that's a cope from the school of "I'm god's gift to software". The biggest benefit of having some unit tests, even if coverage is poor, is that it makes bug find/fix much easier. It's also known that the most bugs appear in the least tested code... Infrastructure code testing is tricky, as it's inherently difficult to unit test. The only answer I'm aware of is to ensure that you adhere to the DevOps (sorry Dave 😉) principle of having minimal variance between environments. This is always tricky because people don't want to pay the costs of fully-duplicated environments, but that's what TF etc. are for - to enable you to stand-up and throw-away test environments "rapidly" and to maintain consistency between them.
    2
  31.  @ModernSoftwareEngineeringYT  Management pressure / lack of management support from people who've never written a line of code in their lives... And lack of leadership from experienced engineers. I've worked with people whose attitude is literally "I don't need to do TDD because I don't write code with bugs in it"... For myself, I literally did some TDD at Uni and was explicitly told that the lecturer wasn't interested in my tests!
    2
  32.  @Bradstephens11  I don't know if it's got any better, but the initial "major release every 3 months" is an indication of weaknesses in their SE processes - the principal of "always have working code" isn't just a nice-to-have, it's essential to delivering efficiently. It's far quicker and easier to debug something the day after you wrote it than 6 months later...
    2
  33. ​ @kbssanik  No clickbait for me. I already came to this conclusion: NFR is an unhelpful term. Cross-functional would be better, but I don't think there's any meaningful distinction. The system must do what it must do, trying to split "requirements" into categories is just a distraction.
    2
  34. Node / npm is the pathological/degenerate case of "software reuse". Devs NEVER vet their dependencies properly. They JustAssumeItsGood™ and move on. FAR too many devs treat OSS as free from everything - ESPECIALLY responsibility.
    1
  35. Yeah, I looked at Gitflow when it was new and it was OBVIOUS to me - as a nearly fresh graduate - that it was overly complex and would result in more effort to manage than KISSing it... Gitflow is antithetical to CICD, I'm completely with Dave. Gitflow - or something like it - can be appropriate, but only as a stepping-stone to doing things better. Managers like Gitflow, because "it's a thing with a name", but since when did managers actually understand version control?
    1
  36. If you have large amounts of merge conflicts, then you have an architectural problem. Fix the problem, instead of applying a sticking plaster to it. (Dave has already done a vid discussing this...)
    1
  37.  @dafyddrees2287  Refactoring large amounts of code to implement a new feature sounds like an architectural change... So it's an architectural problem being fixed. How often do you rename classes? This is not about "things you do occasionally" - there's exceptions to every rule - it's about your default working patterns and why you follow them.
    1
  38.  @Stierguy1  Refactoring is: changing the implementation without impacting functionality - or to quote Fowler: "Improving the Design of Existing Code" Refactoring may impact performance (hopefully for the better), but usually, it's about code structure. If, in the context of software, "architecture" isn't analogous to "code structure" and "design", then I guess I really don't know anything about the meaning of words in the English language... While I'm all for shitposting and trolling for shits 'n' giggles (this I what "social" media is for...), I don't think it's fair to Dave to drag-down the quality of conversation on his channel. And before you continue your childish semantic game, what do you call it when you sit down with code and do NOTHING but a sequence of individual refactors (an extract method here, a collapse hierarchy there)? I would call that "Refactoring". If that results in a different architecture, well...
    1
  39.  @dafyddrees2287  If it's changing lots of files, I wouldn't call that "trivial"... Maybe if you have a good IDE... But even then, if you've got a class that EVERYTHING is touching, then that sounds like a smell to me... And if it IS just a "trivial" name change, then when people pull-before-push, their merge will be trivial, so there is no need to worry about this scenario. Unless we have wildly differing definitions of the word "trivial"?
    1
  40.  @dafyddrees2287  So, you're against GitFlow then? So, what are we arguing about?
    1
  41.  @dafyddrees2287  🤣 I read about GitFlow in 2011 and I rejected it immediately as being contrived. I'd already seen many truly degenerate uses of VCS, so had taken an interest... I was already looking at things in a more abstract way; GitFlow is JUST a (yet another, degenerate) branching strategy - one you could implement in any VCS... and with that frame in mind, it's BAD, because a good strategy is independent of the tooling (they are all, fundamentally, the same...) and this would be bad no matter what VCS you used... I don't know how the confusion happened - will need to revisit this on my PC to do the analysis (but probably my fault 🤦🏻‍♂️)... There's a reason I HATE computers and prefer face-to-face interaction. Yes, it is ironic, given the business I'm in, but I'm still a pen-and-paper kinda guy...
    1
  42.  @dafyddrees2287  🤣 Yep. Sounds right - no doubt you've been in those meetings, where you talk about the minutiae of VCS and branching and merging strategies??? But hey, we can't have those filthy programmer types working their "own" way that's highly efficient - they'll make us look bad!
    1
  43.  @johnmaier3141  No, simple dignity and self-respect...
    1
  44. If you listen carefully, this is precisely what she's asking for when she's talking about "mentorship vs sponsorship". I'm not sure she understands this though... So much politically loaded language in what she was saying.
    1
  45. Interesting. What you call "contextless bias", I consider "common sense". I dismissed Gitflow as soon as I saw it because I thought about it for about 30 minutes and saw how unnecessarily complex it was and how it just compensates for issues elsewhere in the development process.
    1
  46. ​   These are the people who, typically, are a hindrance, rather than a benefit. Software Dev is NOT a job, it's a career. If you're not in it for the long-haul, do something else.
    1
  47. ​ @adambickford8720  🤣🤣🤣 As a DevOps/Platform Engineer, this is both hysterical and deeply painful at the same time. 🫡
    1
  48. ​ @ContinuousDelivery  What this exposes is the naive/willfully ignorant/wishful take that "professionals are responsible for their own development". The reality is that you have to understand what's going on in order to be able to troubleshoot. An example of this is a software solution I inherited that did not work. This was because the external website had a malformed certificate chain and our perimeter security device was using strict enforcement, but just dropped the connection without appropriate feedback. I was only able to work this out because I understood every step of the process (I filled what gaps I had by consulting specialists), which I could only do because I'd done a good computer science degree, so had the prerequisite knowledge to be able to string it all together (and yes, it was I who worked it out, not any of the network specialists). In a world where good CS degrees are rare and 90%+ of people working in tech don't have even a bad CS degree, the idea that companies can build sustainable businesses without taking responsibility for training and developing their staff is just laughable. OP says it's too expensive, but I say the cost of not doing so is far higher. From my perspective, it is infinitely frustrating to be working with intelligent and capable people who could be so much more, if only "management types" understood the value of education and training.
    1
  49. ​ @berkes  This is a quality/project management issue, not a language one. Static typing comes with its own problems, for example, when people require Path objects instead of permitting strings. Something that is trivial to handle, but, y'know "static typing" 🤷‍♂️ Clearly documented interfaces don't have these problems. Interfaces that don't trust user input don't have these problem. Static Typing is useful and I'd rather live in a world with than without, but having static typing vs. not is rarely/ever going to be the "make or break" of a project - it's only a symptom.
    1
  50. If you think refactoring is slower than starting from scratch, I would point you to Perl 6... The philosophical leap here is understanding this choice: 1. Make sure every change works before moving on to the next. 2. Make a whole host of changes, then spend time working out why it's broken. CICD + TDD + refactoring is about choosing option 1. If you are maintaining the external behaviour, then you want to keep running against your existing test suites (or probably improving them as you go). If a change meets all the criteria, then why shouldn't you merge it back at the earliest opportunity? As to what process... Rewriting a whole module is rare, so treat it as an exception; just use branches as necessary with whatever quality gates your team feels is appropriate.
    1