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

DR
Continuous Delivery
comments

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

There are too many non-engineers managing software engineering. This would never happen in civil engineering or medicine. Fundamentally that's our problem.
656
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
In "lean" terms all the superfluous git flow branches are inventory we're holding onto. (Feature branches are pure "muda".)
24
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
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
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
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
@_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
@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
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
I’m trying to promote the term “reluctant integration” (RI) for those techniques that involve maintaining lots of branches...
8
@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
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
@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
"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
“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
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
@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
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
@deanschulze3129 Where does corporate bureaucracy come from? What powerful people feel comfortable with. Under pressure people resort to it just like cigarettes.
5
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
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
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
@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
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
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
@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
… and this is compounded by all those non-technical people piling into the scrum industry…
4
@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
@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
@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
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
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
@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
"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
@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
I don’t want Intel fairies inside. ARM fairies get a lot more done without a lot of heat.
2
@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
@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
@rhys9336 I don't understand why you'd say that. Why is it "kind of crazy"?
2
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
@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
@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
@SamirAbuLina yes there are loads of commits. What exactly is the problem you’re talking about?
1
@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
@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
@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
@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
@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
@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
@edwardcullen1739 I've never seen anything destroy my ability to refactor and to make quick fixes as much as git flow did. It's not that there are 10x productivity developers - it's that things like gitflow takes normal developers and multiplies their productivity by 1/10. It's very, very frustrating - given that most devs today haven't got an XP background they probably don't realise what I'm trying to do or how much I've been snookered by gitflow.
1
@midoevil7 "sometimes the business team is just not sure yet if it should be released now" - So you could 1) use a feature toggle or 2) A-B test if (if that helps the decision)
1
@midoevil7 "sounds as if the team is only working on one feature if there is an "order" ? - Usually in my projects clients have more work than we ever have time to do and they have to decide what things come next. In XP there's a priority order for stories inside an iteration but more than one thing being worked on simultaneously. Commonsense and teamwork is used between people to ensure we don't step on each other's toes because it's better to avoid unnecessary problems than to have to fix them.
1
@midoevil7 "What if the feature is cancelled, how can the team quickly undo the feature from the codebase ?" You might have to roll back one or more commits. Rolling back one isolated change isn't usually a problem. How much effort it takes to cancel a feature depends on how much needs to go - are we pausing something maybe to take a different approach or "not now " or getting rid of it entirely? It depends on the business. Working in small increments and releasing often makes this less of a problem than with feature branches. Scrum in general has provision for cancelling sprints and time for backing things out of a product (or at least making sure they're not in the way.)
1
@midoevil7 It's certainly easier to throw away a branch you don't need. I'd question why anybody would build up something substantial that then needs to be thrown away?
1
@melmartinez7002 every project I’ve worked on was developing multiple features in parallel. One of them lasted four years and had devs in three sites in three different time zones and we had 30 people pairing on different features on trunk. Did you really think I was talking about only developing one feature at a time? No. Seriously feature branching is not the only way to dev “complex” projects….
1
@melmartinez7002 I said “feature toggles” are a worst case scenario not “feature branches”.
1
@melmartinez7002 Let’s not “straw man”, heaven forfend. You said “In many scenarios, multiple ‘feature’ efforts being developed in parallel are very much the norm”. Me too! Multiple features by many people, in parallel on trunk.
1
@melmartinez7002 "They can result in shipping unused code" - ah, my favourite refactoring: "remove spurious shit" ;-)
1
@danm6189 did I tell you about pair programming? Hi Dan - I think I know who you are ;-)
1
@vyli1 1) Pair programming IS code review. Continuous review and that is better than review when it is too late - as happens most of the time with branches. 2) "if you use trunk based development and you are working on a MASSIVE refactoring, you're in fact still in the risk of having tons of merge conflicts" That's possible - and that is why you have to work WITH people instead of pretending they don't exist for a while. How we have staged MASSIVE refactorings in the past: i) tell everybody in advance - have a discussion and make sure everybody is on board. Everybody gets a say because of "common code ownership". ii) on a specific day (preferably a Friday) have an agreement that we won't be attempting anything big today. Get everything checked in (and the build passing of course because that's expected) by mid day. Use the rest of the day to plan, investigate, experiment, spike - anything but DON'T leave any unused code around. Devs of course aren't glued to specific stories so they move around as needed to HELP EACH OTHER clean the decks. iii) when everybody is clear, and if necessary on the next day (Saturday the day after the decks have been cleared) send in a pair to do the refactoring. It should be purely just that refactoring in isolation. It could be as simple as "rename commonly used interface" or "split commonly used interface into two parts". The goal is to restate the entire codebase in the new terms. NOT adding functionality, NOT changing functionality. The purer and simpler the better. This won't cause a problem if the entire team as cooperated. There won't be any fighting or crying because a consensus was achieved in point i) - and there shouldn't be any broken junk because everybody helped each other clear the decks before this was done - due to point ii) iv) the refactoring pair need to hang around and make sure the build goes through - and validate that refactoring helps them express what they need. (There must have been a justification in point (i) right?) v) when everybody gets back in the refactoring pair can spend some time rotating around the pairs helping anybody that needs it to get up to speed There's no technical fix to making big changes - only minimising the impact which involved working MORE closely with people rather than hiding behind branches. "Other people working off from trunk not having your massive refactoring code available will still have problems" - I worked for about four years on a huge codebase with about 30 developers. We almost NEVER had another branch running alongside trunk. We branched very, very rarely and then for the shortest possible time. I can see that it would hurt if we branched a lot - so don't do it eh? Trunk-based development. "Trunk doesn't save you here at all." - oh Yes it did. It worked consistently for four years - with about 30 developers in 3 different timezones, with multiple customers and all developers jointly owning all the code. Not only is this possible and I have done it multiple times - but it's teachable. 3) "if it is such a massive refactoring, there's a slight chance (although I admit often it's not possible) that the change can actually be split across multiple small feature branches" You're not gaining anything here - you just like to have branches. If you want to make things hard for yourself - go for it. What pisses me off is people forcing me to do things that are riskier and less efficient because they can't imagine a better way of doing it and are determined not to listen to people with my experience. 4) "how do you protect developers from accidentally pushing changes, that fail to build the project?" Design and code are a team activity. Programmers are not typists - when you design code in a pair you have to explain your ideas to somenbody else. That's usually when you discover that it's not as well thought out as you assumed - because explaining it is harder than you think and the other developer probably can see things you can't. Fixing the design and reviewing the design is a much deeper activity than you can expect a tool to do for you. At very least, there's a set of unit tests and acceptance tests that you run BEFORE you check in - and then the CI/CD pipeline runs to verify that everything stacks up consistently. "It's fairly easy to do with feature based approach" Bullshit. The "feature based approach" means you can't actually do many refactorings that I would normally do and that means that I have to leave the codebase messier than it would otherwise be. The bigger factor that nobody talks about is also that developers are pitted against each other with the "feature based approach" because reviews are adversarial whereas TBD with pairing is about cooperation - i.e. both devs are working to get it done rather than one person "owning the change" and another person being "captain nitpick" when it's really too late to have any real influence (and not enough time anyway to really get stuck into critiquing a desing properly.) Git is designed to support Linus - and he's not a team player. The team is there to support him. That's the opposite way around to how we're supposed to work in most projects. Just because Linus does something doesn't mean we should.
1
@christophjahn6678 A valiant attempt but the certified masters will single you out as a rubbish Dev for taking longer. Quality and reliability is taken for granted until it deteriorates to the point that it can’t be any longer.
1
@Invatator No. "Local copy" is a clone of master. No unnecessary branches. We do not want to PR every tiny change and we don't want to manage a separate branch - because we want to integrate continuously not only when everything is finished and it is too late.
1
@Invatator " "tiny change" needs to have it's own ticket/change request, for traceability, audit," - Bullshit. You've never practiced extreme programming have you? If I did that I would spend 50% of my day shuffling jiras or index cards. Nobody would ever tolerate that. Audit? Funnily enough, my team did get audited by one of those ISO process audit guys - and he was perfectly happy with traceability with us all working on trunk.
1
@Invatator "With forking you don't need to "keep a separate branch" if they are short lived, purged at the time of the merge." - No. If other people in the project are also committing small changes and refactorings you will have to keep up with a stream of tiny changes from other people. Now you can add in a whole bunch of unnecessary process shuffling updates or work closely with other people on a single branch. I'm not saying you have to do trunk-based development - do what you like, but continuous integration means everybody working in synch on a common codebase, not pretending to work in isolation - even if only for a short while. CI just works better if we avoid unnecessary branching. This whole thing of copying how Torvalds works is so wasteful and damaging. Why does everybody have to pretend to be maintaining a huge, high-profile open-source, general purpose operating system - almost nobody needs to work like Torvalds. So much damage has come from the celebrity endorsement.
1
@Invatator "Give it a try, practically, brcause theory is riddled with logical falscies and whatnots..." Oh really? I don't have much time for theory but I have about 7 years of working with trunk-based development successfully in three different industries. Why don't you park your ego and consider that you don't know everything?
1
@Invatator " this is getting ridiculous, and childish." Yes, I agree. I don't understand your problem here. You say you want every tiny change to have it's own ticket/change request.... and then you tell me you've done "extreme programming" and that "is apparent that extreme programming concept is different amongst us". It's apparent to me that you don't know what you're talking about. You may well have loads of years of development - as most of the gitflow advocates do but so what? We're talking about why gitflow sucks and why CI with tiny incremental changes on one branch is a much better proposition for CI. From what you've said it's clear you've not actually done anything remotely like XP - but that's okay - branch all you want. That's all your problem - but that completely ignores what Dave was saying about CI working better with the whole team working incrementally on one branch.
1
@Keilnoth Normally we pair/mob with people in our timezone. Occasionally we'd pair with people in other timezones - but time lags with large distances over the internet tended to make that painful so we used to limit it. Most companies (at least until recently) used to keep subsystems within one geographical region even if they have to integrate things between regional teams.There's an argument that pairing/mobbing is more difficult done remotely and because of that there's more need for documentation and modelling. That may well be true. Distributed development certainly isn't free like a lot of non-developers seem to think. For one thing, turning on line numbering and referring to things explicitly helps (to prevent misunderstandings) and pausing frequently to check the other person understood what you did/said. That makes remote pairing/mobbing much slower - but I'd rather do that than just hope everything was understood and face a mess later when it isn't.
1
@andrealaforgia5066 "I would question the decision to create a team of people who cannot effectively work together." Sounds like that's generally true to me ;-) It's certainly easier to do distributed dev if the timezones align. People have this fantasy that because it's "agile" they can play fast and loose in all kinds of ways and still expect effective working software. Something always has to give. Remote dev may well require slower collaboration and more documentation - a shame so many people aren't prepared to face up to that. They're happy to eliminate pair programming but they're not so ready to reinforce what's lost with effective documentation and effective, meaningful work tickets in something like jira.
1
@Invatator "you're far off in your assumptions, and understanding on what I was saying" - You said : "tiny change" needs to have it's own ticket/change request, for traceability, audit, etc" No need for me to "assume" anything. That's just plain crazy right there. That makes no sense to people that have been doing XP. You said " it sounds/reads like your proposition is "you can't do CI with XP"" - I never said that - and I never suggested that.
1
@Invatator "if 2 dev work on same base code touching the same files each doing thier own changes, it means the base code breaks one of the SOLID principles, or the division of work, split of the tasks is not done correctly...you're bound to have clashes - inherently!!" - Yes - most days there will be conflicts and that’s not necessarily anything to do with breaking the SOLID recommendations: All you have to do to clash is rename a type. The trick is to make the changes tiny enough so it's easy to deal with. The fewer differences there are between the code on each dev machine the easier it will be. We want to flush changes through the system easily and keep syncing up regularly.
1
@Invatator “just because FANG use it…” We were using it before any of them and we wouldn’t have cared less. We adopted XP because we read the c2 wiki and saw a lot of practical wisdom in it.
1
@Geza_Molnar I really resent this idea that management isn’t part of being an engineer. I know lots of people that did engineering degrees that spent time in the business school at university learning things like project management and finance. Software engineering isn’t coding any more than electrical engineering is soldering. Brunel for example was a famous engineer- he also financed and ran very, very big projects with all sorts of large teams. Those skills were an inherent part of getting engineering work done. The dumbing down and infantilisation of technical subjects needs to stop. Just because we have tech degrees doesn’t mean the skill set is only about doing technical things. There are committees in university that try do design a curriculum to produce well-rounded professionals - yet the industry seems incapable of grasping that.
1
@Geza_Molnar of course you can.
1
@dorcohen3522 I am one. Bringing in a "certified master" very often creates the excuse that software engineers don't need to try to take responsibility for making the team work. Often the "certified masters" preach the doctrine of making the team self-reliant whilst actually making them dependent on this glorified meeting facilitator. The biggest step forward we took as a team was when the team lead we idolized left for a better job and lots of different people within the team had to step up in different areas. There was a lot of growth because we couldn't all rely on one person to do it for us.
1
@dickpiano1802 1) Yes - it isn't engineering. It's nowhere near professional enough. 2) Not so sure. What I have in mind is that serious professions are led by qualified people (even if they aren't hands on any more.) The board of Rolls-Royce for example (one of the most famous engineering companies in the world) has about 60% having a very technical background. The important thing there is that if there was a problem - there are enough senior people capable of gasping what's important. In the software world - we've reached a point now where it is assumed all the technical people do is code. I know people in the British civil service that actually hide how much they really know about developing software because they are afraid it would hurt their promotion prospects by being seen as a "boffin".
1
@dickpiano1802 I didn't think you did. It's okay 🙂
1
@nobody27019 no. That’s not an argument over the practice of medicine. That’s an argument over paying the bill. If the insurance agent strolls into the operating theatre mid-operation and starts telling the surgeon to stop “wasting time on hygiene” or how to use the instruments then it’s like non-developers telling devs what branching strategy to use and that a “release train” or a “cleanup sprint” is a good idea…
1
@nobody27019 Insurance isn't a medical issue - it's a financial issue. They do not decide medical procedures - only financial matters. I live in the UK where very few people have medical insurance. Not everybody lives in the USA but even there, insurance doesn't decide how treatment is done - just what they will pay for.
1
@nobody27019 "The patient doesn't listen to the doctor, and dies as a result. Who do we blame here?" - Tragic things do happen and it isn't necessarily anybody's fault and in those circumstances it's legal argument about the terms of the insurance contract. It's not necessarily a professionalism issue.
1
@おす-qz7kp not necessarily. But we have reached a point now where most people managing this kind of work have very little idea about the basics - the kind of basics found in a simple, first-year undergraduate course on software engineering - like knowing what’s in books like “The Mythical Man month” and “peopleware”. That level of ignorance makes managers easy prey for snake oil salesmen like McKinsey…
1
@GabrielGosselin It's a good idea that managers know more than nothing about the things they will be making business decisions about. Deming would agree with that - but it seems that many business schools (and McKinsey) don't.
1
@KT-dj4iy I don’t know for sure but a lot of good technical people I have worked with don’t want to do leadership/management work. In a few cases it’s sad because I think they’d be much better in charge and would be able to help improve other people and help on a team level.
1
@ContinuousDelivery When you see people attempting to do CI with gitflow and have zillions of branches being built - that's when you know CI has gone through what Alan Kay called "the great low pass filter of life" ;-)
1
@orlovskyconsulting yes, but it’s still pretty simple stuff. I wish it hadn’t been elevated into a religion. I was joking about Dan suing Tony Hoare. But it really is time to understand that it’s just one approach and that there are lots of other ideas - some of which could be better.
1
Lots of things done in the software development industry don't make sense. One reason people would do that is that they are all about getting their "own" feature into trunk and they only see other people's work as something that holds them back - not as part of a team building something together.
1
... but they still don't want to do it right? The stats and the logic aren't the problem...
1
7:30 - Dave cackling like a naughty boy...
1
@itmartinwho I did some work for Sainsbury's IT a little while back, they also have "lots of engineers and data scientists". Many big companies do. That doesn't qualify them to give expert advice. IBM for example has been in the software game since the 1950's. Microsoft pioneered the idea of being primrily a software company- and have been making software since the 1970's. That's a totally different level of experience and expertise. I really wish the business gurus would stay in their lane and stop crapping in our sandbox.
1
@zauxst No - you can't properly do CI with separate branches. It's not "continuously integrated" is it if there is no single, up-to-date potentially releasable thing. You have two or more different realities - and a bunch of risks hanging in the air about how to merge them....
1
@zauxst "The releasable item is in the dev or master branch waiting to be merged in the release branch or added the release tag." Not really. That would be true if devs weren't working on "feature" (ha) branches. You don't incorporate your changes back into the product until it's "finished" (ha - also not really true.) So there are big "lumps" of merging going on - between those your changes do not get back into the product. You should be able to design the product incrementally so your changes can be checked in on master incrementally. This is possible. I did this for four years - whilst working with 30 developers - sharing code across three timezones. It works far better than branches - which suck because of the extra risk and overheard - and generally because of the lack of close collaboration. "Small itineration will get the work done" - yes - so just design your code so the system can tolerate tiny design changes in each separate checkin. No need for all those branches and ceremony. You can still create a release branch if you need to - but we don't want to be merging huge loads of shit across branches all the time like in gitflow.
1
@zauxst "gitflow does not dictate merging huge branches and reviewing them" - whilst that's technically true it does set up circumstances where real people are likely to do that a lot. I agree that code should be minimal - BUT it's even more minimal without the need for branches. It's entirely possible to work one commit at a time - and to design code that makes that possible. I have done more than five years of that - and it allows for better team co-operation, more incremental design and makes it possible to do bigger, more ambitious refactorings that wouldn't be possible with lots of branches. TBD is the better way to do things and the way that extreme programming is intended to work.
1
@fluffysheap that analogy just doesn’t make sense.
1
Most people want to hire people bright enough to be able to cope with the mess but not intelligent enough to refuse to keep making things worse for short term gain. If software maintenance was taken seriously i.e. boldly decide to delete crap, fix or rewrite what they rely on or need - then recruitment and retention wouldn't be a problem.
1
@georgeokello8620 Lmao - I know that. I am agreeing with him dimwit.
1
@LPFan33 I am agreeing with him, dimwit. Not my fault the reply I got didn’t make sense.
1
9:59 "Hell is Other People" - Dave Farley 😂
1
What skills are in demand? Fixing horribly botched software under pressure or designing something new? Everybody talks about making new stuff but I suspect what’s in demand is rapid-fix-it services and people that can read specifications out of impatient people’s minds. Writing more new crap isn’t likely to be the problem.
1
? is_better_than(logic_programming, oop), is_better_than(logic_programming, fp). No.
1
@vyli1 "healthy functional team this is not a concern at all." That's a very subjective thing to say. All the TBD I've worked on has been awesome and all the branch-tastic stuff has been awful. It corroborates what Dave has been saying in his books and videos.
1
@jangohemmes352 You have to be intelligent to be a dev but unfortunately people assume that you're not streetwise, or naive or autistic. It's exhausting when they do that.
1
A professor of Computer Science once confided in me that he thought “Objectory” (the software method) was like cult - with loads of courses and status levels and you had to pay to go up to the next level. I often wonder what that guy would have said about Scrum…
1
We are always racing to learn shiny, new expiring assets…
1