Comments by "Andrea Laforgia" (@andrealaforgia) on "Continuous Delivery" channel.

  1. Great video (as usual). Dave, may I suggest that you improve the sound quality and remove some reverberation in the room? Are you far from the mic? In case, you should wear a lavalier mic.
    11
  2. "There is no manager in the world...", "Agile should be reconsidered"... okay, calm down :) Team Topologies has been written based on what works in the real world. I have worked in at least three companies where we had enablement teams and followed the models suggested in the book and it worked really well. My current company is also adopting that model. I am working in the Developer Experience team. I think you must have worked with some crappy managers (not uncommon) that have seriously burned you out, and that's a shame. Also, Agile is not Scrum. You can work in agile ways without sprints and story points. In fact, it's advisable, in my opinion, that teams do so. It's not Agile that needs to be reconsidered; what needs to be fixed is the "Agile theatre" in so many companies.
    8
  3. You don't "pull in" those changes. You and the other devs work on the same codebase (Continuous Integration <=> Trunk-based development). Working on the same codebase and committing micro changesets multiple times a day, you break down work more easily, hiding incomplete features behind feature toggles, and avoid merge hell.
    8
  4.  @RFalhar  The fact that metrics can easily become a surrogate for the value that they are supposed to measure is well known in business psychology. It has a name, it's called.... "surrogation". Look it up. Its natural consequence is Goodhart's Law: "when a measure becomes a target, it ceases to be a good measure". Harvard Business Review has published a good article "Don't let metrics undermine your business" and you can find many others along the same lines being published over the last 10-20 years. I have recently engaged in a fierce discussion with the creators of Pluralsight Flow to expose all the flaws in their product, which is going to be a boon for micromanagers who - as Allen says - "want what they can measure". It's not about opinions. Our industry has known the dangers of output-driven vs. outcome-driven for many years now.
    7
  5. TBD requires committing meaningful changesets frequently and your aim as a developer is to granularize big changes into multiple, meaningful subsets. The idea is that you break down your work into manageable chunks along the day. That way, it is basically impossible that a single TDD-ed changeset takes a whole day to write.
    5
  6. >Stupid short cuts, no organizing. That has nothing to do with mob programming :)
    4
  7. When things are too liberal, someone might start a project with their favorite toy, develop a whole system with it, and leave a trail of rubbish after they've left. I've seen that first hand and it's a huge problem. There is a lot of risk, for companies, associated with reckless technology adoption. On the other hand, it is also true that too much caution creates stagnation and crystallises people's skills. I've seen people that after 20+ years became totally unattractive to other employers. I guess it's worth having a process that does not prevent the adoption of new technologies but at the same time puts some governance on it. Finding the right balance is not easy.
    4
  8. Nobody is promoting releasing not-too-stable stuff. Quite the opposite. Not that CDel doesn't means that you must release after every commit to master but that you are able to do so anytime.
    4
  9. Unit testing means testing small units of *behaviour*, so the granular bits we develop driven by tests are granular behaviours. There is no reason why the tests your write before the code should in any way tied to implementation. Just write tests to assess granular behaviours.
    3
  10. You are not supposed to merge a failing test into trunk. The atomic unit that you merge into trunk is code + its passing tests.
    3
  11. In a professional context, "enthusiasm for new toys" is a personal feeling, whilst "choosing a technology" is a collective action. The problem is how you bridge the gap between those two, i.e. how you transform your enthusiasm for new toys into a projection of tangible benefits for the organization you work for. There should be a dialogue of some type and a consent like that Aino was mentioning should mature. You might not know if there will be benefits, therefore you ask to experiment, but experiments must be controlled and with well-defined expectations, otherwise the risk of going off tangents is high. I've seen all of that in my career. Deciding on new technologies carries a lot of risk for organizations. A developer might leave after a couple of years, but systems written with a specific stack might survive them much longer.
    3
  12. New hires are complete strangers joining our teams all the time. We must have a process in place that allows them to become productive as soon as possible. Mob programming is great at making people feel welcome and productive as of day 1.
    3
  13. No, it's working together, it's communicating, it's collaborating. A meeting can be working together, but working together is not necessarily a meeting. A meeting is communicating, but communicating is not necessarily a meeting. A meeting can be collaboration but collaboration is not necessarily a meeting.
    3
  14. I've seen a lot of misunderstandings of TDD but yours wins! :D
    3
  15. I would say it differently: focus on repeatable and deterministic tests and avoid fragile and undeterministic ones. That way, you'll see that, if you focus on the left side of the spectrum, you don't need to go to other side. End to end tests can and should be avoided.
    3
  16.  @ZodmanPerth  who said that they should "blindly" adopt them? As an engineer, you must be aware of what the research in your field has discovered and make informed decisions based on evidence. Far from "blindly". This is true for every technical field.
    2
  17.  @ZodmanPerth in every field of the industry there is research showing what are the most effective techniques, ways of working, tools, technologies in specific scenarios. What Dave is doing here is showing you what good looks like. Exactly what the DORA survey does what the Accelerate book does, or what ThoughtWorks' tech radar does. Nothing wrong with that. Now, it's up to you how you put that advice into practice. Dave, and other experts, are not putting a gun at your head and forcing you to adopt a certain way of working. You need to apply your judgement based on your specific scenario. The fault for those engineers blindly applying those concepts is of those engineers. What Dave is doing is showing (not even teaching) good principles. You should thank him for that.
    2
  18. But you customers can start using those features straight away, even though feedback on those features comes a few hours/days later. The important thing is to always keep your system in a releasable state and optimise for complexity, so if anything needs changing, it can be quickly done.
    2
  19. The ability to communicate is a prerequisite for any sort of collaboration, even asynchronous. Mob programming is nothing different than working together. The team must establish a relaxed and psychologically safe atmosphere where everybody is free to think out loud and share.
    2
  20. I would argue that refactorings are the best use case for trunk-based development. If you are refactoring a large part of the code, you’d better ask other people to stop working on that code or you’ll end up with a disastrous merge hell. If you can organise a refactoring as small batches of work to be integrated frequently, definitely do it.
    2
  21. Once again, pair programming does not mean "working while there is a person watching every LoC over your shoulder". That is NOT pairing.
    2
  22. Nope, you don't need that. Adopt continuous integration, no matter what the size of a feature is. Big features should still be broken down into valuable slices deliverable frequently and continuously. If you adopt trunk-based development, you can hide any incomplete functionality behind a feature toggle (if there's no other way). The longer you stay on a branch, the later your changes will be integrated, the more serious will be your merging problems, the less confident you are that your complete feature is not going to break other stuff.
    2
  23. Not really. Wikipedia defines engineering as “Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings”. If you extend that to software, nothing dictates that you should be following a waterfall model.
    2
  24. >The question that everyone in business typically asks, and that mobbers tend to deprecate, is whether it’s enough better to justify the obviously high investment, along with the abandonment of just about all work done in parallel. Business folks often wonder that indeed. I guess these problems arise when two very different areas intersect: technical practices and people management. My answer to that is that it would be easier to understand if "everyone in business" stopped thinking of humans as machines. Making humans work in isolation produces a worse result than having them work as a group. We've known that since the dawn of time. Humans are social animals who achieve exceptional results by collaborating (whether it's chasing a mammoth or coding a new feature). Besides, there is no point in creating teams only to make team members work in silos. What's the point of making me build a spaghetti and marshmallow tower with my colleagues if then you want me to play in my little corner, with my headset on? In no other field, we'll be able to find teams that don't collaborate synchronously to solve a current problem (football teams, military platoons, surgical equipes). The business folks should therefore stop equating mobbing/pairing with typing. Working together means thinking more clearly, sharing knowledge, achieving consensus, creating better quality, getting higher job satisfaction, avoiding wasteful activities of synchronization and rework (which often happens with post-development code reviews) and ultimately saving time.
    2
  25.  @ModernSoftwareEngineeringYT  Should we change "Continuous Delivery" to "Continuous Deliverability"? 🤣🙃
    2
  26. The scale of the project and the number of dependencies should really be irrelevant, in order to apply TDD. In fact, presenting an example for adding two numbers is much more similar to the real TDD scenarios. TDD is for small problems and large problems can always be broken down into small problems. TDD is applied to small scenarios/behaviours to be tested in isolation. Then you move on to the next one, and the next one, and the next one.
    2
  27. Using branching for that specific activity is totally fine and probably the only usage that is acceptable. Branching is not necessarily evil per se. It’s a Continuous Integration anti-pattern, though, so to be avoided when you want to integrate often with other developers in order to deliver changes as fast as possible and avoid merge conflicts (typical of long-lived feature branches). However, bear in mind that the longer your speculative branch staying unaligned with master, the more it will diverge with the rest of the development hence the more likely it is that your speculative work becomes less and less relevant.
    2
  28. >(a) One HAS some other Engineer(s)* available to pair/mob This is the premise of working in a team, isn't it? There is a widespread idea that a team is a set of individuals working independently and only occasionally catching up. I've heard many times the argument "helping the junior members of the team slows down the senior ones who cannot complete their work". That's completely wrong. There's no "my work", "your work", there's the "team's work", so get the members of your team pair up and mob cause THAT is the premise of teamwork. If that condition is not currently achievable, work hard to achieve it. My thoughts about (1) and (2): It's another work culture problem. If you have a super slow local build, that's a big problem. You need to address that. As a developer, you must be able to commit to trunk with confidence. The trunk build is not where you verify your local changes, so any developer who does that needs a good slap on their wrists. Any company that allows gaming the system that way has a big cultural problem that needs addressing. I am not going to comment any of your remaining points, because none of them really contradicts what Dave proposes or creates scenarios where what Dave proposes is inapplicable. Those are not an indication of situations where PRs are a better solution. They only show situations where CI and CD are either not being implemented properly or using a completely flawed toolchain. The fact that PRs, in those specific contexts, might come more handy because CI and CD are done badly, is not a merit of PRs. Sorry, but you missed the point.
    2
  29. Every complex collaborative work activity requires a certain level of communication skills. It's just part of the job. If people sit quietly and do not contribute or even pay attention, that's a problem. It's deeper than just what happens in mob sessions. It's a professional ethics problem. As part of the hiring process, it is crucial to explore the communication ability of a candidate and their attitude towards teamwork. I do think that there is an upper limit to the number of people who can work in a mob and, based on my experience, that's 4 or 5. Pair programming is good but only when pairs regularly rotate. Otherwise the problem is that pairs are going to cristallize, with people who either always want to work together or never want to work together.
    2
  30.  @soppaism  not even needed for that. Major groundwork can and should be done in a TBD way.
    2
  31. Then you were one of the lucky ones. According to the 2015 CHAOS report from the Standish Group, the percentage of failed/successful/challenged Waterfall projects is 29/14/57 vs. 9/42/49 with Agile. Huge difference.
    2
  32.  @davidboeger6766  pushing stuff to master on a whim IS NOT what CDel prescribes!
    2
  33. I never understood why in LoTR they want to live like in the Middle Ages when they have magic and could just make quantum computers out of thin air :D Great video, Aino, thanks. In my company, I'm trying to establish a process based on Tech Radars (inspired by the work done by ThoughtWorks). It's much harder than anticipated. Defining how to evaluate new technologies, how to make them progress through rings, how to create consent and manage disappointment when a specific one doesn't make it. All hard tasks. Whether there should be a "final word" panel or it should be more democratic. How to justify when a technology moves to the "Hold" ring and gets deprecated, and the countless flaming discussions that could generate. Choosing technology frameworks and managing their life cycle is far from trivial. Also thanks for pointing us to Linda Rising's talk. There is an interesting book suggested to me on LinkedIn: "Immunity to Change", by Robert Kegan and Lisa Laskow Lahey.
    2
  34. Feature toggles. No, you don't need to change any code when you push it live. You can just switch a toggle on and that's done via configuration. You can avoid removing the feature toggle straight away from the code (which yes, would require a new production deployment). If you want, you can use the toggle as a kill-switch, in case of problems. It would allow graceful degradation for example.
    2
  35. >Isn't it a good workflow to merge develop into your feature branch at least once a day? No. If developers work on their branches for days, master will not contain any significant changes for days, hence merging it into your branch doesn't make any sense. >It's similar to CI It's not even similar. >but other people won't be disrupted by having to relearn changes of an unfinished feature. Team members always benefit from working on the most up-to-date version of the code. >For example, I rename a method and add a few similar methods and then remove some, I don't want to be used, after I'm sure, which are the best methods. Then add a "Don't use" comment. Isn't communication key in a team?
    2
  36. By adopting techniques like pair or mob (ensemble) programming, you can easily avoid formal code reviews and adopt continuous code review instead.
    2
  37. There are antipatterns with any practice and pair programming is no exception. But it's not a problem with the practice; it's a problem with the humans implementing that practice and not committing to that practice. What you describe is not pair programming; it's "pair programming theatre".
    2
  38. >it result in twice as much code being produced Simply not true. You write code, you need tests for it. Whether you write them before or after doesn’t change the amount of code produced.
    2
  39. Continuous Delivery is the material foundation of agility. Working agilely means collaborating with the customer by releasing valuable working software as frequently as possible, in continuous small batches. The needs of the customer are continuously evaluated and wasting the customer’s budget on potentially useless features is avoided. The tools/methods here are those that enable us to satisfy our customers via early and continuous delivery of valuable software. Do you know a better way of working?
    2
  40. >I think continuous integration is a good idea, but I think pushing directly to origin/main (or origin/master) is a bad idea. That's a contradiction :) It's not CI if you don't push directly to the main branch of development multiple times a day. Note that CI and trunk-based development are the same thing. >My preferred way of working is to split backlog items / user stories into small (mostly) atomic tasks that aim to introduce one small addition. That's great. >All developers are human and everyone makes mistakes. By peer-reviewing every single addition to the code base we catch these small mistakes early. Sure, and that's why CI is not removing the benefit of code reviews from the picture. It's only advocating a different way of reviewing code, through continuous code reviews that happen while developing, and not at the end. There are various disadvantages of having PRs at the end of development phases: it's extremely hard for a reviewer that has not been involved in the development of a feature to get a good understanding of what the code does. You haven't seen it working live, you only have a bunch of files to statically analyse. The risk is that reviewers only skim through the files for a superficial validation, trusting the creator of the PR (especially if she/he is a senior member of the team who knows the system well) and coming up with a "LGTM". This is were PRs can become really dangerous tools. It is much better to use pair/mob programming and continuously review the code while working on it. >The added benefit of this is that you get to read other people's code daily. Is that a benefit? Having to stop your development activities to read other people's code of which you know very little? >That is a great way to learn. Sure, but learning through collaboration is 10x better.
    2
  41. >Saying one branching strategy is a bad idea is bike-shedding and missing the point of CI / CD. If that branching strategy is antithetical to CI, then saying that is a bad idea is perfectly legit. GitFlow is antithetical to CI.
    1
  42.  @secretluver  your point really doesn't make any sense. Sorry.
    1
  43. >shouldn’t someone have reviewed your code before you merged it into origin master? Yep. The guy sitting next to you in a pair or the guys sitting around you in a mob. Or, in today's pandemic terms, "sitting".
    1
  44. Sure but with feature branching you are slowing down the test of the integrated code cause tests are run on each branch independently. It's only when you integrate changes from different branches that you may discover problems.
    1
  45. I can tell you that some coding bootcamps (I've been a mentor in one of them) use pairing and mobbing regularly, rotating the bootcampers. It works really well.
    1
  46.  @madollamike  >so unless your team is comfortable with not being able to work solo Don't you think that "team" and "work solo" is a contradiction? >would you say continous integration isn't a good idea for your team? Continuous Integration is a good idea for the company. It doesn't cease to be a good idea just because your team is a group not able to collaborate.
    1
  47. ​ @madollamike  >If I'm on a scavenger hunt team we might decide to divide and conquer and check in at a designated meet up spot once an hour so we can stay on the same page and review our accomplishments. Do you really think that's a sensible way to carry out a scavenger hunt? I am not joking. I think it's a terrible example that totally shows why trunk-based development is indeed the best way of working.
    1
  48. There are plenty of examples on the internet when searching for "CD pipeline". Tools, however, are irrelevant. What counts is the principles.😊
    1
  49. If it's too intense, then you can inspect whether you are working at a sustainable pace. There are ways to perform mobbing effectively (frequent breaks/rotations, hard "let's call it a day" deadline, etc...)
    1
  50. Can you clarify how Git Flow would ever help companies to manage risk of change in codebases with poor test coverage? Cause if test coverage is poor, no branching strategy helps there. With regard to "one-size-fits-all": no one ever stated that. In every case, however, where GitFlow is used, then Continuous Integration can be used, because CI would provide a logical segregation of features that is equivalent to the physical one offered by GitFlow. Sure, every organization has different approaches to risk, and yet so many use the same techniques to manage it: feature branching, GitFlow, PRs. In virtually every comment from GitFlow fans I've heard "it's not a silver bullet", "it doesn't always work", "in the real world it does not work that way" and yet no real argument was offered to rebut what Dave talks about in his video. What are the contexts where CD is not applicable? (not provoking, just curious)
    1