Each one of your videos has a few bits of subtle humor that is definitely noticed and appreciated - kind of a scavenger hunt to find the jokes buried within.
How do you avoid continuously working on surface features if each task or cycle done should be able to be used by customer/stakeholder? For example how would you plan the team's work if something needs a larger restructure? Or if end goal function requires a large database? Thank you!
Have you tried turning the tree sideways? Feel like all you'd need to do is uproot it with say a backhoe or till or dodge neon, then if you hire a team of hvac specialists to build a small air delivery system from the adjacent building to carefully blow the dirt away from the root structure (you could skip this but risk bonding integredy and other surface contamination issues that may present later). After that its a simple job of fireing the hvac crew, then hireing a subset of skilled powerlifters and a cable making facility, have them calculate the weight of the tree ect... then construct a cable that you can probably still source from oversees anyhow if you hit a good window after new years ect... just make sure you have targets samples of both from large orders and cancel the contract right after*. After that have the power lifters go to the home depot and purchase a wench system with at least a reasonable assembly guide, (see discription for any other tasks at HD for efficency, though couldnt see why you couldent just make each trip individually cause then you can expense out lunch after). After that, just have the power lifters construct the wench and use the dodge neon and any spare vehicles nearby as a counterwieght as you raise the tree up the building side and thus... sideways! Your Halfway there! Lol gonna stop now... not kidding though seems like this happens all too often and usually for several reasons all mixed together in a basic principle that eventually systems are so disconnected that at some point in the chain, you just don't give a shit... (oversimplified true, but I am trying to stick under 3 pages these days per post)... The inverse though is micromanagment and we all know that engineers never have had issues usuall... oh... nvm.
@@ContinuousDelivery I will one day, the ghost spirit of rube goldberg is guiding me in a method and craft to do just this... but I'm still waiting on the 20 goldfish and solinoid switches from china... any day now, and i can get started on getting started.
Great video (as usual). Dave, may I suggest that you improve the sound quality and remove some reverberation in the room? Are you far from the mic? In case, you should wear a lavalier mic.
Thanks. Yes I am still struggling with the sound a bit. I have tried a variety of mics, but I am no sound engineer. I tried a cheap Lavelier Mic early on, but it was worse, so I probably need to buy a more expensive one.
@@ContinuousDelivery hey Dave. When you wrote this comment 1 months ago, did you expect to have a video accumulate over 127 thousand views? Cause you did. Congrats friend, you must be thrilled.
Conceptually I like the CD/CI method but the environment where I work doesn't have any automated testing capabilities. There are no test suites run on any code, it is all tested by the developers initially in the development environment, then moved to a TEST environment and then after more manual testing it is finally moved to production and more deployment day tests are manually run. They tried to get into Visual Studio and DevOps as the source code repository but the developers fought back on that and are back to editing code in the development environment (Linux) using text line editors. (UGHH!!) When they are finished with their change they create a "delivery" that then bundles up the changes and delivers it to the DevOps as a branch. It is all so messy. Prior to that the only difference was that they used a different tool to manage access to the code where developers "checked out" the code and nobody else could modify that file until they were done. This could take multiple days at a minimum.
In Continuous Delivery we try to work so the software is ALWAYS RELEASABLE and when we make a mistake and so it is not, we work to get it bak to releasability as quickly as we can. The win here, is that if we aim for releasability all the time we are forced to change how we approach our work, that, in turn, has a valuable knock-on effect on the quality of our work. That is why I call this an engineering discipline, in the sense that specific working practices (working so our software is releasable) promotes higher-quality outcomes. If something takes a long time we break it up into smaller steps. I have a video on this aspect coming up in the next few weeks.
Not really “continuous delivery” as I would mean it then. The name is based on the agile manifesto, “the continuous delivery of valuable software”. Your software wont be very “valuable” if genuinely “untested” and it won’t be very “continuous” if what you really mean is “manually tested”
Let's say we are working on a very nontrivial piece of software that requires months if not years worth of time to get to the first releasable candidate. Do we just consider it's constituents as separate development processes we can continuously iterate on and 'release' them internally?
The point is that every small change, is done in a way that it is finished to production quality. We divide the work up so that we can make progress this way, that means that when we have enough of the system to be useful, we are ready to release it. This is a significant change in how we organise our work, but it works and is extremely scalable as an approach. Working like this is measurably the best way that anyone knows how to create high quality software, this is the fundamental of Continuous Delivery. Frequent releases is enabled by CD, but you don’t have to release frequently to benefit from it. I describe this in a bit more detail here: th-cam.com/video/mBzDPRgue6s/w-d-xo.html
Not really. 'Milestones' are really check-points in a plan at which people intended to check progress. Continuous Delivery is speeding those check-points up so that you get that feedback multiple times per-day. If we work so that our software is ALWAYS IN A RELEASABLE STATE we get good feedback on where we stand in terms of progress. There is an old joke in programming, "When I, as a programmer, think I am 90% done, there is 90% of the work left to do". In Software it is often hard to measure progress. If I make progress in smaller, simpler steps, but to full production quality, it is easier to see my real progress.
Great video. I'm only 3/4ths of the way through it, but there is one aspect of human psychology that has manifested into the Continuous Delivery methodology, and that is since it is so easy to push out new versions and fix problems, short-cuts are taken, and bad code is sent out when it shouldn't be, more often that it should. When CEO's, or business pressures push too hard for product delivery, teams feel that pressure, and probably move too fast. On another subject, could you do (or have you done) a video on companies that make changes to software that aren't really needed, just because they feel they have to put their own mark on the product? Like Musk says, "The best part is no part" so "the best change is often no change." If it ain't broke, don't fix it.
He looks like a prophetic dream, peaceful vision, guardian angel.
Each one of your videos has a few bits of subtle humor that is definitely noticed and appreciated - kind of a scavenger hunt to find the jokes buried within.
Thanks, glad you noticed, and enjoy them.
How do you avoid continuously working on surface features if each task or cycle done should be able to be used by customer/stakeholder? For example how would you plan the team's work if something needs a larger restructure? Or if end goal function requires a large database? Thank you!
Have you tried turning the tree sideways?
Feel like all you'd need to do is uproot it with say a backhoe or till or dodge neon, then if you hire a team of hvac specialists to build a small air delivery system from the adjacent building to carefully blow the dirt away from the root structure (you could skip this but risk bonding integredy and other surface contamination issues that may present later).
After that its a simple job of fireing the hvac crew, then hireing a subset of skilled powerlifters and a cable making facility, have them calculate the weight of the tree ect... then construct a cable that you can probably still source from oversees anyhow if you hit a good window after new years ect... just make sure you have targets samples of both from large orders and cancel the contract right after*. After that have the power lifters go to the home depot and purchase a wench system with at least a reasonable assembly guide, (see discription for any other tasks at HD for efficency, though couldnt see why you couldent just make each trip individually cause then you can expense out lunch after).
After that, just have the power lifters construct the wench and use the dodge neon and any spare vehicles nearby as a counterwieght as you raise the tree up the building side and thus... sideways!
Your Halfway there!
Lol gonna stop now... not kidding though seems like this happens all too often and usually for several reasons all mixed together in a basic principle that eventually systems are so disconnected that at some point in the chain, you just don't give a shit... (oversimplified true, but I am trying to stick under 3 pages these days per post)...
The inverse though is micromanagment and we all know that engineers never have had issues usuall... oh...
nvm.
Have you tried going for walks? 🤣
@@ContinuousDelivery I will one day, the ghost spirit of rube goldberg is guiding me in a method and craft to do just this... but I'm still waiting on the 20 goldfish and solinoid switches from china... any day now, and i can get started on getting started.
Great video (as usual). Dave, may I suggest that you improve the sound quality and remove some reverberation in the room? Are you far from the mic? In case, you should wear a lavalier mic.
Thanks. Yes I am still struggling with the sound a bit. I have tried a variety of mics, but I am no sound engineer. I tried a cheap Lavelier Mic early on, but it was worse, so I probably need to buy a more expensive one.
@@ContinuousDelivery hey Dave. When you wrote this comment 1 months ago, did you expect to have a video accumulate over 127 thousand views?
Cause you did. Congrats friend, you must be thrilled.
Conceptually I like the CD/CI method but the environment where I work doesn't have any automated testing capabilities. There are no test suites run on any code, it is all tested by the developers initially in the development environment, then moved to a TEST environment and then after more manual testing it is finally moved to production and more deployment day tests are manually run.
They tried to get into Visual Studio and DevOps as the source code repository but the developers fought back on that and are back to editing code in the development environment (Linux) using text line editors. (UGHH!!)
When they are finished with their change they create a "delivery" that then bundles up the changes and delivers it to the DevOps as a branch. It is all so messy.
Prior to that the only difference was that they used a different tool to manage access to the code where developers "checked out" the code and nobody else could modify that file until they were done. This could take multiple days at a minimum.
My pregnant wife was horrified when I mentioned “Continuous Delivery” in a conversation about my job.
🤣 context is everything. Good luck to you and your wife.
Not at all is bad, guess the tasks before delivery she feels more comfortable 😂
Are there exceptions to "always in a releasable state"? What if something takes longer? Like rewriting portions for optimization?
In Continuous Delivery we try to work so the software is ALWAYS RELEASABLE and when we make a mistake and so it is not, we work to get it bak to releasability as quickly as we can.
The win here, is that if we aim for releasability all the time we are forced to change how we approach our work, that, in turn, has a valuable knock-on effect on the quality of our work. That is why I call this an engineering discipline, in the sense that specific working practices (working so our software is releasable) promotes higher-quality outcomes.
If something takes a long time we break it up into smaller steps. I have a video on this aspect coming up in the next few weeks.
@@ContinuousDelivery awesome, that makes sense. Thanks and good luck with the channel!
I do continuous delivery very well, continuous delivery of untested code that is.
Not really “continuous delivery” as I would mean it then. The name is based on the agile manifesto, “the continuous delivery of valuable software”. Your software wont be very “valuable” if genuinely “untested” and it won’t be very “continuous” if what you really mean is “manually tested”
11:53 What about formal methods?
Let's say we are working on a very nontrivial piece of software that requires months if not years worth of time to get to the first releasable candidate. Do we just consider it's constituents as separate development processes we can continuously iterate on and 'release' them internally?
The point is that every small change, is done in a way that it is finished to production quality. We divide the work up so that we can make progress this way, that means that when we have enough of the system to be useful, we are ready to release it.
This is a significant change in how we organise our work, but it works and is extremely scalable as an approach.
Working like this is measurably the best way that anyone knows how to create high quality software, this is the fundamental of Continuous Delivery. Frequent releases is enabled by CD, but you don’t have to release frequently to benefit from it.
I describe this in a bit more detail here: th-cam.com/video/mBzDPRgue6s/w-d-xo.html
13:44
In the video game industry, would this be synonymous to "milestones"?
Not really. 'Milestones' are really check-points in a plan at which people intended to check progress. Continuous Delivery is speeding those check-points up so that you get that feedback multiple times per-day. If we work so that our software is ALWAYS IN A RELEASABLE STATE we get good feedback on where we stand in terms of progress.
There is an old joke in programming, "When I, as a programmer, think I am 90% done, there is 90% of the work left to do". In Software it is often hard to measure progress. If I make progress in smaller, simpler steps, but to full production quality, it is easier to see my real progress.
@@ContinuousDelivery Thanks for the response.
Great video. I'm only 3/4ths of the way through it, but there is one aspect of human psychology that has manifested into the Continuous Delivery methodology, and that is since it is so easy to push out new versions and fix problems, short-cuts are taken, and bad code is sent out when it shouldn't be, more often that it should. When CEO's, or business pressures push too hard for product delivery, teams feel that pressure, and probably move too fast.
On another subject, could you do (or have you done) a video on companies that make changes to software that aren't really needed, just because they feel they have to put their own mark on the product? Like Musk says, "The best part is no part" so "the best change is often no change." If it ain't broke, don't fix it.
awesome videos, lot of ideas.
Thanks 🙂
Test all the f. time
If it is simply explained, why does it still take 17 minutes to explain it?