General statistics
List of Youtube channels
Youtube commenter search
Distinguished comments
About

Continuous Delivery
comments

Comments by "" (@JinnGuild) on "Continuous Delivery" channel.

I'd want to add to the comment in this video about documentation -- Using TDD, we should absolutely be covering each explicit test case regarding the functionality of our code. Whether we're talking about the TDD a dev does using Unit Testing, or the TDD the team (Or SDETs or Automation QA etc) does with automated integration tests (functional, contract, whatever). Those tests describe exactly what is expected of the code, and those tests MUST CHANGE WHEN THE CODE CHANGES. Tests themselves are a form of documentation. Also, if we link test cases, cucumber, BDD, blah blah back to our User Stories, or Tickets, or other feature documentation, then there is a direct link of how the code is implemented to the feature being requested. Not to say that replaces 100% of code comments or other documentation, but it supports a massive amount of that requirement.
16
I more frequently see novices begging to do practices like TDD, and the "coming from above" is management telling them all of the objections listed in this video.
4
Part of the problem is that there is rarely such a thing as "Agile Scrum". Scrum by definition requires iterations. Iterations are GREAT! But mainly related to the Teamwork portions, the SDLC in general, if you will. Unfortunately, Scrum conflates that with Iterative Releases as well. That is, Release every couple weeks or so. Though that may match the lofty goal of 22 years ago, that does not match the current state of what "Continuous Delivery" means. Also, Scrum requires you to perform an abhorrent amount of planning and analysis. Though I have worked with a single client where they "started with Scrum" and, by 100% definition of Scrum (as I remember it from ScrumMaster training 15 years ago), they altered the process until they were no longer doing Scrum. So at some point a few months after starting, they fell into their own Agile stride, and it was wonderful, and Scrum helped them get there. But what they ended up doing was nothing like you'd see if you researched what Scrum is.
4
I agree. I think the video title may be only a SLIGHT misnomer. Perhaps meaning something like - People abuse the power, cloud, and cult support behind the word "Agile" to sell tools, processes, and possibly to somehow misinterpret it to support their own misconceptions. sAFE is a perfect example, and Scrum is another, though I realize Scrum has been around slightly longer than the Agile manifesto, but I think it just hooked on like a leach.
3
@brandonpearman9218 Long story short, yes, that is exactly what they were saying. And exactly as you mention, "Continuous" back then was LOFTY to imagine every couple weeks or months. That was like imagining a Gigabyte of RAM in the 90's!! But just as we have home machines with tens or hundreds of gigabytes of ram now, we also have redefined "Continuous" to literally mean Continuous. No time frame. Just whenever something is done, it goes! If a team 22 years after the Agile Manifesto was written is literally delivering every few weeks because that was the standard set by the Agile Manifesto, they are obviously a couple decades behind the curve. Similarly, when they talk about Face to Face communication, keep in mind they didn't have Smartphones with 5G video, or Slack. They were still working on paper and using E-Mail. "Face to Face" absolutely includes Emojis and Chat today, though I'm sure we'd all agree it absolutely includes Meet/Zoom/Teams/etc. I am actually disappointed in this video for not pointing these things out more clearly.
3
@Dave - Yes, yes and also yes. I especially want to "Yes" at your @16:53 -- Correct me if I'm wrong, but the pattern you gravitate toward is ISFC (Imperative Shell Functional Core). You refactor to allow for Dependency Injection, then you separate out the "Impure" stuff like hitting external SDKs or Databases, and you isolate the functional pieces to be as "Pure" as possible. Maybe you can't reach perfect ISFC, but that's essentially the direction you go in, would you agree? In my own consulting, I find it valuable to make it clear to people new to Unit-Testing TDD that code resulting from TDD are best observed as something like "Pure" functional methods. When your Unit-Testing TDD is finished, you then wrap the resulting great functional-esque code with an imperative shell that USES your logic, but composes it to and from impure calls. As my question to you moves toward a dark space that sounds like "TDD never touches a database", I also want to clarify on that. When I talk about TDD, I assume that people hear my words as talking about Unit-Testing prior to writing "Domain Logic". But I almost always clarify that TDD isn't only about that. The whole Shift-Left mentality comes in to play even as far as to say SDET teams (or their ilk) should be writing tests against APIs as soon as the contracts are decided. Possibly even finishing before dev work starts, but definitely finishing before dev work ends. TDD absolutely includes testing "integration" and "acceptance". Though generally when our audience is the frequent dev working on the middle tier, TDD is taken to mean Unit Testing before writing Domain code. Thoughts?
3
@ainocorry3004 (or @ whoever wrote the script) - Great video. Overdue, and perhaps under-done. I think there was a lot of value lost in just reading the 22 year old (99% correct) manifesto. The second half of the video didn't make up for it quite enough. You can see in the comments the pushback that the Agile Manifesto says to deliver every couple months. Being who you are, and the namesake of your channel, it was a huge missed opportunity to mention how the Manifesto is over 20 years old, and the definition of "Continuous Delivery" has a more concrete or well-known meaning these days. Namely; that Continuous doesn't mean Iterative. Iterative is part of the SDLC and Teamwork, but Continuous is part of the Integration and Delivery. Wow would I love to have a chat and collaborate on working these types of details out, because I love yours and Dave's videos for the most part, and have such respect for you all.
3
@ainocorry3004 Absolutely to everything you said -- I don't mean to assert that anything in the manifesto has become untrue, just that engineers in our industry have refined some of the meanings. I also think it was a good idea to read the manifesto as-is, but I'm commenting on glancing by a few obvious refinements in the context of today. For example, we define "Face to Face" FAR different today, especially after 2020's events. And we define Continuous differently, though I'll leave it to this epic channel to really touch on that, which is actually the main value I was aching for when I saw this video release.
3
Does he? Can you link to his videos saying so? He is very charismatic and I like a lot of his content, though I don't always agree. But I wouldn't have thought there would be such a disagreement.
2
Keep up the good fight, comrade!
2
One concept I teach is that Unit Testing should test Conditional Transformations. It's part of "learning the skill" of TDD (from the Unit Testing perspective). There's more to the lesson than that. But you are actually 100% correct. To do TDD, we almost always start with the most basic and simplest happy path. You write that ((Assertion)), then you write the code to test it. Then you write another assertion (maybe add(2,3)), then make sure it passes. Another part of "learning the skill" is gaining a vast knowledge of pain points for the specific language. Particularly how nulls, zeros, monads, voids, and other things are handled. So after your happy-path testing, you have to also add tests for those things.
2
** How can you develop something if you don't know what the end state is supposed to look like?
2
Thank you for your Service. :D - The battles you have fought (as have I and a few others programming over 20 years) have brought us far. I hope that videos like this one really hope drive the concepts home for those companies and people who are doing Scrumfall or frAgile. Though we took a lot of great lessons from XP, such as Pair Programming.
2
-- Every manager and/or Hero Developer?
2
Absolutely not, and I hope you are just trolling. Agile is a set of principles, waterfall is a set of processes, which do not follow Agile principles.
2
@giovani5586 I can understand that as some people's viewpoint, which is why I said it depends on what your ratio is. But to me, I'd rephrase your statement to something like this: Operations, Planning, Security, Reliability Engineering, Data Architecture, User Experience, Quality Engineering, Software Engineering (etc etc) are all *Information Technology* subjects. Quality Engineering is not Software Engineering, though they are two disciplines that work together. IT Operations is not Software Engineering, though it is required for Software to run. Site Reliability is not Software Engineering, though it is the latest role for companies following best practices. etc etc As a 20 year Software Engineer (and "Developer" before that), I could fill multiple full time [jobs, roles, contracts] purely focusing on the principles and practices that elevate Software Development into an Engineering mindset. TLDR; How do we write code to do this thing vs. Why do we write code to do this thing. In the context of this video (and Cloud Computing) which is an Operations/SRE concern, Software Engineering is absolutely required. Because (Purely in relation to code) we need to make choices on how we abstract our work, how we decouple different parts of the system, build stateless systems, make sure we aren't building "Distributed Monoliths", and all kinds of Code related concerns. So I can see some argument or some ratio toward including those other *Information Technology* roles and conflating them with "Software Engineering", but I personally set my ratio to a "Software Engineer" focusing on Operations and hardware like 10% simply to overlap with those roles in a DevOps mentality, and maybe 50% focused on coding, and plenty more room for other things not discussed here.
2
I can't recall where this concept originally came from, but I think it is already known to be a mistake. Though it depends on your definition of Engineer, and your definition of Customer. It isn't a horrible idea to hold your weekly (or 2-weekly) demos, managed by Product or QA, and having a dev there to take notes or answer questions. But those demos are specific customers, not the whole customer base. And your devs aren't acting as help desk constantly, it's one meeting every couple weeks, and they're generally meant to be fairly quiet. There's a line somewhere, and there is indeed benefit to doing demos.
2
You are correct in some ways. Though I'll point you to the publications of most expert Software Engineers, including almost every big name out there. Dave being one of them in his book, Mark Seemann, Uncle Bob, etc... They make it fairly clear that Software Engineering, while being a discipline that requires scientific reasoning, logic, measurements, and so forth, is different from other engineering disciplines. For almost the exact reason you point out. Physical engineering disciplines don't have the luxury of tearing down their bridges, infrastructure, buildings, and blowing up cars over and over. It is violent and cost prohibitive. But I guarantee you... if they could, they would. Any engineer (Physical or Digital) who has experience on both sides are extraordinarily envious that Software Engineering has this possibility to crash our proverbial cars millions of times over while attempting different implementations until they get exactly the best implementation. Our industry is in a unique position where we CAN do that. If your main experience is outside of such luxury, I can see how it would look insane. But if you give in to the absolutely absurd power it gives us digitally, you can see the value of running hundreds of tests millions of times over, constantly, in an iterative approach to improve your code until it is finally ready for production.
2
When I consult for companies, I make it an absolute priority to touch on both Conway's Law, as well as the fact that "Agile" is a set of principles surrounding the SDLC. SD, obvious to us, means Software Development. Systems like "sAFE" are business processes that strive to hook business processes (not Software Development) into a hopefully "Agile"-Principled SDLC. If you aren't first Agile in your SDLC, then you can't claim to have Business Processes that "Hook into your Agile SDLC". A business can't be Agile. But as per one of the Agile Principles - They can support the Software Development team, give them the tools they need, and trust them. As they step back, the SD team needs to also provide those hooks where the business can be looped in, especially for demos, and possibly velocity reports if you subscribe to that.
2
It's a feeling. If you're used to Rock Climbing (Lead or Toprope), then a perfectly vertical surface is really nothing. You don't even care if you fall, and don't even look down (or notice). But if you then free-climb 100ft up, the cliff certainly seems steeper and higher... of course it isn't, it's the same cliff. But suddenly it's far more complex.
2
I hear you. And the goal is worth mentioning or re-iterating; TDD results in good design because thinking about what you want to accomplish naturally results in good design. And that thought process has both positive side effects: Good Design and a great number of Tests coming into existence. Your premise seems to lean too far into TDD being a Design-First mentality, or a mentality of perfection or over-architecting. But think good design is a side effect of TDD and come back with your considerations from that viewpoint.
2
TDD (From the dev and Unit Testing perspective) relies on exactly one person. I have seen others conflate this video with the more meta TDD concept, which includes a shift-left mentality, SDETs, and overall ((Integration)) Testing. But the focus of this video is fairly narrow. It's on the individual Developer being able to do their job appropriately. This mentality also ignores the question that was asked/answered in both the video and in another thread in these comments: If you don't know what the result should be, how will you test it? Otherwise spoken: If you don't know what the result should be, how will you develop it?
2
Please do expand. Toward deceptive companies claiming Agile but doing Waterfall? Toward the industry or Agile in general? Toward this video/channel? Why?
2
I can slightly agree with this. But keep in mind that the vast majority (which is a lot) of companies doing "Agile" and mis-interpreting them have never even opened the Agile Manifesto. Or if so, the teams are being run by individuals who refuse to let go of their Gantt charts, and so will purposely misinterpret to suit their needs. Any person who is either tenured enough with Agile, educated on the subject, or new enough to not have been tainted by working within waterfall companies has no trouble at all reading the Agile Manifesto and interpreting it crystal clear.
1
You've almost hit the nail on the head there. TDD isn't just "easier" to test Functional code. TDD (in terms of Developer Unit Testing) is almost exclusively married to testing Functional Code. I'm not saying HASKELL or F#. I'm saying the functional (pure-esque) parts of the codebase that make up business rules, logic, algorithms, etc. No matter what language/paradigm you overall subscribe to. Granted, there is a more meta definition for TDD, but this video is focusing on the developer doing Unit Testing.
1
I think a couple people have similar ideas. This other comment (and my reply) may be relevant here: https://www.youtube.com/watch?v=4TuyMcCrTB4&lc=Ugz0q8E82UM-9nuKQzh4AaABAg.9sMdxb26xu49sP3fLv0Tpw
1
Dave covers a couple good points. But even amongst the current set of comments, and in my own experience, the issue is that people approaching TDD with Unit Testing don't see the difference between Unit Testing and Integration Testing (which is everything else). They see complications or impossibilities because they think their TDD needs to include testing the database or the UX. While TDD at a meta level DOES cover that, this video (and most uses of the term "TDD") is focused on Developer Unit Testing. Which is (for the most part) testing the functional portions of the code being currently written. It is not testing integrations.
1
You're going to start a flame war on Scrum, lol. I don't see the relation, but I agree in any aspect that TDD > Scrum (again, no real relationship though).
1
Those are very important questions - But they are questions regarding Integration Testing. Which includes almost everything (performance, acceptance, etc) that is affected by factors outside of your personal code. Unit Testing is a hyper-focused topic specifically about the (typically Functional) pure code you write. Algorithms, Business Rules/Logic, etc. This video has such a focus, on Developer "Unit Testing" -- by following TDD. Worrying about different databases, OS's, and so forth don't affect this level of focus. But your question is absolutely valid for the more meta definition of TDD, which includes a whole "Shift-Left" mentality, SDETs, and more. It's just not what this video is about.
1
@d3stinYwOw That's exactly right. But again, that isn't Unit Testing. If your test behaves differently depending on configuration, or where it ran, it isn't a Unit Test. Therefore it isn't related to this video's points. If the tests rely on tool versions, access rights to endpoints, databases, or any other system it "integrates" with, then it's an Integration Test. That includes most UI testing, Acceptance Testing, Regression Testing, Performance Testing, etc etc etc. I had to point out in a different comment that when I say "UI Testing isn't Unit Testing", I am only talking about those UI tests that are Integration Tests. There are plenty of UI Services and Behaviors that can be tested in such a way that they don't hit external factors.
1
Dave had a narrow view in this video, but I think he kept it on topic. TDD is a huge concept which includes a lot of areas of testing. But to "The Developer", which this video is targetting, it overwhelmingly means [UNIT] Testing. That is almost exclusively testing Functional code, algorithms, etc. If your testing is expanding to cover graphics, UX, database interactions, or any testing that ends up involving any measurable integration between systems, those are Integration Tests. STILL PART of TDD in a wider scope... but that frequently includes tests written by SDETs, QA, Integrations Teams, Infra, etc. Video games do have a very high number of algorithms and functional code. And even if Dave (et al) don't directly agree that Unit Testing is purely for Functional code, I think they would agree there is some fairly obvious line somewhere where testing is no longer Unit Testing if some amount of framework or integrations are coming under fire. So you may be right on the macro level that TDD (including UX testing and such) is nearly impossible for things like Video Games. But at the scope this video is bounding itself to (Unit Testing), the concepts may still be applicable.
1
I don't believe the video ever calls out bad developers per se, or "developers writing bad code." I think it is addressing perfectly competent, if not excellent, developers who can write great code. But that, even so, if they just set out to directly write code based on what they imagine in their head, there will be more issues than if they set out to write tests first. That gets the ideas out of their head and into purposely failing tests. Then they can base their "real" development on those tests to ensure they are fulfilling the real requirements. It forces these good developers, who write perfectly good code, to shift their mindset up front. TDD does not set out to stop developers from (purposely or accidentally) writing bad code. The code is fine. It's the intention and design of the code that ends up falling short. Maybe I consider "bad code" differently than others. But I've seen beautiful code have horrible bugs in production because it wasn't written with a TDD mindset.
1
@Fluxiton I feel an infinite amount of sadness at this, "Good code is code that delivers business value writing tests doesn't help you design to or deliver these goals". But I'm not blind to your point that, if they can't just write good implementation code, why do you think they can write good test code. I see no other possibility beyond the fact that you haven't seen proper TDD Unit Testing. I'm not supposed to talk about my own talks, but my latest TDD talk (as boring as it may be) could be novel to you. Test code isn't "real code", and doesn't really require even level 1 skill. If TDD with Unit Testing is done correctly, it's like 2 lines, sometimes 1 line of code for a whole test. Unfortunately, a lot of people see "Unit Testing" as whole frameworks with mocks and shims and huge assertions and such. In that case you're right -- such complexity would make me question exactly as you are.
1
@Fluxiton I think that is a poster child for experiences that create reservations about testing. But what you just described is *Integration Testing*, and certainly not TDD or Unit Testing. In the shortest number of words: If your Unit Tests run differently depending on configuration or environment, they are *Integration Tests*, not Unit Tests. It may click into a positive revelation if we realize this video is talking about a very narrow scope of TDD called "Unit Testing". Sometimes people accidentally use the term "Unit Testing" to mean a whole lot of things, but it is actually a very specific and narrow definition. Unit Testing tests functional code with 0 side effects. That's a short naïve definition, but it's pretty accurate for such a short sentence. Your experience was unfortunately with Integration Testing.
1
@2:30 - You're essentially working against Conway's Law. Not that that's bad though. The problem in many companies is that the Developers are working against Conway's Law. They're trying to change "The System" (Software Architecture et al) without changing the Organization. But they really can't change the organization, because the organization doesn't trust them. As a point of order, the organization likely hired people who would "do what they say", and who they probably pay poorly. So why should they trust them to lead? So it's great to have consultants (or Chief Engineers, Principal Engineers, Software Architects, etc) doing what you say, and trying to "Coach organizations to structure themselves to... [See Agile Principle #5]. But that only works when you enter an organization where the developers are already pushing upward. Because they can NOT change unless they change at the same time. That said, we can't get organizations to change unless they trust their dev team. And we can't get the dev team to be trustworthy if the organization isn't hiring people they trust. And they won't hire people they trust unless we self-regulate and define what it means to be a practicing Software Engineer. Certainly one who understands and champions TDD and Continuous-*
1
@unduloid If testing is giving a false sense of security, you are writing bad tests. Or, you are only focused on one type of test (acceptance, unit, regression, integration, system, performance, etc). Testing does nothing but give a proper sense of security, if you know how to test. There is no place in the Software Engineering industry for arguments based on the assumption that "the professionals" suck at their job. The only answer is; "Professionals" should learn how to do their job.
1
I assume this is word play with perhaps a much-needed video titled: Do People Abuse The Word DEVOPS?? I think that is actually a great idea, and has HUGE alignment with this one. Because DevOps is a mentality, or a principle perhaps. It isn't a set of processes. The DevOps mentality should increase communication and provide both overlap as well as obvious separation. But I agree with you that a lot of companies have just renamed their Operations team.
1
@PavelHenkin I agree with the sentiment. But unlike the satirical OP of this thread, and unlike the video, SDETs are a position with specific tools and processes. Agile and DevOps are principles that should be the foundation for processes. I have also seem some really good "Shift Left" movements that have either re-trained their "QA" departments, or unfortunately replaced some of them, with SDETs. Or "Automated Test Engineers", or whatever else you wanna call them. But TLDR; People who write tests alongside (or even before) development, instead of focusing on testing Post-Development.
1
I've mentioned before about a missing conceptualization of the lines between different types of testing. I think we should be clear that this video is talking about Unit Testing. That is explicitly testing ONLY Your code. If you are integrating with another tool, even if it's a foundational framework needed to do your code, then you shouldn't be writing Unit Tests against it. Unit Testing is to test only YOUR code, it isn't an Integration Test. That said, there is indeed a more complex and macro level view of TDD which includes testing parts of "your code" that include integrations with other tools. But this video seems to exclusively be talking about Unit Testing by the Developer who is writing their own software and needs to test their own code.
1
@xtinctspecies I think that is a good answer to your question, where you said, "How do I test something I don't know what the end state is supposed to look like."
1
Others have essentially mentioned it, and I have in other threads, but I'll be more direct here -- TDD is important as a meta concept. But this video is specifically talking about Developer Unit Testing. It mainly applies to algorithms (naively speaking). UI Testing, UX testing, Integration testing, etc... those all have a place in the meta TDD concept (Shift-Left), but it's not really the scope of this video. Granted, UI Developers DO sometimes have bits of algorithms in their "domain layer" or "service layer" portion of their code. So Unit Testing TDD does work there. But don't conflate it with testing design or integrations that require touching a "backend".
1
@bryanfinster7978 Perhaps no value to the conversation but: I have been doing web development since Javascript was invented, and I am very well up to date on the latest React, Angular, and Svelte frameworks. You are 100% correct that BDD is for UI testing (or testing "closest to the user" as I put it). But follow BDD principles and using cucumber-esque documentation isn't purely limited to Unit Testing. If you're doing BDD, you're testing a whole range of things. This video is talking about the Unit Testing portion. That said, if testing the behaviors of the UI is done in a way that it doesn't require "Services" to make HTTP calls, then it can usually be considered Unit Testing. Whenever I say something like "Unit Testing isn't UI Testing", I almost always specify that I'm talking about whether or not the testing touches the backend. I also agree that almost all UI testing should be part of the "Meta" TDD definition, and are almost all covered under BDD.
1
She also went through a whole permutation set, including "You can do Agile without Scrum". But seemingly explicitly excluding "You can do Scrum in an Agile way." Lol
1
@jasondbaker I've noticed some of that. For example, I haven't seen truly effective "QA" Departments for quite a long time. As companies "Shift Left", the checks for quality (including testing) becomes automated and run by scripts/code. They usually grow from GREAT QA personnel who learn a bit of coding. But those people still fall under their own teams. Perhaps renamed "Quality Engineering", definitely Site Reliability Engineering, but not Software Engineering.
1
 @ContinuousDelivery Thanks for the link! I'm headed over to watch that whole thing now.
1
@ContinuousDelivery Yes indeed. I agree, and that scenario shows how things can vary. I did say a couple times that each person will have a different ratio in their definition of "Software Engineering", which includes how much they lean toward the Code side, versus how much they overlap with Process, Design, Infra, etc. I'm sure in some companies, Software Engineers purely do code, while in others, Software Engineer is defined such that code isn't even on their mind, and everything between.
1
@ContinuousDelivery I do personally bias toward Software Engineering leaning fairly heavily toward code, but I'm only calling it a hat. I do believe that somebody can both wear the hat of Software Engineer (from a code-design perspective), as well as having fairly extreme coordination or fully hat-wearing of some more traditional infrastructure, testing, or planning roles. Just like I believe somebody can both build and operate a database as well as design and code a Website and everything between. That doesn't mean that we title that person a DBA and say DBAs do Web Design. It's just a talented person who can wear many hats. And though I do enjoy having clear definitions of roles, that doesn't mean I think they need to be separated. I 100% think there is overlap, coordination and communication, and a required understanding between the roles and the people who fulfill them.
1
@ContinuousDelivery Absolutely, and my conversation here seems harsh and out of place given that this video has a very clean start and end, the first paragraph in the description doesn't say it's just a clip of a longer video, I'm new to your channel, and I do have a weakness of not scrolling down to links in descriptions since they are almost always ads or ref material and such. Those things combined (especially my weakness) made me have a strong desire for more than the given content, and made me converse on there needing to be more than Zero talk about code as seen here. I'm watching the other video now. I do hope to continue to discuss and hopefully have some solid back and forth with you about Software Engineering as I watch more of your content! Loving it all so far.
1
Thank you so much for saying this. I had a similar comment on one of the other videos. It can't be over-stated or over-valued how true that is.
1
@mecanuktutorials6476 What you're saying is true in some scenarios. Mainly in older legacy code, in monoliths, or code not following SOLID-esque principles. Code with methods longer than 10'ish lines (give or take). But I only agree with you for the times people write Unit Tests after the fact, and in already huge spaghetti code monoliths. If you are doing TDD, there is simply and absolutely no way to complete code without it resulting in being properly documented by the tests. Granted, it does require TDD skills, naming conventions, etc.
1
This can become even better designed and more simplified if you lean into ISFC. (Imperative Shell Functional Core). If you're doing TDD, then your resulting methods and algorithms shouldn't be tied to dependencies at all. You shouldn't end up with things you need to Mock. But then the question arises, Well how do I use this purely functional bit of code with the database? The answer isn't to change that beautifully TDD-created functional code. The answer is to wrap the code in an Imperative Shell. You "Compose" your application together to consume your fully Unit-Tested algorithms and business logic/rules. TDD leads to ISFC - IMO
1
@k8s347 You think the "point of [this] approach" -- Do you mean the approach of GitFlow, or the approach that this video and the comments above espouse. Your contextual branching may have diverged. The point of [this] approach (the conversation against gitflow) is to NOT Do Pull Requests. PRs hinder CI, if not break it. But the point of GitFlow, at least one "benefit" is that there is a gatekeeper which, of course, makes it not continuous.
1
@Quenjii You are mis-defining async. Neither approach is async. Async means actions can happen irrespective of the other's schedule, including both "At the same time" as well as "at any separate time". Pull Requests are purely Serial, they happen in an order, definitely not async. Pair Programming happens only in parallel, never in serial. So PP isn't async, but most people agree that Parallel is closer to async than Serial is. So if anything, your definition is close to backward.
1
@scatterarrow The speaker absolutely does not pretend that. His stance is to do Pair Programming. While I'm a fan of PRs for some reasoning, I'm a fan of Pair Programming for others. Pairs working on something means it is not "un-reviewed". It absolutely is. Also, you CAN check in half-finished code, or even code with blatant errors in it, and have it delivered all the way to production. As long as part of your CICD process includes Feature Gating and your changes are behind such a gate.
1
@OrcusMaximus I had the same stance you did (and I still value that stance) for a long time. I even try to get clients to that point as an interim so I don't blow their minds with culture shock. But if you commit to Pair Programming and erase from your mind the thought that two people working on one thing is a waste, then it becomes your life, in a good way. It is so amazing.
1
@justusschwabedal5924 I agree with @arch126, but I also find this scenario silly. 8-hour workdays not overlapping means you only have 3 developers exactly perfectly distributed around the globe. Or, if you want at least half of your work day focused on pair programming, you have 6 developers EXACTLY Perfectly separated around the globe. Okay, maybe pair programming isn't right for that scenario. But also, c'mon, lol. Also also, like I said, it is agreed that Pair Programming isn't meant for 100% of projects. But the percent it would work for is higher than people imagine.
1
@Quenjii You're once again mis-quoting (selectively). The second half of the sentence you referenced said: including both "At the same time" as well as "at any separate time". But your method only works "at any separate time". And it requires your part to be complete first, then their part to be complete afterward. That's literally synchronous, the opposite of Asyncronous.
1
Hey Dave! Firstly, 100% on your list of common arguments. But I would propose that developers "hate TDD" almost exclusively because of bad management. Managers are the ones arguing the points you lay out, and they do so with rank authority. I am describing a complicated reality. Some management, frequently as high as executives, would rather hire a more compliant and quiet developer than listen to "some idealistic engineer" constantly pushing for TDD (or other engineering principles/processes like CICD). There are vastly varying personalities and backgrounds for each manager. But they do wax authoritarian and waterfall. ((( This doesn't mean engineers shouldn't use your tips to push for improvement. They Should!!! ))) In an upcoming speaking engagement, I am going to be reviewing how novice "workers" (devs) have certain personalities, and they either grow into a Managers, or into an Engineers. I would debate that your video is leaning too heavy in trying to convince those "workers" with engineering mindsets. I contend that they all already agree. The real target audience needs to be Managers, or (or novice workers with managerial/business personalities who will one day grow into managers). This video has value, but our whole industry (Software Engineering) needs a bigger initiative demanding that trust and respect be given to engineers with the expertise to make these decisions. It's a huge initiative that dwarfs the constant repetitively redundant echo of experienced engineers like yourself writing articles, books, blogs, vlogs, videos, and it never goes anywhere because we all already agree. In another (agile?) video, you said something about how managers make bad decisions because they don't trust their developers. The solution to that isn't to just blindly hire anybody on the street and trust them, but to be more diligent in your hiring, as well as be explicit with how you implement continuous education and training for developers toward a trustworthy engineering mindset. TLDR; You (we) should focus on that, building systems that demand (through proof and voice, not force) that management trusts their engineers. TLDR TLDR; We demand that managers trust their engineers.
1
Beyond other reasonable points that you need that extra code whether you do it before or after development... Your point about "Twice as much" is incorrect. There should be many times more test code than production code. At least as far as Unit Testing is concerned.
1
Answer this: How can you NOT do Waterfall when Compliance is so important in places like Government! In Government (and others), we require more compliance! Therefore, Waterfall! You can't have compliance checkpoints if you don't plan the whole thing carefully, and if you're just constantly delivering. COMPLIANCE!!! This is what I hear when I discuss the benefits of Continuous Delivery / Deployment. I have answers, I wonder what yours is.
1
I wondered if anybody would say TDD isn't a skill. I have seen that argument go awry because some people define skill differently. What are some of your examples of skill, or counter-examples of skill?
1
@5:50 Hey Dave! I found those code snippets interesting, and found them in your "Acceptance Testing for Continuous Delivery" slides for your conference talk. I'd classify what I see as a very Rich Domain Model (RDM) based development (Data and Behavior together). What are your thoughts on Service-Based development, using something closer to Anemic models, and passing them as data into Service classes/methods? Got any content on that?
1