Comments by "Brent Jacobs" (@br3nto) on "Continuous Delivery" channel.

  1. I’m actually really concerned about the messaging in this vid and others like it. It’s a disservice to our community. People shouldn’t be taught fanatically that one thing is good and another thing is bad. They should instead be taught the trade-offs, and taught the skills to be able to make informed choices. Branches are good for the things I mentioned in another comment, but there is a trade-off to be made the longer a branch is left open and the more code that goes into it. By jumping to “branches are bad”, you’re skipping important teaching points like how to break large problems down into smaller problems, and how to introduce fundamentally different code without breaking everything. For example a fundamental breaking change from a one-one relationship to a has-many relationship in your DB when a lot of app logic is implemented as role-based logic, and now needs to shift to resource-based logic. It takes a different kind of skill to do that in a CI way. You’re missing the opportunity to talk about that and teach those skills. Please stop being so fanatical about “branches are bad”, and instead focus on the skills devs need to be able to push changes to production faster.
    50
  2.  @michaelrstover  I’m quite well watched. If Dave won’t provide balance, I will. I hope others do too.
    13
  3. It’s literally impossible to not do branch based development. When you check out a branch from a remote repo, a new branch is created. It’s actually awesome that we can do that. We should create branches. How often are you in the middle of making a change when a new more urgent requirement comes up? Either stash or commit your change in a branch, then create a new branch for the new work. You can’t do that if you don’t use branches. They let you be creative. They let you try new things without effecting the main branch. It’s perfect for the creative process. It is the worst advice to not use branches. Don’t listen to it. Stale and long-lived branches on the other hand are the devil. If you have a branch, you need to frequently rebase it, but the more code in that branch it’ll start holding up other dev work that is planning to rely on that work. This forces work to be done in serial instead of parallel, and that really slows a team down.
    9
  4. Great video! I think this captures the problem with software engineering really well. Especially the part where you say that at any time, a change in requirement may mean our design doesnt work any more or is now a poor choice even though moments before the design was fine.
    8
  5. 7:13 omg! Reset frame! That’s amazing!!!
    8
  6. 14:52 I would google it too. And for the same reason. The most important thing about software is that it meets the changing needs of its intended purpose. So software needs to be well written, easy to validate, and easy to change.
    7
  7. I agree with getting code out into prod asap to get feedback, but I’m still still not convinced on the No branch policy. Firstly, just pulling from remote creates a distinct local branch. But more than that, I’m usually working on a few ideas at once, swapping between them over a day. Or checking out other changes from other team members… I don’t know how you could do this without branches…. Maybe with git worktrees… but it’s kinda like working with another branch anyways… further more, doing this my team is still able to deploy multiple times a day… and after, we just rebase and continue. But granted, I don’t know how to get rid of the PR without the equivalent of pair programming before release. But do we need to review in person? Sometimes it’s definitively better, especially for complex changes.
    6
  8. 2:16 The UI is really just a projection/transformation of data in flight and the backend is really just a transformation of data in flight to persisted data. Both well established repeatable patterns. The hardest part therefore is modelling the data in flight. The transformations to persisted data store or UI is just repeating the same patterns.
    5
  9. I think the problem is that many devs don’t know how to write simple code. And this has impacts on frameworks and libraries which then also become more complex than necessary. One example is creating a pure static function which holds some global configuration, and calling that function in random places throughout the code. Immediately, we get a tonne of complex coupling which makes it really difficult to modify. We effectively have private backdoors into our code which we can’t access and easily test. Perhaps we can mock that global function, but that leads to horribly complex tests that may randomly fail. Instead, the config should be injected. It might be more code, but it’s more testable and less decoupled code that is easier to modify.
    5
  10. 15:35 how is code “code hidden away on a feature branch” any different from code checked out locally and not pushed to the remote trunk?
    5
  11. 6:27 LLMs will never replace programmers because they are missing two important features. They don’t understand the actual AST of a program and they cannot make manipulations, transformations, additions, subtractions of that AST. When I say AST I’m not meaning the actual AST of single language, but the entire generalised concept of what an AST would be for a multi-language program like we see in web apps with SQL, backend code, over the wire serialisations, HTML, JS, etc, etc.
    5
  12. @Ned Gerblansky everyone’s different mate. I don’t find the background distracting, but the commenter does… and they’re not the only one… you wouldn’t say to an epileptic person to not be a snowflake when they get fits from flashing lights… they don’t control their reactions. I can only assume that people who find the background distracting are equally unable to control their reactions. So don’t call people who react differently to you snowflakes. If it annoys you that much maybe you are the ❄️
    5
  13. What do you mean when done right? OOP is always functional programming. The instantiation of a class is effectively the creation of a closure and a callable function (or functions depending on how many methods the class has), which can then be passed around and referenced and called at some later time. OPP was doing functional programming before functional programming was even a thing.
    4
  14. AI is a bit like Clippy… it’s good in theory, better when it’s not there, will miss it when it’s gone.
    3
  15. From my perspective, this happens because the people managing software teams and projects have absolutely no formal or informal training in software engineering. What exacerbates this, is there is an IT department and CTO and/or CIO, but no software department and CSEO to discuss, encourage, and assist with good consistent practices. Only people with software engineering training/experience should manage software engineering/development teams, and there should probably be a corresponding department and representation at board level. Not only this, but software engineers are the only profession that could also extend their training to refactoring company structures to make them more efficient, and solve all the silo issues. (Assuming that company processes and hierarchies are same enough to the patterns seen in software).
    3
  16. 14:39 hold on… the branches should be rebased, and so have all the latest changes…
    3
  17. Hey Dave. Can you show us the alternative to feature branching and pull requests?? Not just describe it, but demonstrate it.
    3
  18. A better analogy maybe that code is a deprecating asset. There’s a cost to build or purchase, a cost to maintain, and a cost to replace. Like a car or house, software ages, becomes more expensive to maintain and gains greater lack of modern features, and probably also experiences a decline in expertise to support it. The quality of the code is only part of the story.
    2
  19. “We can’t fit the complexity in our heads” Yes! This isn’t said enough!
    2
  20. 1:39 it works and is easy to change 100%!!!!
    2
  21. Can you show more examples please? E.g how do you do this in reactive style apps? E.g how do you mock chart libraries that draw to the canvas? What are some common examples that can easily be encapsulated? What are some harder examples?
    2
  22. 💯. The things you mentioned are 100% the first things a dev team needs to do to achieve CI. Fix deployment pain, increase observability and testability. CI isn’t just something a team can achieve overnight. There are steps that must be taken to make it happen. Dogmatically saying CI is the only way and branches are bad skips over all the important discussions and learning that a dev team needs to take on board to make CI happen and also skips teaching about all the nuances and tradeoffs that can legitimately be made along the way.
    2
  23. @Ned Gerblansky Surely, a false equivalence can be used against an ad hominem? Fallacies are quite effective... Yeah, I like the animations and layout too. Your last comment was insightful. You’re very passionate about the gui not changing and people taking responsibility for themselves. The good thing about Dave is that his whole schtick is to gather feedback and improve. So I’m sure he’ll take the feedback and either change and adapt or choose to ignore it.
    2
  24. 12:11 they might teach only coding in Computer Science degrees… but they do teach software development in Software Engineering. I did a Software Engineering degree, and I’m constantly flabbergasted at how people with Computer Science degrees can’t actually write good software systems. They are great on the low level, but self-taught at the higher levels. I’m also flabbergasted that companies think Product Managers without software engineering degrees and experience are a good idea. Software Engineers are trained for that role at university.
    2
  25. Is it a good idea to merge many smaller repos into one big repo? What considerations need to be made when doing this? I came out of this talk wondering if my team of 4 should merge our 20 odd interrelated code repos into a single monolith repo. There’s so much code/design patterns we wish we could extract into libraries and share with the other projects, but the amount of time has proven to be just too prohibitive. A common problem is that when developing or changing features, we need to update the dependent libraries/services first and release before working on the actual feature that will benefit users. This is time consuming and error prone. We need to be 100% accurate with our change to the dependent libraries/services otherwise we will need to perform multiple releases. With a monolithic repo I can see how it would reduce the barrier and time costs as we could develop all the services and libraries in step and release all at the the same time. But I’m hesitant to take this step as I’m not sure if there are any negative or unintended side effects.
    2
  26. You can easily do CI and use branches together. Branches are a creativity and productivity tool that can be effectively used to do CI. The thing being glossed over is all the skills that a dev needs to develop in order to do CI. How to break problems down into smaller pieces without breaking the app is not something taught well. It requires a different type of thinking and methodology than simply writing an entire feature or change in a branch and then merging it. It’s a shame that this conversation skips talking about those needed skills to make CI work.
    2
  27. I’m still convinced a class describes one or more closures that close over the same variables. Therefore OOP is just an advanced form of FP.
    2
  28. 11:42 AI tools aren’t in the right place to achieve the goals that both of you are looking for. AI tools in the IDE is really the wrong place for them. Instead, they should be in git repositories and issue tracking systems. Then it could be the goal to define requirements, and have AI tools to help incrementally change the system to meet the requirements. People in the loop can validate or direct the changes. Requirements can incrementally change, and the AI tools identify and close the requirements gaps. Maybe even suggest 10 different alternatives for consideration. Devs can provide feedback on the alternatives, and combine the alternatives. Etc etc. there is still this fundamental problem of making sure that everyone is on the same page and working in the same direction and making the right changes though. The other gap is that we don’t have a cross-boundary multi-language “compiler” that can detect error states in distributed systems yet. That is , a compiler that can create an AST for any distributed or monolithic system.
    2
  29. Switching priorities causes you to need to temporarily work on another feature. You want to run an experiment or two or three to compare different approaches to the same problem. Branching can be a great creativity and productivity tool. I don’t agree with b or c. I think b is problematic because there’s a good chance a patch will need to be applied to both versions, but now you need to apply the same code twice (or more, depending on how many versions you’re managing). It would be better if both versions were supported in the main branch. I think c is probably because data scientists and others have less formal software engineering training. There is less incentive and/or knowledge to write maintainable and shareable software. Even throwaway code can be useful in the future, so merging it into the main branch and making it shareable and maintainable would be more beneficial in the long run. That just an assumption, but backed by some first hand experience.
    2
  30.  @ContinuousDelivery  yes, fair enough with the timings. But it doesn’t matter if the written OOP is good or bad, it can still always be considered as functional programming. Even though it’s not what people think of when thinking about functional programming, creating an instance containing data which can be passed around around and used and manipulated at any future point in time, it has the same effect as functional programming.
    2
  31.  @ApprendreSansNecessite  Maybe I don’t seem to be, but I am actually very open. I love learning and discussing ideas. I think I seem closed to you because I haven’t been convinced yet by your argument that I’m wrong. So, I think maybe we’re talking about two different parts of the Functional Programming ideology? The part of that ideology where it says functions are first class citizens, I’m saying that an object meets that criteria. Nothing more, nothing less. Referential transparency, immutability, and any of the other properties can be codified within the class to give it that deeper adherence to the more pure and algebraic parts of the functional programming ideology. That is, it’s the way you write code that matters. So, I don’t think it’s true at all that “the moment you introduce that stateful closure you literally loose every single feature of functional programming”. Also, at some point in our code, there has to be mutability and state that is changed, otherwise you don’t have a useful program. At some point I want that 1 to become a 2 or that “Hello World!” to become a “Goodbye World!”. The more mathematical parts of the Functional Programming ideology seems to ignore that part. I’m sorry but I don’t know what I’m supposed to be thinking upon i your triangle/square example.
    2
  32.  @nythrox3047  it’s not like saying that at all. Well, maybe, if the CPU instructions provide OOP and FP concepts. I guess one of my implicit points is that saying code that is writing in a “functional programming” kind of way isn’t a good description of what is good code because technically all OOP is FP and I’m sure all FP code is not good code. The more I read up on FP though the more I realise it’s an ideology. Which parts of that ideology are the good parts that automatically make a certain piece of code good? I’d wager that there are equal amounts of really shit hard to understand and reason about highly coupled poorly written FP code just like there is with OOP code. Which, if true, means it’s not FP that makes code good but certain qualities mentioned within that ideology. I mean JS code is FP code and not all JS code is good code. Or maybe I just read too much into the title. I assumed the title meant good OOP looks like FP which is good. But I think I added the which is good part myself.
    2
  33.  @nythrox3047  maybe that’s what they implied, but they didn’t say that explicitly in this or the original vid. So yeah I took it to mean the normal meaning of functional programming, which starts with first-class functions. Sorry? OOP starts at that FP point. There is no reason all the other functional programming qualities that have been talked about in this thread can’t be used too. So my point is, those qualities talked about aren’t specific to functional programming. They’re specific to just programming whether using FP or OOP. I guess it’s just that FP came first. Good code doesn’t look like FP, because FP doesn’t automatically mean good code; FP code can be really shit; good code looks like <insert specific qualities that don’t relate to a specific programming paradigm here>. Make sense?
    2
  34. How do you train something that doesn’t have feelings and empathy and consciousness about the concept of being nice? But if you could, by training it the concept of being nice, you also need to train the concept of not nice. The problem on lies in the places where these systems apply actions and have effects on our world. There is no reason why we can’t simulate and/or run those outputs through additional auditing layers to root results that will have a bad effect on us.
    2
  35. Hotdog! Not hotdog!
    2
  36.  @ContinuousDelivery  nah the analogy works. Let’s say the asset is a machine to do some task in a factory. Is the machine fit for the task? Does it fit within the budget? How much resources does it take to maintain? Now, let’s consider those same questions over time. As new machines come out with more advanced, how does it compare? Can the existing machine be modified and upgraded? Can you still get parts? Can you still find people that know how to maintain the machine? Can it still do tasks in a market competitive way? It’s the perfect analogy because a computer program is basically a digital machine. The best part is that companies know how to budget for the maintenance and upgrade of machines, but they often don’t know how to do that for software. More people understand physical machines because they can see and touch it. This analogy is the perfect parallel to allow ordinary people to understand that software needs to be maintained too. The good thing with just using the more generic term asset, is that it can be adjusted to what people understand. Like maintaining a car or a house or a road. And all these things can be over or under engineered, fit or not fit for purpose, too expensive or not expensive enough, just like your 100 vs 100k LOC example.
    1
  37. @ nothing gets modified. It’s all read-only.
    1
  38. @ no. It’s actually terrible for the same reason global variables are terrible. Like I mentioned at the start, it creates a lot of highly coupled code due to how it has backdoors into the code. It creates code that is not easy to modify. Sure you might be able to change a value and it effects everything globally, but the second you need one value here and another value there, you find your self in a mess and doing all the work that should have been done up front, and would have been easier up front.
    1
  39. @ I think your logic is backwards here, and I also think you’re missing my actual point, which is “most devs don’t know the patterns of code that make code more complex and difficult to change”. First off, this is just one example pattern. Second, the situation I have described has happened many times throughout my career, and happened again just this week, hence why I used it as an example. Every single time this pattern is implemented, the effort to fix it is large compared to the small effort to inject it from the start. It’s either lazy development or uneducated development when this pattern is used, and it inevitably leads to unnecessary future code changes because the requirements do always eventually change.
    1
  40.  @lucemiserlohn  yep, I 100% agree with everything you said. I also know we can write code in two ways, less complex that is decoupled and easy to change, and more complex that is couple and hard to change. There are patterns of code that are more aligned with the former, and patterns of code that are more aligned with the latter. Knowledge and ability of how to achieve the former seems to be less practiced. As Uncle Bob says, most devs stop at the first working solution, and don’t continue to make that code maintainable.
    1
  41. They probably also have people who are not Software Engineer educated at the top of the management hierarchy. That is, they probably have a Chief Technology Officer, but not a Chief Software Engineering Officer in the C-suite. They probably have an IT vertical, but not a Software Engineering vertical. Each Software Engineering team is probably part of some random business unit and isolated from one another.
    1
  42. 5:35 I like that point Dave. What we actually want to know is: what are the gaps between what the system does and what we want the system to do, and what effort and cost is required to close those gaps. Leaders of organisations want to be able to steer the ship, and to do that they need to know how to correct course and what efforts and resources will get them to the new place quicker. Actually, it’s probably not just leaders that want that, rather everyone wants that.
    1
  43. The other point is that leadership teams often don’t really care about the small details of how. Their focus is more on things like: how can we increase our market share, how can we increase profit, how can we attract bigger customers with larger growth potentials, what market segment niches should we be expanding into or getting out of?
    1
  44.  @zour2361  culture is like a river… it has a continual flow of momentum, so is hard to change.
    1
  45.  @HoD999x  LLMs aren’t the only AI techniques. Maybe a sufficiently complex LLM could gain enough emergent properties to do it. However, I’m placing my money on different techniques that do the things mentioned in my comment more efficiently, simply, and cost effectively.
    1
  46. 5:47 this is where I strongly disagree with the direction the software development industry is going. Product Management should be a specialisation of software engineering. The reason of simple: people who complete software engineering degrees are specifically taught how to gather and validate requirements and how to build systems based on those requirements. People who aren’t Software Engineer degree qualified just haven’t been taught the correct skills for effective product development. I find that people with the Product Management title are often under skilled and prioritise the wrong thing so they make many bad decisions because they don’t have good development and system design foundations to guide them. Likewise, Product management is often conflated with people management. The absolute worst part about the separation of Product Management from software development is when requirements development precedes software development; we return to a waterfall based model and loose our agile processes. We increase the time it takes to get feedback that validates whether the requirements were correct or not or whether tweaks are needed or not. Product Managers should think of themselves as forward scouts that gather information about the lay of the land and bring it back to the tribe for deliberation. As a team we can form hypotheses that act as our requirements, then we work quickly to build solutions that either validate or invalidate those hypotheses.
    1
  47. To what extent should logs and metrics be part of our data model vs separate from?? In my mind, log files seem to represent all the things we want to know but haven’t incorporated into our data persistence model. In theory, each log represents an actual event in our system that should match to a well defined process. Logs seem lazy; and incomplete solution. If we instead log these well defined events to a database, we can then query join and filter that data using one solution instead of using a separate log technology.
    1
  48. 13:35 wait what? Local unit tests and integration tests should give you a big clue if your changes are good or not
    1
  49. @Ned Gerblansky naaaw, thanks man.
    1
  50. I’m theory, iterative development doesn’t just apply to software, but also process change and information flow change. A company could try to completely design a new process and/or team hierarchy and replace the existing process in one fell swoop… but they would be better to improve iteratively. And like Dave always says, always test to verify the changes. The concept of TTD therefore and all the related refactoring techniques that apply to code, also apply to business transformation. That’s a pretty cool concept to think about! The assumption is that companies are just analog versions of software.
    1