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

Daniel Sandberg
Continuous Delivery
comments

Comments by "Daniel Sandberg" (@ddanielsandberg) on "Why Pull Requests Are A BAD IDEA" video.

The seven points you brought up all have one thing in common: They are feedback that something is wrong. You present them as problems when they are actually symptoms of cultural and technical issues. CI, CD, agile, etc also have one thing in common: To give everyone a healthy dose of reality and force you to do something about it. Flaky tests? Fix them! FFS! Slow build? Fix it, but don't fret over "a few minutes", you probably spend 10 times more time per day checking Twitter and getting coffee than a few minutes of building. People are force pushing? You allow that? Every SCM tool I've used supports to block force pushes (BitBucket, GitHub, GitLab, etc). Etc... sigh... I guess it feels easier to sweep the symptoms under the "rug of PR" instead of actually fixing things.
14
 @pgeorgiadis2 Wait, what makes you think that pair programming costs 100% more?
6
You do! You run the tests. You make sure to merge other peoples changes from remote/main to your local clone many times per day, and run the build, unit-tests, linting, and functional tests *before* you push to master. That way you know if there is a conflict before you push. This is the prime directive of CI - check your sh*t before you push. And if it still breaks on the build servers, stop working, drop everything and fix it, or revert the breaking changes within 10-15 minutes to unblock the rest of the team. If you can't do these things on *any* environment you need to fix that.
4
@OlleHellman The reason I'm asking is that basically everyone in this comment section seems to think that CI is a tool, running "checks" on a build server against your feature branches. That is not CI, by definition. You don't "run through CI". You don't "have CI". You don't "use CI". You either do CI or you don't! CI is a practice and a social contract *not* just a build server even though tool-vendors would like us to think so. Everyone integrates their changes into the *mainline* , at least once per day (preferably more). Unless it's merged into main and automatically verified, it's not integrated. If you can't run a majority of these checks on you local environment before committing, you *can't do* CI. Running checks against a feature branch is not CI. Sorry, but I'm adamant about this because our industry has gotten into this bad habit of redefining things to mean "whatever we are doing right now". - We installed Jira and have burnups, burndowns and user stories - we're agile. - We created a new team called "DevOps" and hired "DevOps engineers" - we're DevOps. - One write code, then someone else looks at the code, then we change the code, then we PR the code - we're pair programming. - We are running Jenkins against "whatever we are doing with branches right now" - we're doing CI.
3
@adagio1980 If a simple revert doesn't fix it and it takes 10 hours to fix you probably stumbled onto a nasty systemic bug that no one knew about. Concurrency, transactions, etc... Since we in CI talks about "push at-least once per day, preferrable multiple times per day". The amount of "work lost" if that is left on you laptop while you're on vacation is neglible. The amount of times I've started working on something on Friday afternoon, got stuck, went home, came back after the weekend and just deleted whatever I was doing last week and then implemented a much better solution in a few hours...
3
@PelFox Yes, Trust is part of being in a team. People makes mistakes. That is life. It's messy. Deal with it. As long as people improve over time and it does not become a bad habit of being sloppy you will be just fine. If people keep being sloppy, your technical team lead need to have a serious talk with them. E2E tests are usually to expensive to run locally, but that is fine too. What is important when acceptance tests fails later in the pipeline is that people stop doing what they are doing, find out what is wrong, swarm around it, fix it and see if they can improve the pipeline to catch it earlier. "Keeping the system in a good/deployable state is more important than daily work." I.e. fixes and improvements are more important than checking off another feature from the todo-list.
3
"asynchronous pair programming" is just an attempt to redefine pair programming to fit some idea that pull requests must be. What do you think pair programming is? Just two people working on the same task?
3
@oliverrushworth702 I would try to make the team focus on throughput and result instead of on individual contributions and "number of tasks/features delivered". The team will then kind of have to focus on technical practices (CI, PP, TDD, etc) to keep the system releasable over time as well as promoting certain cultural changes (see "blameless postmortem" for example). Rinse and repeat and continuously improve. Within a year, your team will run circles around the rest of the organization. Two of my favourite talks are "Sleeping with the enemy" by Gojko Adzic and "Beyond developer" by Dan North. The first one is about programmer/tester relationship and Gojko also wrote a couple of books on the subject. "The three amigos" being one. Dan has many talks around team, org culture, and "soft skills", etc.
2
According to some "old IT/tech people on Twitter" the amount of programmers doubles every 5 years. About 10 years ago everyone went nuts with FB/PR/GitFlow. Thus we can extrapolate that 75% of all programmers in the world have never done anything but FB/PR and so have never done or seen real Continuous Integration. Yikes.
2
Copy paste of my other answer: You do! You run the checks. Before you push. You make sure to merge other peoples changes from remote/main to your local clone many times per day, and run the build, unit-tests, linting, and functional tests *before* you push to master. That way you know if there is a conflict before you push. This is the prime directive of CI - check your sh*t before you push. And if it still breaks on the build servers, stop working, drop everything and fix it, or revert the breaking changes within 10-15 minutes to unblock the rest of the team. If you can't do these things on any environment (including your local env) you need to fix that.
2
Seems like you are making the same mistake that managers have been making for 30 years. Thinking that programming is typing and that the goal is output rather than outcomes. Failing to take the entire system, for the lifetime of the software, into account. Wait until you hear about mob/ensemble programming where the entire team, POs and all share an 80-inch screen and one keyboard.
2
@appuser Not sure how to answer that directly... I can say this: Pair programming is not - two - people - programming. Pair programming is "two people programming". It's collaborative, not cooperative. It's the difference between having fun with your friends and having fun with your spouse. That doesn't mean everyone spend all their time pairing. It's like a relationship, we spend a lot of time "collaborating", but it's occasionally punctuated with times of alone time and deep focus. You'll probably end up divorced if you insist that your spouse spend all their time with you and vice-versa. It's like everything, it takes time to learn and get comfortable with. If you have never pair programmed and spent your career "sitting alone in your corner, with your headphones on, typing code" it's not easy, and quite frankly you've been mismanaging your job. Deep collaboration and high bandwidth social interaction is a very important part of SWE. Unfortunately too many of us thought that working in software would be the same as when we got into it as a hobby. We were either lied to, or lied to ourselves. We are not getting paid to do our hobby of just writing code and it's easy to be disenfranchised when it turns our to be different than we thought. And thus we tend to invent all these handoffs and roles where we push the uncomfortable things away... we add layer after layer and build walls and "specialist groups", all so that we won't have to change and do that scary thing we don't really want to do... And that is what I reacted to; I interpreted it as if you wanted to add yet another specialist group to avoid changing/keep the status quo. I may have overreacted... 😕
2
@appuser Yes, you expressed it so much better and concise than I ever could: "trying to engineer a solution to avoid some kind of social territory". I'm going to steal that instead of writing a frustrated whitepaper every time. :)
2
This has been brought up many times on his previous videos about branching and git flow. The answer is still the same: 1. All the different feature branches will *not* be integrated with each other since they are isolated until they are on mainline. Until it's on main, it's not integrated. 2. The unit of work in FB/PR is quite large and is regarded as a "complete whole". In CI/CD/TBD we see the unit of work as a (couple of) small commits, many times per day, so that everything is always integrated and tested, even if incomplete. 3. If you really must work that way, fine. Still not optimal and it's not CI whatever anyone calls it. There are better ways... Conflicting perspectives: - FB/PR proponents views this isolation of changes (and programmers working alone) as a good thing. - CI/XP proponents views this isolation as undesirable and a fault in the system of work.
2
Open Source is a different context. Linus created Git to slow down changes *because* he's the author of the biggest open source project there is - The Linux OS kernel. FB/PR was built *for* open source, where you have 1000's of unknown contributors all over the world and a few trusted committers. Pretty sure Dave said [paraphrased] "async, pre-merge, blocking review using pull requests in your *team and organization* is where the problem lies." And I don't buy the "introvert" argument for one damn second. There are two sides to that argument. 1. It's used as an excuse so that developers can sit alone in their corner, with their headphones on, writing code in isolation, getting paid to do their hobby. Probably why FB/PR has become so popular... It avoids interactions. It defers integration. 2. For 50 years the industry has been built on the notion of "the lonely geek" and the "superhero programmer"; attracting a certain kind of personality. If the situation is that "people can't collaborate with other humans" we probably did that to ourselves and it's time to stop digging the hole deeper. Programming is fundamentally a social activity and too many of us thought that choosing it as career would mean to continue what we did when we learned on late evenings in our rooms when we grew up. It's still a job and we have to do things that's uncomfortable. We need to become much better of getting out of our comfort zones. That doesn't mean we need to sit in each others laps all the time. Most of the time we should pair and collaborate in small groups, punctuated with moments of deep focus work alone or pair. It's not all or nothing. PS: I'm an outgoing introvert.
2
CI is not just merging. CI is a human practice and it's not CI unless it's merged INTO master several times per day. Can everyone just stop redefining CI to be "whatever we're doing with branches right now"!?
2
It's scary actually. According to some "old IT/tech people on Twitter" the amount of programmers doubles every 5 years. About 10 years ago everyone went nuts with FB/PR/GitFlow and thus we can approximate that 75% of all programmers have never done or seen real Continuous Integration. Yikes.
2
I have no answer shorter than an entire book on this... The problem is if team members are working on multiple projects at the same time then you don't actually have a team. That's like having a football team playing 5 different matches at the same time. This is a symptom of something being wrong with how things are prioritized and/or how the organization is structured... The job of a senior/lead is not to gatekeep, to check everyone's work and approve of it. A senior can't behave like a curling/helicopter parent and protect juniors from themselves all the time. That tends to hold back peoples learning and growth, and also teaching people to not trust themselves. You need to find a way of working where everyone can contribute, learn and make mistakes, without a senior handholding them or taking the company down in the process. I don't care what that is, as long as it's a minimal measure and not someone gatekeeping everything (the seniors might as well do all the work by themself in that case). You should be able to find a way of working where in the end "everyone" would make similar (or better) decisions, even when the seniors aren't in the room. After all, the job of a senior engineer is to create more senior engineers. There are no "do this"-answer except "get good at pair and group programming" and build "defenses" into the system of work so that the blast radius of mistakes is as small as possible. Dave has another video here "A Guide To Managing Technical Teams" and Dan North has a video from "Goto conference" called "Beyond developer", check them out and show them to your team next time you have a "tech friday" get-together.
2
@moodynoob Yes, Google is an extreme example. Which is why I mentioned that they have a lot of tooling. The OP noted that he couldn't image how to scale it with 150 people and I simply gave counter argument that it can scale just fine. Monorepos is complex so I avoid "singlular organization monorepo", but I really like to put all the client, backend, DB, integration-test and deploy code into a single self-contained repo. In Sweden we have an expression "dumsnål", which basically means "stupidly cheap". And so is the case when management don't want to pay for good tooling (among other things), but have no problem hiring tons of people instead and adding 15 layers of handoffs and start a new "rewrite the system project" every 5 years... 🙁
2
Run the full build and tests locally before every push! No need for branches.
2
Sounds horrible! :/ As the old saying goes: "You can Change Your Organization or Change Your Organization".
1
99% of all IT companies wouldn't know agile if it hit them in the face. Most companies thinks it's just a process and takes all the "easy parts" from scrum, skips the good parts from structured SDLC and ends up with the worst of two worlds. Thinking that burnups, burndowns, boards, jira, standups, story points, user stories, sprints, etc. makes them agile. They ignore all the technical practices from XP, CD, et al. (that is required to make it work) and then wonder why it didn't. Then people come out on the other side saying "I hate agile". Like my grandpa - he refused to try pizza his whole life. A few weeks before he died we asked him why he never tried it - his answer? "It's just a pancake with ketchup and cheese!".
1
CI is not a build server or a tool.
1
And if it's rejected you have to switch back, remember what you did maybe 3 days ago. Fun. People are obsessed with busyness and chalking off tasks from a todo-list. The problem is that we are really *not done* unless it's running in production (or at-least staging). But people love to "implement tasks", then pass it to PR/test and pretend they are done and move on to the next task, when in reality nothing is done. You should really read about one-piece flow and theory of constraints and how inefficient async blocking workflows actually are. And no, you don't "run CI", there is no such thing... And unless the code is merged into main, any result from a build pipeline is irrelevant.
1
Then show us the data that Feature Branches and Pull Requests is the best, optimal, most effective way to deliver high-quality software *outside* of open source.
1
@fringefringe7282 So why the mocking of "the data says"? Nothing personal, I responded that way because all the time CI/TBD gets mocked as "won't work in the real world" and I'm getting so damn tired of it! Ok?
1
@fringefringe7282 Well, I think it would have been better to have had a discussion arguing the point rather than immediately devalue the data before even looking at it. There's probably a bunch of logical fallacies going on here on both our parts. TBD = Trunk Based Development. Anyway, let's go our separate ways. It's taco friday. :)
1
"...and I don't have to run them on my local machine" is a red flag. Let me explain. If it is difficult to run the build and tests locally, if it is slow, if you have to perform 17 manual steps, if it downloads the internet - that is feedback. That is THE feedback you should LISTEN to. One of the major points of a local build is to act as an artificial constraint to expose technological, design and workflow issues. Replacing the local build with a PR build on a build management system is a band-aid so that people can avoid fixing the real problem.
1
While I will try to answer this without purposely being offending, you may feel that way anyway. Your job as a senior/lead is not to gatekeep, that is, to check everyone's work and approve of it. You can't behave like a curling/helicopter parent and protect juniors from themselves all the time. The only thing you'll end up doing is holding back their learning and growth, and also teaching them to not rely on themselves. You need to find a way of working where they can contribute, learn and make mistakes, without you handholding them, nor taking the company down in the process. I don't care what that is, as long as it's a temporary measure and not you gatekeeping everything (you might as well do all the work yourself in that case). You should be able to find a way of working where in the end "the others" would make similar (or better) decisions as you would, even when you aren't in the room. After all, the job of a senior engineer is to create more senior engineers, not dissuade people and having them leave within a year. Dave has another video here "A Guide To Managing Technical Teams" in which he calls your style "programming by remote control".
1
CI is not a "build server". CI is not "running checks on your feature branch". CI is not "rebasing/merging into a feature branch". Can everyone just stop redefining CI to be "whatever we're doing with branches right now"!?
1
@WildfireS1 I would start by reading the Continuous Integration article on Wikipedia. CI is a practice and a social contract. Unless the changes are integrated into mainline multiple times per day, triggering a build, linting, checks and tests, and output a versioned deployable "artifact" (or at-least a tag), preferably built *once* (as in opposition to have different builds from different branches for different environments) - then it's not CI. Jez has a very simple description here on youtube watch?v=IvWr29afDF8&t=270s
1
So what is CI then? Define it please.
1
That is just a band-aid that avoids the real problem - that the team/organization can't keep the system in a working state. Wasting testers time testing unintegrated code instead of fixing the systemic problems.
1
@oliverrushworth702 Unit and acceptance tests are a way better way of keeping a system in a working state than using branches and lots of testers doing manual regression tests. Testers time could be used better on exploratory testing and talking with programmers and SMEs. And if your team has 10 programmers and each sit around with for example 2-3 waiting PRs and one active feature branch, you'll have 30 unintegrated changes sitting around. How will they know if their changes conflict and break something even if they rebase off main? They won't; until something is merged into main, which has a tendency to be more or less seldom. And in worst case you'll spend another day trying to get your stuff to work again and it's a race. Branches are used to isolate changes, CI is used to integrate changes and fail early.
1
You don't get to redefine "pair programming" to mean what you want it to mean.
1
Why the assumption that CI+PP means sacrificing quality? CI and PP does not mean that there is no holistic review or that any issues with the structure of the code just sits there and rot. Please do a whole team review of the state of the code base a couple of times per month. Make an action plan, refactor mercilessly, redesign as needed, fix small issues as soon as they are spotted, and continuously improve. CI requires that everyone gives a s**t. You can no longer commit half-a**ed code and leaving it broken for days on end. It must always work. It enforces code-hygiene and care. The problem is that programmers that has only ever worked with FB/PR often falls into the "build trap". The belief that you get ONE chance to get it right and need to polish the code on a branch for a while, have people cast judgement on said code (after the fact), then merge when "approved" and NEVER LOOK BACK AT IT AGAIN. That is the damn problem. If the team spend all their time building the next thing (because incentives and whatnot) and don't care for the state of the system or know how to refactor and improve as it evolves you're screwed anyway. And to start working on the next thing while waiting for review does not make you faster. It just wastes time because now someone have to stop what they are doing to review it, then you have to stop working on the next thing to fix "suggestions" people have on the PR.
1
Huh? Are you OK? I suggest talking to a psychologist.
1
You are forgetting one important aspect: Positive feedback loops. Maybe it's not about "hire people that don't make mistakes" and instead building a culture of learning and continuous improvement. Maybe it's not about "trusting themselves, or others" but creating an environment where mistakes has a limited blast radius and there is safety with no blame games. Maybe it's not about "agile, CI/CD, or whatever" but in having an attitude of "we have to figure it out and *change our thinking and beliefs* as we learn more". The point is - CI/CD creates a positive feedback loop that gives everyone a healthy dose of reality and forces you to change what and how you do things. This tends to lead to taking many more smaller steps, more and smaller commits, more pair-programming and collaboration, better and faster tests, simpler design, etc. which leads to less mistakes and higher trust and less fear. 🙂
1
Sounds excessive! Maybe time to re-evaluate your career choices if you find it that hard to collaborate and interact with others. Software development is after all a social activity. This comment makes me sad for our profession. :/
1
- Where is he just throwing more money at the problem? - In what universe does pair programming means a new job description where someone sits behind you and barks? - So having two people work in isolation and then adding a third person, that does not have the context nor the insight of the design decisions, cherry-pick parts into a whole is "not throwing money at the problem"?
1
You want a "more direct and frequent line of communication and more hands-on interception of incoming code... with the reviewers to be specialized in reviewing and suggesting/alterations"? And if you do that at real-time, at the same desk, you just described TBD/CI with pair programming. But I know what you really meant and this is the same trap that SWE has been falling into for 50 years... Sigh.
1
@prdoyle Wall of text incoming - duck and cover! 1. Sure, but it is not integrated until it's ON main. 2. Even if you rebase your branch, you still only check integration with what has made it into main this far. Everything else that is not on main is an unknown. As an example: If everyone "merge into main" at the end of the day or end of sprint, you won't know if everything actually integrates until that time. That is way to intermittent and is similar to old school waterfall "integrate and test at the end", although at least it's a more frequent than once per year. If everyone merges their code into main several times per day - fine - but what do you need FB/PR for in the first place if it only lasts a couple of hours anyway? Seems like a lot of ceremony. I have actually been there, twice, kind of - in a highly compliant industry. We had armies of testers, reviewers, configuration management people, merge bosses, process and branches, and yet we had very expensive production issues all the time. Then I took over as tech lead for the most certification-critical components. The only changes we made was that we skipped all the ceremony/merges/handoffs and started doing proper XP/CI/TBD and our response time became 10x better and our production issues went down by 2 orders of magnitude. That alone saved the company $2M per year. A few years later a bunch of managers decided that "everyone must do FB/PR because we have to be compliant (BS, yadda, blah) and we read on the internet that that is everyone else is doing so we should too" and it became dogma and enforced by people not doing the actual work. After that we had slowed down and were right back in the tank and half of us had left within a year. *We didn't need FB/PR - we were doing better without them already!* Because so many are used to treat version control as a kind of personal junk-drawer where we throw things into a branch, fiddling around for a while, have it being broken for hours/days, flaky and unstable and then pick up the pieces into a whole at the end, then squash merge and PR; they get stuck in that cycle. 1. This is often a sign of bad design or issues with the culture. 2. There is a world of difference between "half baked", "incomplete" and "messy crap" - in XP/CI the software should still always work properly. 3. Code reviews are primarily there for learning and feedback. Async blocking reviews actually slows the organization down and have questionable effect on the quality. And even so not all changes requires review and not all reviews have to be blocking - see Martin Fowlers 3 types of reviews "ship-show-ask". FB/PR proponents are stuck 100% on "ask". You can always refactor and improve things after the fact, after it's on main, and even after it's gone live. Something people seem terrified of.
1
First: Talk to each other, spike and pair/group with other people than just programmers. There is more to development than writing code. Second: Remote async work always has a cost, a cost we have to pay many times over in terms of communication, mistakes, rework, process (PR or whatever), etc... Yes, context matters, but we shouldn't chose "strategy" without understanding (and accepting) the implicit cost. Not that the IT industry has ever done that properly - like government IT projects... Third: No one is spitting out features every 10-15 minutes. Committing code every 10-15 minutes on the other hand works just fine. You can commit unfinished code/features/changes as long as it doesn't break anything... which is kind of at the heart of CI (and the other CI). Geepaw Hill has a couple of articles and presentations I like - "Many Much More Smaller Steps".
1
@chaos_monster I think we are talking past each other. First: I have no response to that. Second: Which was kind of my point... Third: Nowhere did I say to deploy every 10-15 minutes. Can we agree on that at least? Not all changes requires a feature flag. Only changes where we change the behavior of the system or add/replace/remove a part of it. And this is like everything else - keep things simple and clean up as we go.
1
💯
1
"oooor you know, you have continuous integration for the feature branches" - nope, you can't, because that is not CI.
1
And if it's rejected you have to switch back, remember what you did maybe 3 days ago. Fun. People are obsessed with busyness and chalking off tasks from a todo-list. The problem is that we are really *not done* unless it's running in production (or at-least staging). But people love to "implement tasks", then pass it to PR/test and pretend they are done and move on to the next task, when in reality nothing is done. You should really read about one-piece flow and theory of constraints and how inefficient async blocking workflows actually are.
1
"There's absolutely no reason why you can't CI every single commit no matter what branch it's on." So what is CI then? Define it please.
1
How the h*ll do you lose code in git? It's impossible, unless you allow "force push/rewrite history". But in that case you just screwed yourself. Every SCM tool I've used has mechanisms to block force push + branch protection rules to block rewriting of history.
1
@Ryosuke19 That is one kind of pair programming called "ping-pong programming". It's a fun little game to get going when working on something boring or "where do we even start" kind of task. Love it.
1
@babgab Pair programming is not - two - people - programming. Pair programming is "two people programming". It's collaborative, not cooperative. It's the difference between having fun with your friends and having fun with your spouse. I don't really care for optimizing individual developers time. What I do care about is to optimize throughput and work not done - ie. if you're working with FB/PR and only having someone review it at the end, and it turns out it's the wrong thing, the wrong way, a misunderstanding, etc. at what point is it "rejected"? The rubber duck came in after all that time and effort had already been applied. With pair programming you'll get feedback much sooner. The solution is of course to make sure that the work done in the PR is very small, less than an hour... but then the question is why even bother with an FB and not just do proper CI and have someone come over to your computer/hangout/screenshare and review it before you push to main (or after push if possible)? Or do proper pair programming to begin with. :)
1
Umm, refactoring?
1
"it's difficult for management to accept it", yeah about that... In the end they hired *you, the engineers* that *knows* how to make software, management don't. You should be able to tell them "You don't pay us to type, you pay us to make software and this is how we make software, we pair and collaborate." - Ask them if they would hire a doctor and then tell the doctor how to perform the surgery. - Ask them if they would hire a finance auditor and then tell them how to do their job (that's how the CEO and CFO ends up in prison). - Then ask them why they would hire smart people and engineers and tell them how to do their jobs and still blame the engineers when sh*t hits the fan. But I get it.. politics... you can't just ask serious questions... I'm just an angry "naive unprofessional ideologist" so what do I know... PS: Never heard about PSP. :)
1
Ok, explain to us what you think CI is then.
1
It scales very well (given good tooling) Google is doing this - 20,000+ developers, billions of lines of code in a single repo, on a single branch. They do have review-gates, but there are no branches or pull requests involved as such. And the majority of checks are automated... That the commit-build takes an hour has nothing to do with TBD or PR. That is always bad tooling, bad design and bad tests. CI means the original as written, not whatever people redefines it as so they can put CI on their resumé. See wikipedia for example. Read Extreme Programming Explained. Lot's of WIP and "not-done" changes waiting for review, checks, etc. is "not a good thing (tm)". I suggest reading The Goal by Goldratt and The Phoenix Project by Gene Kim, as well as other books in that space. Management: "All hands on deck", "what do you mean, having two people at the same keyboard?", "Why aren't everybody busy, typing code? Do we need to fire people and trim the fat?", etc. Sigh. Yeah. I hear you. Get a new job or something.
1
@AlanW I don't work at "the company". This is very well documented in articles as well as on youtube by employees. PS: My original comment was instantly deleted by "the company's comment bot" due to being negative about "the company". LOL!
1
You don't seem to really understand the economics of software engineering. Pair programming does not costs twice as much. You have to look at it from a holistic perspective over time - the amount of bugs, the knowledge sharing, the amount of rework, the quality of solution, the clarity of code, the amount of unnecessary work not done, etc... Having another person, not doing the actual job and only there to review is the same old trap we fell in when we decided to separate architects from developers from testers from UX from the business and maintainers from programmers and... It's all just reductionism and excuses... Focusing on efficiency is a bad strategy at best and damaging at worst. What matters is throughput, sustainability over time and the ability to produce the expected result within reasonable time and cost - i.e. effectiveness. There is an old adage in the software industry - "if you want to go fast, you need to go slow".
1
@KyleGobel Yes, I know I may come off as "abrasive" and counterproductive. It's not personal, I'm sorry. I'm just tired of everything in IT right now... It's more complicated than that... having another person there is best done as the job is being done, not after it is done. What I mean is that all those things I listed comes from the practice itself. The effect is emergent, not strategic. See it like this: On paper it is cheaper to have a single surgeon doing the surgery. Having to pay extra for nurses and anesthesiologists seems inefficient. Right? But if we look at it from a holistic perspective and look at the amount of mistakes that requires more corrective surgeries, the pain, medication and recovery time, the loss of quality of life and at worst the loss of life. Then the premise of having multiple people collaborating, helping and checking the work *as it's being done* suddenly seems like a good idea. - Efficiency / cost accounting - make "healthcare" as cheap as possible. - Effectiveness / throughput accounting - keeping and making people healthy and return to life - result.
1
CI is more than a build server that runs checks against your code. And if it's ran against feature branches then CI is not even in the scope anymore. Yes, I know tool vendors would like you to think that CI is "jenkins, circleCI, whatever"...
1
@adamhenriksson6007 Yes, but when you said "CI is run on submit" I assumed you meant "running automated verification on feature branches" - which is, by definition, not CI. I'm adamant about this because we have gotten into this bad habit of redefining things to mean "whatever we are doing right now". I know what you meant and I'm just trying to break people out of the illusion that they think they know what CI is and that they are doing CI when they aren't. It's a little like when teams spend a week writing all the tests, and then coding for another week and then calling that TDD. Just tired of everything right now...
1
This is a false dichotomy. If programming was just typing it would be correct. But programming is thinking about the problem, figuring out solutions, troubleshooting existing code and talking with other people to make better informed decisions. And yes, there already is. It's called "mob programming" or "ensemble programming". You should watch his other video named "You Must Be CRAZY To Do Pair Programming".
1
This is really hard. Databases are amazing and terrible at the same time. I hate them, kind off... Anyway, in my Java projects we made sure that our "monolithic" application was properly modularized and that each module was responsible for it's own database-schema. Modules communicated with each other over normal Java APIs instead of "through complex SQL-queries with tons of foreign keys, joins", etc. In some places we used Flyway with versioned DDLs, etc. In some other places it was home-built python-scripts that executed on-demand before the application started. This made it much easier to manage the database as well as extract "services" from the monolith. Was it perfect? Hell no. So we used blue-green "staging" to save our bacon and not destroy the production DBs. Can we stop using databases? :)
1
@pablog5738 For modules that changed a lot it was worth it (always deployable). For things that changed much slower we could probably have achieved the same with good process and change management. This was at my previous job with 1000 devs and 1000s of servers. My current job is a startup with 50 devs and 20 servers which has many other problems than schema versions. It will matter in the future, but for now we just have a single database guy that handles all the DLCM.
1
@pablog5738 It was 7-8 years ago. I don't remember and I was the guy that avoided databases until I really needed one just because they hurt and they drag you down with them. For applications that gets deployed a lot, many small changes to the DB-schemas is fine. It's like refactoring normal code - it's never done - many small changes, always deployable. Sometimes we had to "branch by abstraction" the database and just support old and new schema at the same time and other times it was a backup followed by a straight data-migration. For those with applications that has a much slower rate of deployment (weekly or whatever) you can still do many small changes of the schema v1.2.1, v1.2.2, v1.2.3, etc. during the sprint, and then at the end merge all those intermediate schema versions into a v1.3.0 (and delete all the v.1.2.x). That works fine when having a more static release schedule. Not really CI but YMMV...
1
What are you trying to say? It's not like Dave doesn't know this and have been promoting pair programming for many years. Please explain your comment.
1