Comments by "DR" (@dafyddrees2287) on "Continuous Delivery" channel.

  1. There are too many non-engineers managing software engineering. This would never happen in civil engineering or medicine. Fundamentally that's our problem.
    656
  2. 4:24 "We want replaceable developers and we don't want to train them." - What I describe as the "lightbulb model" of tech recruitment. i.e. hire smart but naive, highly motivated ("passionate") people that have learned the latest tech. Use them like lightbulbs. Get them to burn as brightly as possible and then throw them away and hire new ones.
    100
  3. In "lean" terms all the superfluous git flow branches are inventory we're holding onto. (Feature branches are pure "muda".)
    24
  4. I worked with 30 devs across Singapore, the UK, and the Western US - all sharing the same big codebase. We managed to work together closely and in all of four years we hardly ever needed to use a branch. We all shared the same codebase - with common ownership (i.e. anybody can change anything.) No need to "fear" anything - you just have to learn the XP way of working in a co-ordinated fashion. Branches are no substitute for working closely with other people. Now I know lots of people fear doing that and don't want to face the possibility of it - but it does actually work. My "nightmare" is not being able to get rapid feedback about things on separate branches working together - that totally kills my ability to refactor and simplify things. The code becomes very, very hard to change- and very quickly. Working with my 30 colleagues on a trunk is a lot easier because catching up quickly with changes - and learning to make small commits makes it much easier to refactor complexity away.
    20
  5. It is like smoking: people do what they are comfortable with. Even when there is evidence it is bad or the wrong thing. There are endless excuses to justify doing what people are comfortable with.
    14
  6. The first software jobs to be replaced will be tech recruiters. Even the real, live ones don’t know what they’re talking about, make snap decisions based on wrong assumptions and just spend most of their time employing sales tactics. If they behave in a manner indistinguishable from bots, I don’t see why not.
    12
  7. Should scrum masters, delivery managers and other people that have power over teams have a code of ethics too? Many of these people have a massive effect on how devs work.
    12
  8.  @_Mentat  Twice in my career I have been invited to do indefensible things to progress projects. “Can’t you just leave the debug port open? [on a live system]…. I promise not to come after you…” - is just the most recent. (It’s not just the insult - it’s that they think I’m stupid enough to enter into a “heads I win, tails you lose - hurry up” situation.) Please remember that James Liang now sits in prison in the USA after working for Volkswagen. Their management may deny involvement but how believable is that?
    10
  9.  @erikf790  The financial industry absolutely won't tolerate people that admit they don't know the basics of finance - yet for some reason boasting about not knowing about software engineering is a status symbol in our profession. I've heard more than a few people boast things like "I am above the level of software development". One woman I know in the UK civil service tells me she likes to hide how much she knows about IT because she thinks it would hurt her promotion prospects. If there was some sanity you would think that management should understand the basic concepts of the things they make decisions about. I'm pretty sure W. Edwards Deming was all about managers understanding the industry they are in.
    10
  10. I wish people would stop comparing every project with the Linux kernel. It's vanishingly unlikely most people are going to do anything like that - and yet the entire industry is out there gawping at Linus and copying everything he does as though it's gospel. 1) What he does is not the only way. 2) Linus is not a team player. He is a successful asshole that gets away with being an bully by having a successful, widely-used project. Most people need a team - with team players on it not assholes. 3) Linus can actually be wrong about things. 4) There's a big difference between working on a well-integrated team of trusted people and being a Linux kernel maestro assisted by a team of trusted lieutenants taking patches from thousands of the great unwashed of the world. There is actually a cost in terms of time and attention in serving as an open source project - that isn't necessarily appropriate even for most things.
    9
  11. I’m trying to promote the term “reluctant integration” (RI) for those techniques that involve maintaining lots of branches...
    8
  12.  @JuanRV73  It's quite depressing how development is reduced to "typing code" in the latest flashy technologies. It was never like that but almost always is treated that way by people that can't do it themselves - but are in charge.
    7
  13. McKinsey would not be the first company I would turn to for help with software engineering. If you want help with software engineering you could ask Google, Microsoft, Tesla or IBM. I would ask a company that is intrinsically committed to software engineering rather than johnny-come-latelies that are mostly about generic business management. Why is it credible for McKinsey to offer software engineering advice? What have they actually built themselves?
    7
  14.  @joek4563  I've been doing this for almost twenty years now and the difference between trunk-based dev and this gitflow bullshit is massive. You just can't do big system-level refactorings at all if you're going to have lots of branches. You'd either break everybody else or never be able to work fast enough to deal with all the conflicts you'd get all the time. The only option is to work WITH other people - not to temporarily hide away from them.
    6
  15. "Just Merge...." - phrase frequently said by people that neither write, understand nor merge code. This is what happens when non-engineers dictate how engineering is done. Having the power to force people to jump through hoops doesn't mean it works better.
    6
  16. “As a field, we are suffering from a ‘resource curse’: there’s too much money in computing and it dilutes our field with carpetbaggers.” — Lunch with Alan Kay
    5
  17. Nope - that's not continuously integrated is it? The risk is in the merges - and not understanding what other people are changing. If you wait until they've finished "their" feature (big problem already there with code ownership) then you're merging great big lumps of changes - which is asking for trouble.
    5
  18.  @joek4563  Great - now you have a broken build with tons of shit to track down. It will be much more difficult to sort out because you will be reconciling your finished work against the latest. Merges of huge amounts of changes suck absolute balls to sort out. It's much easier if you have to reconcile your tiny change against somebody else's tiny change.
    5
  19. When I first saw the gitflow diagram I felt sick at the sight of all those arrows. Every one is a potential merge hell. It's great for the "muggles" (non-developers) that worry about what's in a release but never have to use git directly to resolve a merge.
    5
  20.  @deanschulze3129  Where does corporate bureaucracy come from? What powerful people feel comfortable with. Under pressure people resort to it just like cigarettes.
    5
  21. Just wait until a "certified master" that doesn't know anything about development starts hassling you about why "can't you just merge it in".... and to add insult to injury said person usually doesn't even posess enough of an understanding of the concepts involved to be able to understand a straightwordward explanation... whilst simultaneously they're looking down on you for being a "boffin".
    5
  22. Thankyou so much. It's really useful to have a place I can refer people that mandate gitflow. (I had to revise this comment several times to remove swearing.)
    4
  23. There needs to be more to being a dev than fixing code based on “jiras”… and a lot of the interesting decision-making is in being trusted to design things. Unfortunately not that many people are trusted to do that.
    4
  24.  @zauxst  You obviously have never used “MercilessRefactoring” - you must just leave inconsistencies and design burps build up everywhere… or spend almost all your time merging. You have never tried to do XP and CI properly. Lol…. (Why are devs so soften arrogant pricks?)
    4
  25. It’s all good and fine to put forward a reasonable argument about education and thinking but the recruitment game is still a mindless frenzy of buzzwords and certifications…
    4
  26. You say "yay" now. Wait until you find out about pair programming though. There are no excuses when you can only check in work done in collaboration with another responsible person.
    4
  27.  @rajm1976  true. Usually they have almost ALL the power. We pretend they don’t have it and they pretend not to have it and that they don’t use it. We pretend we haven’t noticed that they use it.
    4
  28. … and this is compounded by all those non-technical people piling into the scrum industry…
    4
  29.  @Keilnoth  Feature flags are a bit of a worst case scenario because we don’t want a combinatorial explosion of switches undermining the usefulness of tests on a CI server. The trick is to build things in the order you want to release them and release very often. We did branch for hotfixes - at that point you are maintaining two different versions of the app anyway. We almost never needed a hot fix though - it happened very rarely, like once a year.
    3
  30.  @edwardcullen1739  "If you have large amounts of merge conflicts, then you have an architectural problem." - Not necessarily. Example: You realise that a class name is not as clear as it should be so you rename the class. This affects all the code that explicitly mentions the old name. That can easily cause loads of merge conflicts with other people. That's nothing to do with architecture. Also on a large system that's long-lived enough sometimes you have to refactor important mechanisms - is that an "architectural problem" or just a realisation that the system needs to change to accomodate new functionality? Either way - "keeping up with change" is very important. Saying a merge is no big deal misses the point - there's a stream of refactorings and changes coming.
    3
  31.  @YisraelDovL  to explain that I really would have to "bang on" about pair programming and why code reviews suck ;-) Code Reviews are for people that really don't like teamwork so they pretend to review each other's work - but often it's either "skim reading" or "nitpicking" or "sod it - let it all through". Please just try to imagine a world where everything isn't on loads of unmerged branches - and where people are disciplined enough to work together in tiny checkins that are individually releasable. I blame Linus for all the bullshit that comes with loads of branches and reviews - he certainly isn't a team player or a pair programmer ;-)
    3
  32. If the goal really is to create crappy software as fast as possible then maybe AI is the solution...? Maybe they will get what they deserve.
    3
  33. It’s not really so extreme. I call Scrum “moderate programming”: where “certified masters” with no relevant practical knowledge cherry-pick practices based on what will produce the most crap in the short term.
    3
  34.  @edwardcullen1739  "How often do you rename classes?" That's not architectural change - it's a trivial change that could touch loads of text across a codebase. Besides - I don't feel it's reasonable to partiton changes into simple ones and "architectural" ones. In a team of 10+ people - somebody will probably rename something every day - and that's not a problem with Trunk-based dev. We set things up to be able to handle change easily. You set this whole question up with the preconception that we need to avoid changing things - and that if we do it's "bad". That's the opposite attitude of extreme programming. We keep the code as small and minimal as possible - and don't hold off making simplifying changes. Code needs to be in a state where it can be changed, continuously in tiny increments that are visible to everybody. The more afraid people are of change - and hence build up big change sets - the worse changes are going to be - so people end up living with huge piles of crap because they don't want to cause "architectural changes".
    2
  35. "I would like to do a Better Job but my Boss Won't Let Me!" - This is because your "boss" is not a lead dev that could help mentor you. Your boss is probably a washed-up ex-lawyer or grubby salesman that retrained as a "certified master". One does not get delivery bonuses by letting the technical underclass have "refactoring" or "spiking" time. If you can move to an Extreme Programming team and leave that jackass behind. Sadly, this is becoming increasingly difficult to do.
    2
  36.  @Jheaff1  "Exactly. Is Dave suggesting we don’t do code reviews?" - not necessarily. Two options: 1) Pair/mob programming (i.e. continous review - which has lots of other advantages. and 2) Get your work reviewed one small commit at a time and get the other dev to review it before committing it back to master. (So, it's like pairing but asynchronous.)
    2
  37. I don’t want Intel fairies inside. ARM fairies get a lot more done without a lot of heat.
    2
  38.  @zauxst  I meet loads of people that do devops and dev “by trade” that haven’t ever learned to do things the XP way (including CI.) It’s pretty rare and getting rarer. You’re the one with the attitude problem here mate with your supercillious use of “lol” after demonstrating clearly that you don’t understand why lots of merging would be a problem getting in the way of “MercilessRefactoring” (yes, it’s a thing - if you dropped the attitude long enough to learn about it you’d answer your own question.)
    2
  39.  @itmartinwho  if I survey 100 random people in London and ask for their top ten list of software expert companies, how many do you think would say “McKinsey”?
    2
  40.  @rhys9336  I don't understand why you'd say that. Why is it "kind of crazy"?
    2
  41. Robert I. Sutton's "The Asshole Survival Guide: How to Deal with People Who Treat You Like Dirt", Penguin, 2018. - If you're a developer it won't be long before you need this book. If you want to be treated reasonably and with respect then development is not for you.
    2
  42.  @qj0n  You can't ever have worked on a scrum team then. A scrum master theoretically has no power - but every single one I've ever worked with for all the years I've done this has another job - typically a management one. The best example is: CTO i.e. pretty much power over everything technical including hiring people and finding new work. Often they are really project managers with the title "scrum master". Nevermind the theory, they pretty much always have power and are seldom afraid to use it. Worse, they often they have no dev experience which makes it even more difficult because now the project is run by someone that can only see things from the outside - which makes it pretty much impossible for them to understand the dev part of the project.
    2
  43.  @qj0n  Shit, maybe I should learn Polish then because scrum has had a very destructive effect here in the UK and in the USA.
    2
  44.  @SamirAbuLina yes there are loads of commits. What exactly is the problem you’re talking about?
    1
  45.  @edwardcullen1739  "Refactoring large amounts of code to implement a new feature" No. That's not what I said. One, indivudual renaming on it's own is enough to cause loads of merges - either for you or everybody else.
    1
  46.  @yaghiyahbrenner8902  how do you handle the stream of changes that arrive before you squash? How can you make lots of changes if you work in isolation from master? Don’t you either end up with a branch that’s hard to keep viable because you’re merging all the time?
    1
  47.  @edwardcullen1739  " if you've got a class that EVERYTHING is touching, then that sounds like a smell to me" Not necessarily. Real example: We had a product that almost 30 people had been working on for about four years.... It sent binary messages to hardware devices. The assumption was you could send multiple messages to devices to set them up and we had built a product on the basis of that - hey it had been working in almost every country in the world with devices from most manufacturers (with all kinds of abstractions to allow for all the different quirks and bugs of different hardware and firmware combinations.) Then it turns out, the biggest manufacturer of the device we were sending the messages to made a mistake in their firmware - and we'd have to set them up with a "single shot" message and they now had thousands (millions?) of devices that had wrong firmware. You can't build software to be completely general - you have to build on the domain you're given... and then one day some new constraint nobody has had before that will force a change. It's not some "smell" - i.e. a design mistake or oversight. Our requirements became more general i.e. 1) continue supporting existing services and hardware in the field and 2) support the new hardware that only works by breaking an assumption that had been stable for four years.
    1
  48. ​ @edwardcullen1739  "people pull-before-push, their merge will be trivial" I used to think that too. How do I get an isolated renaming into a gitflow repo? It won't allow me to make a trivial renaming in isolation. If I'm working on a story don't I have to package up all the changes on a feature branch into a giant change (that comes from squashing the changes on my feature branch.) If I follow the gitflow rules and my renaming is on the feature branch (because the rename occurs naturally as part of the feature) I get a great big change with loads of refactorings AND behavioural changes that no other developer will want to swallow when they review the PR. Now that is a nightware - trying to understand multiple refactorings AND behaviour changes all in one - i.e. gitflow actually making it hard to understand because all the changes have been concentrated together. I understand I could make a separate refactoring branch (if I knew in advance what I needed to refactor). I mean I could make an experimental throwaway branch and use it to work out what needs to be simplified to support the new behaviour and then create a series of "single refactoring only branches", and then make a "real" feature branch to work on top of that. The certified-professional-meeting attender class (i.e. non-engineers) won't like "single refactoring only" branches because forcing all devs to commit features as the merge of a single feature branch makes release management easier (at the expense of CI)... and of course refactoring and keeping the code simple isn't a problem for them so why would they care? I often see refactorings and how features could be really simple - and then remember that level of refactoring would never survive in a gitflow environment - so the other devs I work with never get to see how much simpler the codebase could be and I end up spending a lot of time being frustrated by working on code that's much more complicated than it needs to be and it can only get worse.
    1
  49.  @edwardcullen1739  "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." - I had a moderately small number of small, easy merge conflicts until gitflow was imposed. After gitflow I had either 1) no serious refactoring or 2) refactoring on the feature branch, squashed into a super-commit that is hard to merge because it's multiple refactorings plus changed functionality. It would be easy to merge even a big rename if it's ONLY a rename in the merge. It's a disaster if it's multiple refactorings and functionality - as would be the rule for anybody brave enough to do that in a feature branch. Gitflow IS the problem here. The sticking plaster is usually not refactoring anything - I'd rather use trunk-based development which doesn't have this problem.
    1
  50.  @edwardcullen1739  " So, you're against GitFlow then? So, what are we arguing about?" - Yes. I'm not sure how you got to that. I thought you were arguing for gitflow?
    1