PAINFUL Software Release Cycles Are NO JOKE
ฝัง
- เผยแพร่เมื่อ 25 ก.ค. 2023
- What’s your software release cycle? How long does it take you to prepare for a release? If it’s more than a day you aren’t practising Continuous Delivery yet. Still, there are all sorts of barriers to optimising the release process that get in the way of effective, efficient software release management and the adoption of Continuous Delivery. CD fixes release cycle problems by optimising for fast, efficient, cycle times and high-quality outputs, but how do you get to there from where you are now?
In this episode CD expert Dave Farley describes the Software Release Death Spiral, how decisions reinforce bad outcomes, and amplify our need to do more things that only make releases more difficult and more risky. He describes a real-world example of a large company, with complex software, breaking out of this death spiral and how they went from being unable to release software at all, to releasing software all the time.
-
🎓 Continuous Delivery: Better Software Faster Course
🚨 £100 OFF FOR A LIMITED TIME 🚨
No more stressful releases or expensive delays between features. In this course, Dave Farley guides you through the fourteen essential techniques that you can apply to get the benefits of Continuous Delivery for your software, your team and your business. FIND OUT MORE HERE ➡️ courses.cd.training/pages/cd-...
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE and start your free trial to see if you like it! There are then options from just £2 a month ➡️ bit.ly/ContinuousDeliveryPatreon
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
🔗 LINKS:
The Continuous Delivery Mailing List ➡️ www.subscribepage.com/cd-mail...
-
BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 "Growing Object Oriented Software Guided by Tests", By Nat Price & Steve Freeman ➡️ amzn.to/2Lt3jho
📖 "Test Driven Development: By Example", Kent Beck ➡️ amzn.to/2NcqgGh
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
IcePanel is a collaborative diagramming tool to align software engineering and product teams on technical decisions across the business. Create an interactive map of your software systems and give your teams full context about how things work now and in the future. ➡️ u.icepanel.io/1f7b2db3
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
#software #softwareengineer #developer - วิทยาศาสตร์และเทคโนโลยี
🎓 Continuous Delivery: Better Software Faster Course 🚨 £100 OFF FOR A LIMITED TIME 🚨
No more stressful releases or expensive delays between features. In this course, Dave Farley guides you through the fourteen essential techniques that you can apply to get the benefits of Continuous Delivery for your software, your team and your business. FIND OUT MORE HERE ➡ courses.cd.training/pages/cd-better-sw-faster
Someone got really excited with the dragon animations...
+1. I’m guessing Dave is playing with AI and I’m curious what that is😅
Behavior-Driven Dragons.
Whew, I thought I was the only one seeing them.
I got a feeling that they're dinosaurs or "Dinobabies" if you're a manager at IBM
This channel is legit gold
lol
12 minutes in and this man is describing the exact problem with my job in ever more painful detail. I work in a large cybersecurity company that sells my hours to a government agency through contracts (yes the same government agency through sometimes five different contracts at a time) that specify projects. The relationship with the customer is cold, on some projects hostile. The product suffers too, of course. If we find a bug we first ask who has to pay for it, us or the customer, then distantly second whether it matters or would be easy to fix. Releases are three a year at most. But we are certainly agile, my boss says, because we have scrum and sprints and a scrum master who spends most his time working on charts and estimates.
It's not all bad. At least we have decent testing (though mostly manual) and support for me learning the skills to get a better job later on.
I'm betting what they mean by "Scrum" is what some certification mill taught them, not the framework PDF. Either way, Scrum is agile nor does it work. It is a pretend exercise to create shiny reports to show upper management.
Working on bad projects is quite a good way to gain experience of what not to do in future 😉
Good luck!
My job wasn't in a gov't setting like this, but it was very similar. Same kind of relationship w/ the customers, a toxic relationship between support & developer teams, and many outages. The dev teams had some sort of scrum team structure. Managers focused a lot on tons of metrics & estimations, yet we never delivered on time and with many bugs and the metrics were most likely skewed. The business was sold to another company and is apparently the product I was working on is now in the process of being shut down now by the new company.
The development effort was soo slow and poorly done that I had to resort to running manual MySQL commands in production and shell commands to modify database rows for a customer. Scared the HELL out of me. Sooo much stress, I QUIT!
Gave me a lot of experience on exactly which type of company to look out for when it comes to finding agile farces.
This is exactly my world, except not cyber. But tangentially related at the moment.
The man who taught the Japanese auto makers the management methods that enabled them to eat the Big Three's lunch had this to say: "Eight-five percent of all problems are caused by management." Traditional management are stuck in paradigms that don't work but are never questioned.
That man was Deming - en.wikipedia.org/wiki/W._Edwards_Deming
Great description of a rare event. This is that eventuality where a team of devs plus manager cannot be corrected but are replaced by devs and manager who can. How do the new team members undo the evils of their predecessors. The more normal eventuality is that the devs and manager immune to being corrected (such people do exist) are unable to get new jobs easily and stay put forever, perpetuating their outcomes.
I have worked in the wind and generator indrustri and those are heavily hampered by certifications and thats why they can't just press out releases from day to day.
Been there.
It's a paradoxical situation on many levels. Part of the processes are cemented in contracts. Contractors would deliver the code but no unit tests (no contractual obligation). Bureaucracy is superfluous if you version your documents, code, etc. anyways. The bureaucracy could still not make sure that changes to the software or infrastructure were documented in a transparent and easily understandable way. Still important details are not always documented. The various teams are opaque regarding their responsibilities and if they are not then people in other departments don't care about the big picture. Division of responsibilities is on a very small scale thus introducing continual delivery would involve several departments and teams. But still quite a few essential requirements are missing (i.e. unit tests and automated tests). Tests are semi automated although it would be possible to "go that extra mile". The organisation spends a lot of money on professional "toys" with excellent automation capabilities (e.g. weblogic and jython scripting tool) and a lot is still done manually. Deployments are done partly manually and almost every time something goes wrong.
It's complicated on many levels.
I used to believe it was possible to change an organization, but no longer do. There are too many people whose jobs demand the slowness and they will all fight you.
There are some orgs that won't change. This is certainly true, and it's also true that when you start trying to change orgs like this you can activate the "cultural anti-bodies" who will aim to retain the, non-functioning, status-quo.
But it's also true that if you never try change will never happen, and many people, even in dysfunctional orgs want to change. There's a joke that I have heard Martin Fowler tell a few times, "You either change the org where you work, or you change the org where you work". For me giving up and not trying to change things for the better isn't an option, but sometimes the scale of the change that you can make may be small.
@@ContinuousDeliverywell said! I like the term "cultural antibodies" 😂
I totally agree. I won't ever try to change an organization on a fundamental level like that again. I'll always discuss w/ direct co-workers, but it's not my job to convince the entire org. Don't "fix" or save them. What changes is how much money they get. Just let them go broke and stop earning them money.
I thought I could change an organization once. After 8 months of banging my head against the wall I left the company.
Hi Dave, great stuff as always. Where does requirements, design (ui, ux) and architecture fit into this? Are they part of the cycle or outside ?
I think that they work best as part of the cycle, I have a couple of videos that outline some of my thoughts, one talks about BDD, but that is A LOT about the requirements process in my view...
"The Ultimate Guide to BDD" th-cam.com/video/gXh0iUt4TXA/w-d-xo.html
"What SW Architecture Should Look Like" th-cam.com/video/ElMnHDSFaCw/w-d-xo.html
low trust = low productivity
Is there a link to the Continuous Delivery newsletter, please? Couldn’t find it in the description.
Hi Felipe - here's the link. Thanks for bringing it to my attention, I'll add it to the description: www.subscribepage.com/cd-mail-list
Thank you!
It took me a day to finish some code but it's tested and cleaned up and all that. Unfortunately it took more than 10m because it's just the beginning of the project and there was a lot of bugs that failed my tests and refactoring after the tests were passing.
Try working in smaller steps, writing the test first to verify each, small, step and committing after each each small, simple, test passes.
@ContinuousDelivery - Do you think that company would have been as accommodating to your ideas if you had been an employee, say someone who read Continuous Deliver, watches these videos and/or took your course, rather than an external consultant?
I've found it very difficult to make changes from within. The ideas from external consultants seem to carry more weight. The more expensive the consultant the better. And if they have to fly, well then gosh darn it, we're going to jump on this immediately.
"And he (Jesus) said, 'Truly, I say to you, no prophet is acceptable in his hometown.'" - Luke 4:24.
It is certainly more difficult to make changes like this as an employee, that isn't right, it isn't sane, but it does seem to be a real thing. I confess that as I have become more experienced as a consultant, and higher-priced, it does make a difference to how people listen to me, and who listens to me. The higher the price, the more senior the audience.
None of this is good, but the cognitive bias of "decision from authority" is a real effect.
I recommend to my clients that they use me for that 😉
A couple of notes from my personal experience:
1. If your estimate is 10 and you declare 40, the team will take the 40 number as an anchor and will fill it with what they consider necessary activities. Then you will likely spend 160.
2. With more or less awareness, both implementers and users recognize the problem of the long delivery cycle and create alternative delivery conduits. Frequently, they use the term "configuration" to create code delivery shortcuts. In reality they build a way to late bind code, escaping the tedious gates of the longer process. This approach creates a full domain of new problems.
1 is called "Parkinson's law"
the image you put up with "No plan survives first contact with the enemy" is wrong. Your image shows Helmut von Moltke the Younger. It was said by Helmuth von Moltke the Elder. Thats german nobility right there...
Thanks for the correction 😉
Does anyone have experience working with bureaucratic organizations (e.g., in our host's case, the Civil Service) that feel that compliance to an external funder, policy arm, etc. prevents some of the ideas the host presents and advocates for?
Yes, quite a lot, and it is almost never true, the barrier is nearly always the company's interpretation of regulation rather than the regulation itself.
Yes, that's where I am now. Change isn't glacial, it's impossible.
@@ContinuousDeliveryThat's a particularly common and thorny issue. If I'm a software engineer tasked with X, should I dive into the research to counteract my managers interpretation of the compliance regulation? Managers love being told they're wrong..
@@PavelHenkin only bad managers dislike being told they are wrong 😉
It isn't the managers job to tell everyone what to do, though many try and arrange things to work like that. Good managers are more like sports coaches, they set out the strategy for the game and help the "players" to maximise their skills and to understand the strategy well enough that they can exercise freedom to improvise as the game progresses.
As an engineer, your job is to produce good SW that solves a problem for someone as efficiently as you can. Some, quite a lot, of that, only you can do. So properly understanding the constraints in which you operate (regulation for example) allows you to better optimise to minimise the impact pf the regulation. Leaving that as a problem to non-technical people means that you will get non-technical (read 'bureaucratic') solutions to these problems which are actually VERY amenable to automation. You have to engage with this part of the problem, with the help of non-technical people, but not at their command.
I describe some aspects of this in this blog post: www.davefarley.net/?p=285
@@BryonLape Try and find a way to break the vicious circle and in particular focus on making change in VERY small steps. Fix one thing now that gets in your way, start moving the curve from constantly trending down "slower and more complex" to starting to trend up ""faster (small steps) and less complex".
SMOP - small matter of programming
"Plans are useless, but planning is essential."
it's truly poetic that you made this video when you did... because we just had a bad release... thanks to me lmao.... but on the real, I found a neat new nuance with aws AMI's and time zone persistence when an EC2 is spun up... no big deal, only caused a few 1000 medical records to be written in UTC time instead of central. lol.
Given, I'm not ignorant lol, I did test changes made, no one thought to actually look at the ec2 though, since the image pipeline appeared successful based on the logs.
It was embarrassing causing several people to context shift in the middle of a sprint, but tbh its this weird nuance experience that I love lol
Did you pay for the dragons animations, or did the dragons animations pay you?
The dragons are there looking for weakness, before they pounce 🤣🤣
i'm too noob a coder to comment on the video content, but i want that jinx tshirt
Feel free to comment, noob or not, we have a deal with the place where I buy most of my T-shirts so that you can get a discount there's a link in the description too this video, but also here:
🔗 Check out their collection HERE: ➡ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
"Everyone has a plan until they get punched in the mouth."
-Mike Tyson
1:08 I don't consider releasing once per week to be Continuous Delivery.
Is it cheating if I comment before watching 😅
Yes, if its OK for me to reply without reading the comment 😅
Yes, but only if you have a refactor button.