When I worked at Pixar I saw this process unfold in real time. Every day the changes made to an individual asset get pushed to the live version of the film / project and rendered each night. Then the next day everyone reviews the sequences of frames to determine if the small changes worked, and if so what needs to be done next. Every individual code / asset update gets incorporated as soon as it can so it can be tested along with everything else in the rendering. Then small changes can be made today and the tests run overnight to repeat the process again tomorrow.
Dave, I want to stop for a sec and say thank you. You've bring so much important topics to my professional path; in every one of your videos I find wisdom, expertise and caring. Thank you!
One critical point missing from the "Process of translation" part is that there is huge pressure on estimating how long work will take once "Story" is defined. This then forces lots of the follow-up design that needs to be integrated into the story before "real work" begins. I feel you should stress that to make this process work, business management must abandon need to estimate the work, as there is not enough information at the start. And only actually doing the work gives us enough information, and that is often by the end of the full work itself. Actually heard one of our org leaders say that he was able to achieve "good story work estimation" on one of his previous teams. And that was because lots of the design and implementation was front-loaded during "planning". I interpreted it as lots of the uncertain work being done outside of estimated work time and work itself being straightforward once the critical details were worked out.
Do you really think management should "abandon" asking for estimates, or merely defer asking for them until later in the process? Imagine you are the manager, and as such, you are essentially the buyer of the labor to achieve your goal. Not getting an answer about how long something will take is a lot like walking into a car dealership, asking how much a particular car costs, and being told "we have no idea, but we'll let you know after you agree to buy it." Don't misunderstand; I am a developer myself, not a manager, and I know it's impossible to guess at the beginning of a project how long it will take. Yet managers have every reason to care deeply. They really do need an answer at some point.
it's not as black and white. As a dev and dev manager in the last 15 years - it's so easy for devs to build their sand castles without proper preparation for work or even understanding the domain of problems. Estimating keeps that process in check, obviously in the most inefficient and immature way - but a way it is and it's easy and relatively repeatable. In the end at work you need to bring results out the door and not the "good ideas". If you add to that picture a sad statistic that rarely your team will have many devs with more than 5 years of experience - we get ourselves a pretty nasty situation we need to cope with.
@@CosineKitty Yes. There is often no good reason to estimate when the work will be done. Your analogy with car does not fit in here. If something is important enough, it is unecessary to know how much it will cost, you will still build it, even if it is expensive. Because you expect that payoff will be at least order of magnitute over expected costs.
@@RFalhar this approach doesn't work in less mature teams. In mature ones estimates are not needed, we agree on that. I also agree that the best measure of progress is code on production but again.. it's not black and white
The approach I describe in this video is available for you to learn on-line in my Continuous Delivery course "Better Software Faster". TAKE A LOOK ➡ courses.cd.training/courses/cd-better-sw-faster and watch a free preview.
The irony of this approach being so well suited for regulated companies, yet it's regulated companies who are most likely to push back on this approach because: "we're regulated".
Beyond Coding Podcast would be a great place for Dave for feature. Patrick asks great questions and Dave is a store of information. I'd love to make the introduction if you're not closed to it
How I describe SWE in conversation: "Software engineering is a process of translating the inner thoughts of humans into a set of computational functions through a series of iterative learnings."
I'd love to see more videos on requirements. Just because I'm a developer doesn't make me able to write specs. All too often I've seen projects where the business owners go straight to a developer, and the developer just starts writing code.
Here you have everything you need to know about requirements. The best way to develop is to start writing code despite a requirement is not perfectly defined. You implement it step by step and after each step owner should check it and give you feedback so you can continue with the next step.
Dave, thank you for the work you are doing for the CI/CD community. There is still one topic I am struggling to understand, however. How do we deal with CD for projects supporting multiple release lines? Where one story/commit needs to be integrated into several release versions? It is something I am unable to find any goo resources on. Do you have any though/words of advice on this?
I just think the companies has evolved faster in the Downstream than in the Upstream. I mean, once de specifications are Ready the team can deliver fast with CI/CD Pipelines, but looks like people in the Upstream don't know how to work like that yet. In other words, the Cycle time is fast but the total Lead Time is long.
ปีที่แล้ว
About login pages. I've heard from others that it is wrong to have a User Story even mentioning the login. If I were working on a project you are managing and I'm coding components of the Login page: What are some examples of paths that I could encounter if I do a backtracking of the "process of translations" from where I'm hypothetically located (Design & Implementation) all the way to the "Vage wish"? Rephrasing: If you are in the "Design & Implementation" phase and coding Specifically the "Login page" of a System, backtracking the breadcrumbs in the process: What are examples of actual "Executable specification", "Examples", "Stories", "Vage whish"? But if only one example I'm interested in the "Stories".
Agreed. Regulated SW systems design will greatly benefit implementing similar automated requirement process you described here (with some abstraction).
Growing the code base incrementally is ideally the best one, but in actuality, when starting a project, everyone is concern to ship the whole thing at once asap because the company is running out of budget.
Unfortunately, the software industry still relies on artifacts that are not code: docker images, jar, exe files, dependency registries, etc. This is necessary "glue" to execute actual code. But the simplest solution would be to have a runtime to execute code as soon as it was "pushed" to the code repo. Unison programming language is trying to just that. It is still in an early alpha state, but I hope such an approach becomes a norm in the future.
Very interesting! One thing I don't completely understand is how you can continuously check for releasability when the system has obviously not been built yet. My guess is that "releasability" is not a yes/no decision but say a percentage of how much of the system is releasable. Comments?
From 11:30 onwards its great example of failing at user story step. Mixing the needs with solution at early stage. Hard for most junior and mid level software developers to understand this problem.
Dave, I need to help organize a team of 20 people (architects, developers and tester) that today are doing a very poor job on the new MES system my company is developing. I am mechanical engineer, so coding is not really my cup of tea. But I am sure we can make a much better job if we put our resouces on the correct places. What you recomend me to read first, and trainings I could take second?
About thirty years ago I watched a video about paradigm thinking. Paradigm thinking is when a person's concept of something is artificially narrowed for no valid reason. For instance, the man who invented the quartz movement for watches was Swiss. The Swiss watch manufacturers, who dominated the market, were not interested in his discovery. In their thinking, it wasn't really a watch because it didn't run on springs and gears. He found a more receptive audience among the Japanese, to whom a watch was a wearable device that told you the time. It turned out that the watch-buying public had the same idea as the Japanese, and delivered the lion's share of the market to the Japanese. Software development managers can be guilty of the same thing. Management is done a certain way and no other, and any suggestion that we abandon the concept of deadlines is abandoning management entirely. We have to assign a point value to each project, and track how many of these points each developer accomplishes during the year, because we're not really managing if we do it some other way. We do performance review because that's how management is supposed to be done. And so on.
Thank you! I’ve seen all what you mentioned in all my passed work experience except performance testing. In a fast paced environment, I’ve never seen performance tests being run within a continuous integration environment. There are separate performance improvements projects though. While slow paced integration, 6 months and above releases, there were performance tests done before the release.
At LMAX where we built one of the world's highest performance financial exchanges, we did continuous performance testing at two levels. We did component level and whole system level perf tests. Both were implemented as "Pass/Fail" tests, based on thresholds of throughput and latency. It was all run in our deployment pipeline and our whole pipeline evaluated everything, including the perf tests in under 56 minutes.
@@ContinuousDelivery Thank you. I would love to work at companies that value high quality measures. However in my experience, most companies and specially at the startup phase, do not care about quality measures whatsoever and makes me a sad engineer.
I really enjoy your content, and I've read all of your books 🙂 - thank you for all you've done for the community. The approach you describe seems really good for "big service-like software development processes", and I've had my share of those for the last twenty years. But let's say you're coding something like a synthesiser or some other more creative tool where your task is to "Figure out what's possible". What are your thoughts on that kind of software projects? Something where you're building something that's really primarily research from the developers. Because we're trying to build "what can be done", but the initial wish isn't really definable. Another example could be a game, where it should be "fun", where it's hard to actually know whether or not what you're doing is "fun". So you need to have man multiple "ways you're going", paths of research or so. But those long paths may be discarded when they finally are abandoned... I'm rambling a bit here, but I get to work on these projects, and I can't apply your ideas readily.
If you are talking about music synthesizer, natural scope could be categorised for example through frequency, waveform, delta for the frequency and/or waveform and also esthetical aspects connected to different combinations in practice. Doing something human cannot hear or feel or distinguish any way probably is not useful to your project even when it is doable.
@@timop6340 Thank you. I'm absolutely hearing your suggestion, and it's good in many cases. My current task is to make "Something new and exciting", and maybe that's my problem, that it's actually research. Maybe I'm looking for a way for software research to combine with CI practices. Like a Continuous Research kind of framework.
"Something new and exciting" is fine as a starting point, but that is nowhere near something that you can build yet. You MUST have some idea to start cutting code. You are not randomly throwing characters into your compiler. So you have some sense of direction to explore. It may well be wrong, as you start exploring this direction, you may discover a new path that looks more interesting. All that is fine, and normal for any type of development. So at the point at which you think something like - "I think I can do something interesting with more compression & reverb on this part of the signal" (or whatever) then that is the point where you start to define a story, "as a musician, I want to apply compression & reverb only to a specific frequency range". When you find the new thing that is better than my (made-up) idea, then either park or dump the stuff you had. But when you keep things they are better defined, easier to return to, and you know that those that were finished still work, when you made changes. I don't think that there is any difference between this sort of software, and exploration, and any other. I would argue that SW dev is always a process of exploration.
Thank you! I'm aware it's not a request line. But if it was my birthday I would like to see a chapter in modern software engineering revision ten about strategies for keeping and removing unused code that may be used in the future. Everything I've read and watched has been with the underlying assumption that code goes in - code stays in. Not code gets used, then removed, then maybe not, then maybe again. I know the answer is "it depends", but I think there are also some pointers and ideas... Maybe just shared experiences that could shine some light into this.
I think stories are too small to capture the users' goals. You can use story mapping to shim this or larger interaction design focuses features (low precision) early then break them down into stories level work items to both understand the goal and develop toward it incrementally.
It took me just a brief while to get the point of dependency injection, but once I got it, I soon realized it was massively overused. People declare so many singleton instances for thread-safe classes, it is extraordinary to me how cluttered Spring can make a project become. Unless you really know what you're doing with Spring's autoconfigure algorithm, I would never suggest Spring Boot for a monolith.
I am finding that bringing up process bottlenecks in scrum ceremonies is helping my team be more conscious of dogmatic behavior. I will often get asked to provide a better perspective. This is where I try to influence the team(s) to adopt the practices you speak about. I have found that a lot of teams want to know the solution before making any estimates, which I think is silly. I am trying to give more direction for folks to focus on the outcome instead. I do have a question about project managers and story creation/management: I am often perplexed by project managers wanting to create an entirely new story when a requirement need changes. Why do you think they do that instead of revisiting the previous story and making the appropriate modifications to acceptance criteria?
They dont want to reopen a closed ticket and mess with leads times ? I suspect. A good idea to go your way and their way is to create an epic which contains the updated specification, containing the 2 stories which shows the history of the requirement.
Thank you for pointing out that this process is only needed for complicated projects. What do you think how many project types does this apply to? 0.0002% or less?
Also in bigger projects you will have single responsibility or not? Monolith or Chaos (like 150 different k8s - microservices with rabbitMQ and full unit and e2e tests on a 5 page wordpress website or an ERP or other trivial things)?
Trust me - starting a "simple" project with this same philosophy will pay dividends when the project inevitably grows in complexity. Otherwise you'll find yourself spending a lot of time trying to back-fill all of these processes, and that's a much harder job than just starting off with the right footing.
How much division of labor do you think is ideal in that process. Do you need business analysts, requirements engineers and QA people apart from developers, or is it better to have a team of generalists that talk to the users directly? Cool shirt btw
I think it depends on the size of the project to some extent, but there are hard limits to how far you can divorce dev teams from the whole process. It works best when dev team members are closely involved from the get go. Not necessarily everyone on the team, but some people. Similarly, depending on the domain, you may need some deep technical expertise, so you need access to domain experts. You may need other people involved, but key is that this isn’t done with hand-overs, but through collaboration at each small step. This all sounds more complex than it really is, I think. In my experience, this is a lot easier than any of the alternatives.
Hi Dave!! Thank you for your videos. I have a question in my mind. I am a big supporter of CI/CD, but I always puzzling me this idea: If I integrate continuously with small steps directly to main (TBD), this I do several times a day, and deploy with each integration, if my deploy takes about 1 hour, with several devs and teams doing the same thing, wouldn't I have a bottleneck in the deploy? How are these problems currently being solved? Thank you in advance
There are a few ways that you can cope with this. Optimise the deployment! Look to see if you can speed up the deployment process through automation, and through optimising the code. If you are doing data migration and that is slow, consider runtime, rather than deployment-time, migration techniques. Allow incremental deployment, just deploy the parts of the system that have changed. Allow distributed deployment, break the system into smaller, independently deployable pieces that you can deploy without need to change, or test, against the others. This is the true Microservice approach.
my manager always tell us to invent a solution based on a fuzzy 2 line requirement heard in a chat or during a random meeting, then after a week or 2 we go to the customer with our idea,(already in DEV) ,that is obviously wrong, and they then define the idea more precisely and we basically delete everything we have done for 1 or 2 weeks and restart. Can someone more experienced than me try to explain me why he does something like this and if this is a wrong approach or there is something to it that i am missing? In my mind the perfect approach is to start with a very solid understanding of what they want and then touch the code.. and this video seems to somewhat cofirm but it also say to start as soon as possible with something working so i honestly don't understand if inventing is part of making the customer understand the problem better..
Hey Dave, thank you very much for your content. I really enjoyed this and many of your other videos and books. Basically, this process sounds very reasonable to me. In many teams I worked, a lot of problems appeared because we focused on technical solutions and not user problems. This process proposes a better way. I still have a question though: What concretely do you mean here with executable specification? At the beginning, you do not have any solution (which is good). To solve a user need, there could be many very different solutions. I get, that we can write a specification upfront, since it focuses on the user problem. But how can we make it executable without knowing how this user problem is solved? Currently, I'm having some kind of cucumber spec in mind and I can't imagine implementing the test steps without a solution in mind.
At about 14:36 in the video, you talk about the design phase. This is after the executable specification. The problem I have is that the UX/UI takes time to hash out and get confirmed with the stakeholders. If the dev team commits a story to a sprint, then they only have two weeks to do it (stories should fit in a single sprint), most of which will go to UX/UI design and leave no time for coding. Is the best solution to this problem to have separate UX and dev sprints, where stories go through UX sprint and come out ready for dev sprint? Of course, there would be at least one dev in the UX meetings. And, I realize, some stories don't need much UX, so they might skip the UX sprint and go straight to dev, which is good because it would help keep UX from being a bottleneck. Anyway, does this sound like the right track?
Well if you are doing UX/UI that way, I'd say that there are better ways to organise things. If every story goes through a separate UI team before it is "developed" then this is a hugely inefficient approach. Development is development, and that includes the UI. So find ways to organise that allow you to do the UI design as part of the story development. Style guides for most normal changes is a much better way of doing things than delegating UI design to a separate group, for example.
@@ContinuousDelivery Well, it's not every story that needs UX/UI design. But when we come to a new type of interaction, we do like to spend some time and get it right, usually with a prototype and some back and forth discussion with a developer and the domain experts. It's hard to fit all that into the same sprint where we develop the feature. Perhaps in these cases we should make a separate story for prototyping the UX? I guess the trick would be to avoid letting that prototyped implementation leak into the acceptance tests for the final story.
Just 2 weeks ago, Amazon lost the ability to maintain customer authentication & identification between login to the store website, so the user was kicked out with a 503 error. If you say “so what; nobody noticed”, then I’ll say your reasoning becomes faulty because systems are not designed to go down … only the people behind them.
What's with the overwhelming fixation on "not breaking the tests"? I sense that LOTS of testers are spending so much time on maintaining automated GUI checks they're not really looking at the product as real human beings would look at it. Check outside the lab: no person who is actually using your web site is obsessing over locators or whether to use explicit or implicit waits. All this effort is hardly "freeing up time for exploratory testing". Here's a question, though: do the managers who are saying "automate everything!" know what this is costing you?
Also. Why would it be the testers that are maintaining the tests? Let the programmers maintain the automated tests. Gojko Adzic has a video called "Sleeping with the enemy" that explains the mindset behind that.
Hmm i think you misunderstood, the idea is to create test that do not break easily, not to maintain test so they are not broken. If the latter happens a lot, people should reconsider their testing strategy ( specially the involvement of tester and dev into it, like mentioned above ), because i totally agree with you this can be a waste of time better spent elsewhere.
@Daniel Sandberg Testing is-among other things-using both tools and direct interaction with the product to question and evaluate its behaviours and states. So in a way anyone carrying out this kind of activity is a "tester".
Unit testing and automated checks are really helpful; it's good to find low-level problems in code at the when they're easy to find. Checking the build for relatively shallow problems, close to the surface, is a really good idea too. However, far too much of what passes for testing these days, in my view, is about demonstrating that we can build the product frequently and that it can work. Now, sometimes shallow testing might be enough. A lot of software isn't that important; low-risk; simple. When money, health, safety, privacy, or fairness are at issue, though, complex systems need deep testing. We need to analyze them deeply, explore them thoroughly, push lots of data through them, given them a good hard shake, uncover hidden risk. We need to develop some experience with using those systems as they will be used, as realistically as possible, before we inflict them on the wider world.
I hope to implement some of these practices in an upcoming project. This may be because I don't have hands on experience yet, I've been confused about how acceptance tests fit. If I'm committing Acceptance tests to my codebase before the story is complete won't my pipeline constantly be in a failing state? Do I need to delay committing new acceptance tests until the feature is completed?
No need to hold off committing, and you should avoid that, instead mark the test as some version of “under-construction” and don’t run them in the pipeline until they are passing. Run them in a dev environment instead.
DB schemas are implementation detail, so you are free to design whatever you want in response to the requirements expressed in terms of user need. I'd do it exactly as I describe the process of any other step in SW dev in this video. Describe what the user wants, go through the steps to create an executable specification that demonstrates that the user-need is met, then design a solution, including a DB schema, that fits. If you are using a DB schema as an integration point between different components, services or apps. First I'd advise against this as a design approach. But if for some reason I decided to do it anyway, then I'd treat that as a design problem in terms of separation of concerns, modularity, abstraction and coupling - like any other integration point.
@@ContinuousDelivery my concern is not the executable specification, my concern is unlike refactoring code, I can't refactor my schema and scatter my data. It seems like that needs some speculative planning, although I wish I didn't have to to the same.
@@swagatochatterjee7104 Yes you can, there is even a book on this topic: "Refactoring Databases: Evolutionary Database Design" Scott Ambler & Pramod Sadalage amzn.to/36BjHrT
Please make real world examples of what is said here. It's a lot of nice word but doesn't mean much or say how to apply that in the real world. The most important part to me is how can we take a legacy and tightly coupled system and bring it there. There isn't a single answers ofc but at least having examples it would be way better.
There are lots of examples. There are several on my channel, checkout some of videos in my “Case Studies” playlist Case Studies th-cam.com/play/PLwLLcwQlnXBzoKPUPouBjd9B_zle3JuYD.html The description of the process was how my team built one of the world’s fastest financial exchanges, at LMAX www.lmax.com/technology
You have possibly got the least intrusive sponsorship spot on all of TH-cam... even your "please buy my book or training courses" is nicely low key. :)
Please actually have solid "real world" applications of these continuous delivery implementations and not just "pie in the sky" ideas leaving viewers hungry for courses/books
That's not really an easy process. It actually goes through all conceivable steps. Maybe "easy" and "software development" don't go together, no matter how you twist them. I have trouble with the "executable specification". What is it executed against when nobody has thought about the design of the implementation, yet? You cannot have feedback from something that doesn't exist. "Yes, but it is like test-driven development and you will fill in the missing parts". Nope. On this level in particular, the design is a dynamic process and you just don't know what will come out when it is finished, therefore there is nothing up-front to describe an execution against. This makes no sense to me unless you get back into the habit of micro-specifying a lot before writing the "executable specification".
Not so! The exec spec defines what the user needs, not how we will achieve it. If you don't know that before you start, then what are you starting on? It may change later, but usually not by very much. I agree with you that there is no real "easy" in software, but I think that this is as easy as it gets.
@@ContinuousDelivery A spec what the user needs. Check. On what kind of machine does this spec execute when the system which is supposed to implement the spec does not exist, yet? How is this machine defined and maintained, what is its scope, how can it give realistic feedback before the actual implementation?
@@hermannschmidt9788 That's not a requirement from the user's perspective in this sense. This is not about the service that is delivered, that is about the mechanism that delivers it. which is separate to these executable specifications. Naturally there is a point where a "translation" needs to happen so that these things are genuinely "executable", but before that point, they don't need to, and shouldn't, say anything about what is required for that translation. If you'd like to learn more, I have a very good training course on exactly these topics 😉
@@ContinuousDelivery Well, I've seen such executable specs (BDD style) and they were nothing but glorified tests that needed lots of extra work to supply the abstraction layer, which eventually made them executable on the actual implementation. They don't give true feedback in the non-executable stage. I have doubts about the artificial abstraction (as in language) they sit on, which is neither the immediate system the users put their hands on, nor the level of the "real thing" where devs run their tests.
@@hermannschmidt9788 Well, maybe you have seen it done poorly? I have seen this technique used to build some world-class systems in a variety of different industries.
This is a very limited view of software development. Consider the software for the Mars rover. The whole increment and make small changes ideas are clearly are worthless for a project of this nature. In fact you has better understand exactly what is needed want before writing a single line of code. In fact the code generation is the smallest, least interesting and easiest part of the job.
Actually not so. The small increments part *is* how NASA build Mars rovers. They test in simulation of course. There is noting about this approach that forces you to release frequently to production, but building so that your systems are always in a releasable state is the high-quality, safer approach. You don't create complex systems with one single step.
When I worked at Pixar I saw this process unfold in real time. Every day the changes made to an individual asset get pushed to the live version of the film / project and rendered each night. Then the next day everyone reviews the sequences of frames to determine if the small changes worked, and if so what needs to be done next. Every individual code / asset update gets incorporated as soon as it can so it can be tested along with everything else in the rendering. Then small changes can be made today and the tests run overnight to repeat the process again tomorrow.
Dave, I want to stop for a sec and say thank you. You've bring so much important topics to my professional path; in every one of your videos I find wisdom, expertise and caring. Thank you!
Thank you 😊
I concur. Watching Dave's videos continues to add to my confidence, and I love to exercise my psychological safety wherever possible.
One critical point missing from the "Process of translation" part is that there is huge pressure on estimating how long work will take once "Story" is defined. This then forces lots of the follow-up design that needs to be integrated into the story before "real work" begins. I feel you should stress that to make this process work, business management must abandon need to estimate the work, as there is not enough information at the start. And only actually doing the work gives us enough information, and that is often by the end of the full work itself.
Actually heard one of our org leaders say that he was able to achieve "good story work estimation" on one of his previous teams. And that was because lots of the design and implementation was front-loaded during "planning". I interpreted it as lots of the uncertain work being done outside of estimated work time and work itself being straightforward once the critical details were worked out.
Do you really think management should "abandon" asking for estimates, or merely defer asking for them until later in the process? Imagine you are the manager, and as such, you are essentially the buyer of the labor to achieve your goal. Not getting an answer about how long something will take is a lot like walking into a car dealership, asking how much a particular car costs, and being told "we have no idea, but we'll let you know after you agree to buy it." Don't misunderstand; I am a developer myself, not a manager, and I know it's impossible to guess at the beginning of a project how long it will take. Yet managers have every reason to care deeply. They really do need an answer at some point.
it's not as black and white. As a dev and dev manager in the last 15 years - it's so easy for devs to build their sand castles without proper preparation for work or even understanding the domain of problems. Estimating keeps that process in check, obviously in the most inefficient and immature way - but a way it is and it's easy and relatively repeatable. In the end at work you need to bring results out the door and not the "good ideas". If you add to that picture a sad statistic that rarely your team will have many devs with more than 5 years of experience - we get ourselves a pretty nasty situation we need to cope with.
@@CosineKitty Yes. There is often no good reason to estimate when the work will be done. Your analogy with car does not fit in here. If something is important enough, it is unecessary to know how much it will cost, you will still build it, even if it is expensive. Because you expect that payoff will be at least order of magnitute over expected costs.
@@MisFakapek No. Finishing work by deploying into production keeps that process in check.
@@RFalhar this approach doesn't work in less mature teams. In mature ones estimates are not needed, we agree on that. I also agree that the best measure of progress is code on production but again.. it's not black and white
Just wanted to drop by and say, the only thing more consistently of high quality than the content, is the quality of Dave's T-shirts 👕
Great content, now it's time to convince CTO, Release Manager, QA manager, Product manager to change the way of working
The approach I describe in this video is available for you to learn on-line in my Continuous Delivery course "Better Software Faster". TAKE A LOOK ➡ courses.cd.training/courses/cd-better-sw-faster
and watch a free preview.
The irony of this approach being so well suited for regulated companies, yet it's regulated companies who are most likely to push back on this approach because: "we're regulated".
Beyond Coding Podcast would be a great place for Dave for feature. Patrick asks great questions and Dave is a store of information. I'd love to make the introduction if you're not closed to it
How I describe SWE in conversation: "Software engineering is a process of translating the inner thoughts of humans into a set of computational functions through a series of iterative learnings."
I'd love to see more videos on requirements. Just because I'm a developer doesn't make me able to write specs. All too often I've seen projects where the business owners go straight to a developer, and the developer just starts writing code.
Here you have everything you need to know about requirements. The best way to develop is to start writing code despite a requirement is not perfectly defined. You implement it step by step and after each step owner should check it and give you feedback so you can continue with the next step.
@@tongobong1 So, you're saying just wing it?
@@esra_erimez yes just start coding the initial basic idea.
Shhhh. Agile doesn't write requirements.
@@esra_erimez don't listen to these
Dave, thank you for the work you are doing for the CI/CD community. There is still one topic I am struggling to understand, however. How do we deal with CD for projects supporting multiple release lines? Where one story/commit needs to be integrated into several release versions? It is something I am unable to find any goo resources on. Do you have any though/words of advice on this?
Your blog is pure gold.
I just think the companies has evolved faster in the Downstream than in the Upstream. I mean, once de specifications are Ready the team can deliver fast with CI/CD Pipelines, but looks like people in the Upstream don't know how to work like that yet. In other words, the Cycle time is fast but the total Lead Time is long.
About login pages. I've heard from others that it is wrong to have a User Story even mentioning the login. If I were working on a project you are managing and I'm coding components of the Login page: What are some examples of paths that I could encounter if I do a backtracking of the "process of translations" from where I'm hypothetically located (Design & Implementation) all the way to the "Vage wish"?
Rephrasing: If you are in the "Design & Implementation" phase and coding Specifically the "Login page" of a System, backtracking the breadcrumbs in the process: What are examples of actual "Executable specification", "Examples", "Stories", "Vage whish"? But if only one example I'm interested in the "Stories".
A long , difficult and important journey requires simple small steps.
Happy Programming.
Agreed. Regulated SW systems design will greatly benefit implementing similar automated requirement process you described here (with some abstraction).
Growing the code base incrementally is ideally the best one, but in actuality, when starting a project, everyone is concern to ship the whole thing at once asap because the company is running out of budget.
Unfortunately, the software industry still relies on artifacts that are not code: docker images, jar, exe files, dependency registries, etc. This is necessary "glue" to execute actual code. But the simplest solution would be to have a runtime to execute code as soon as it was "pushed" to the code repo. Unison programming language is trying to just that. It is still in an early alpha state, but I hope such an approach becomes a norm in the future.
Thank you. This was eye opening, especially the part about how to turn a vague wish into implementation.
Glad it was helpful!
Very interesting!
One thing I don't completely understand is how you can continuously check for releasability when the system has obviously not been built yet. My guess is that "releasability" is not a yes/no decision but say a percentage of how much of the system is releasable. Comments?
This is a very interesting approach. THank you, David!
From 11:30 onwards its great example of failing at user story step. Mixing the needs with solution at early stage. Hard for most junior and mid level software developers to understand this problem.
Excellent description with visuals and I love the T-shirt too.
Glad you like it!
Dave, I need to help organize a team of 20 people (architects, developers and tester) that today are doing a very poor job on the new MES system my company is developing. I am mechanical engineer, so coding is not really my cup of tea. But I am sure we can make a much better job if we put our resouces on the correct places. What you recomend me to read first, and trainings I could take second?
About thirty years ago I watched a video about paradigm thinking. Paradigm thinking is when a person's concept of something is artificially narrowed for no valid reason.
For instance, the man who invented the quartz movement for watches was Swiss. The Swiss watch manufacturers, who dominated the market, were not interested in his discovery. In their thinking, it wasn't really a watch because it didn't run on springs and gears. He found a more receptive audience among the Japanese, to whom a watch was a wearable device that told you the time. It turned out that the watch-buying public had the same idea as the Japanese, and delivered the lion's share of the market to the Japanese.
Software development managers can be guilty of the same thing. Management is done a certain way and no other, and any suggestion that we abandon the concept of deadlines is abandoning management entirely. We have to assign a point value to each project, and track how many of these points each developer accomplishes during the year, because we're not really managing if we do it some other way. We do performance review because that's how management is supposed to be done. And so on.
Thank you! I’ve seen all what you mentioned in all my passed work experience except performance testing. In a fast paced environment, I’ve never seen performance tests being run within a continuous integration environment. There are separate performance improvements projects though. While slow paced integration, 6 months and above releases, there were performance tests done before the release.
At LMAX where we built one of the world's highest performance financial exchanges, we did continuous performance testing at two levels. We did component level and whole system level perf tests. Both were implemented as "Pass/Fail" tests, based on thresholds of throughput and latency.
It was all run in our deployment pipeline and our whole pipeline evaluated everything, including the perf tests in under 56 minutes.
@@ContinuousDelivery Thank you. I would love to work at companies that value high quality measures. However in my experience, most companies and specially at the startup phase, do not care about quality measures whatsoever and makes me a sad engineer.
@@dodandos yes, that is true, but it is also true that over 95% of startups fail, so maybe there is some correlation? Just sayin' 😉
I really enjoy your content, and I've read all of your books 🙂 - thank you for all you've done for the community.
The approach you describe seems really good for "big service-like software development processes", and I've had my share of those for the last twenty years.
But let's say you're coding something like a synthesiser or some other more creative tool where your task is to "Figure out what's possible". What are your thoughts on that kind of software projects? Something where you're building something that's really primarily research from the developers. Because we're trying to build "what can be done", but the initial wish isn't really definable. Another example could be a game, where it should be "fun", where it's hard to actually know whether or not what you're doing is "fun". So you need to have man multiple "ways you're going", paths of research or so. But those long paths may be discarded when they finally are abandoned... I'm rambling a bit here, but I get to work on these projects, and I can't apply your ideas readily.
If you are talking about music synthesizer, natural scope could be categorised for example through frequency, waveform, delta for the frequency and/or waveform and also esthetical aspects connected to different combinations in practice. Doing something human cannot hear or feel or distinguish any way probably is not useful to your project even when it is doable.
@@timop6340 Thank you.
I'm absolutely hearing your suggestion, and it's good in many cases.
My current task is to make "Something new and exciting", and maybe that's my problem, that it's actually research. Maybe I'm looking for a way for software research to combine with CI practices. Like a Continuous Research kind of framework.
"Something new and exciting" is fine as a starting point, but that is nowhere near something that you can build yet. You MUST have some idea to start cutting code. You are not randomly throwing characters into your compiler. So you have some sense of direction to explore. It may well be wrong, as you start exploring this direction, you may discover a new path that looks more interesting. All that is fine, and normal for any type of development.
So at the point at which you think something like - "I think I can do something interesting with more compression & reverb on this part of the signal" (or whatever) then that is the point where you start to define a story, "as a musician, I want to apply compression & reverb only to a specific frequency range". When you find the new thing that is better than my (made-up) idea, then either park or dump the stuff you had. But when you keep things they are better defined, easier to return to, and you know that those that were finished still work, when you made changes.
I don't think that there is any difference between this sort of software, and exploration, and any other. I would argue that SW dev is always a process of exploration.
Thank you! I'm aware it's not a request line. But if it was my birthday I would like to see a chapter in modern software engineering revision ten about strategies for keeping and removing unused code that may be used in the future. Everything I've read and watched has been with the underlying assumption that code goes in - code stays in. Not code gets used, then removed, then maybe not, then maybe again. I know the answer is "it depends", but I think there are also some pointers and ideas... Maybe just shared experiences that could shine some light into this.
I think stories are too small to capture the users' goals. You can use story mapping to shim this or larger interaction design focuses features (low precision) early then break them down into stories level work items to both understand the goal and develop toward it incrementally.
It took me just a brief while to get the point of dependency injection, but once I got it, I soon realized it was massively overused. People declare so many singleton instances for thread-safe classes, it is extraordinary to me how cluttered Spring can make a project become. Unless you really know what you're doing with Spring's autoconfigure algorithm, I would never suggest Spring Boot for a monolith.
As a big fan of dependency injection and I have to agree, it is easy to misuse but when done well it is incredibly powerful tool.
I am finding that bringing up process bottlenecks in scrum ceremonies is helping my team be more conscious of dogmatic behavior. I will often get asked to provide a better perspective. This is where I try to influence the team(s) to adopt the practices you speak about. I have found that a lot of teams want to know the solution before making any estimates, which I think is silly. I am trying to give more direction for folks to focus on the outcome instead.
I do have a question about project managers and story creation/management:
I am often perplexed by project managers wanting to create an entirely new story when a requirement need changes. Why do you think they do that instead of revisiting the previous story and making the appropriate modifications to acceptance criteria?
They dont want to reopen a closed ticket and mess with leads times ? I suspect.
A good idea to go your way and their way is to create an epic which contains the updated specification, containing the 2 stories which shows the history of the requirement.
Thank you for pointing out that this process is only needed for complicated projects. What do you think how many project types does this apply to? 0.0002% or less?
Also in bigger projects you will have single responsibility or not? Monolith or Chaos (like 150 different k8s - microservices with rabbitMQ and full unit and e2e tests on a 5 page wordpress website or an ERP or other trivial things)?
Trust me - starting a "simple" project with this same philosophy will pay dividends when the project inevitably grows in complexity. Otherwise you'll find yourself spending a lot of time trying to back-fill all of these processes, and that's a much harder job than just starting off with the right footing.
How much division of labor do you think is ideal in that process.
Do you need business analysts, requirements engineers and QA people apart from developers, or is it better to have a team of generalists that talk to the users directly?
Cool shirt btw
I think it depends on the size of the project to some extent, but there are hard limits to how far you can divorce dev teams from the whole process. It works best when dev team members are closely involved from the get go. Not necessarily everyone on the team, but some people.
Similarly, depending on the domain, you may need some deep technical expertise, so you need access to domain experts. You may need other people involved, but key is that this isn’t done with hand-overs, but through collaboration at each small step.
This all sounds more complex than it really is, I think. In my experience, this is a lot easier than any of the alternatives.
Hi Dave!! Thank you for your videos. I have a question in my mind.
I am a big supporter of CI/CD, but I always puzzling me this idea:
If I integrate continuously with small steps directly to main (TBD), this I do several times a day, and deploy with each integration, if my deploy takes about 1 hour, with several devs and teams doing the same thing, wouldn't I have a bottleneck in the deploy? How are these problems currently being solved?
Thank you in advance
There are a few ways that you can cope with this.
Optimise the deployment! Look to see if you can speed up the deployment process through automation, and through optimising the code. If you are doing data migration and that is slow, consider runtime, rather than deployment-time, migration techniques.
Allow incremental deployment, just deploy the parts of the system that have changed.
Allow distributed deployment, break the system into smaller, independently deployable pieces that you can deploy without need to change, or test, against the others. This is the true Microservice approach.
Have you seen this applied in the video game industry? I'm looking to try this on our new project. Pretty excited about it!
Yes, th-cam.com/video/8hXRvvFDztg/w-d-xo.html
my manager always tell us to invent a solution based on a fuzzy 2 line requirement heard in a chat or during a random meeting, then after a week or 2 we go to the customer with our idea,(already in DEV) ,that is obviously wrong, and they then define the idea more precisely and we basically delete everything we have done for 1 or 2 weeks and restart. Can someone more experienced than me try to explain me why he does something like this and if this is a wrong approach or there is something to it that i am missing? In my mind the perfect approach is to start with a very solid understanding of what they want and then touch the code.. and this video seems to somewhat cofirm but it also say to start as soon as possible with something working so i honestly don't understand if inventing is part of making the customer understand the problem better..
Hey Dave, thank you very much for your content. I really enjoyed this and many of your other videos and books.
Basically, this process sounds very reasonable to me. In many teams I worked, a lot of problems appeared because we focused on technical solutions and not user problems. This process proposes a better way.
I still have a question though:
What concretely do you mean here with executable specification?
At the beginning, you do not have any solution (which is good). To solve a user need, there could be many very different solutions. I get, that we can write a specification upfront, since it focuses on the user problem. But how can we make it executable without knowing how this user problem is solved? Currently, I'm having some kind of cucumber spec in mind and I can't imagine implementing the test steps without a solution in mind.
Excellent talk
Thanks 😊
At about 14:36 in the video, you talk about the design phase. This is after the executable specification. The problem I have is that the UX/UI takes time to hash out and get confirmed with the stakeholders. If the dev team commits a story to a sprint, then they only have two weeks to do it (stories should fit in a single sprint), most of which will go to UX/UI design and leave no time for coding. Is the best solution to this problem to have separate UX and dev sprints, where stories go through UX sprint and come out ready for dev sprint?
Of course, there would be at least one dev in the UX meetings. And, I realize, some stories don't need much UX, so they might skip the UX sprint and go straight to dev, which is good because it would help keep UX from being a bottleneck. Anyway, does this sound like the right track?
Well if you are doing UX/UI that way, I'd say that there are better ways to organise things. If every story goes through a separate UI team before it is "developed" then this is a hugely inefficient approach. Development is development, and that includes the UI. So find ways to organise that allow you to do the UI design as part of the story development. Style guides for most normal changes is a much better way of doing things than delegating UI design to a separate group, for example.
@@ContinuousDelivery Well, it's not every story that needs UX/UI design. But when we come to a new type of interaction, we do like to spend some time and get it right, usually with a prototype and some back and forth discussion with a developer and the domain experts. It's hard to fit all that into the same sprint where we develop the feature. Perhaps in these cases we should make a separate story for prototyping the UX? I guess the trick would be to avoid letting that prototyped implementation leak into the acceptance tests for the final story.
@@adamschaff4397 Yes, and for those stories, draft-in a UX/UI expert to work on the new ideas along with the dev team as part of the development.
Great lecture!
That shirt is epic!!!
gold content!
It’s so simple and obvious. Yet, I have never seen it in real life. No matter how many people tried to enable this.
I think it is "simple and obvious" once you have seen it and not necessarily before.
I think that the best ideas always look like that.
Just 2 weeks ago, Amazon lost the ability to maintain customer authentication & identification between login to the store website, so the user was kicked out with a 503 error. If you say “so what; nobody noticed”, then I’ll say your reasoning becomes faulty because systems are not designed to go down … only the people behind them.
What's with the overwhelming fixation on "not breaking the tests"? I sense that LOTS of testers are spending so much time on maintaining automated GUI checks they're not really looking at the product as real human beings would look at it. Check outside the lab: no person who is actually using your web site is obsessing over locators or whether to use explicit or implicit waits. All this effort is hardly "freeing up time for exploratory testing". Here's a question, though: do the managers who are saying "automate everything!" know what this is costing you?
The fixation is that you write tests that *are looking at the product as a human being*. Then they are the same thing.
Also. Why would it be the testers that are maintaining the tests? Let the programmers maintain the automated tests. Gojko Adzic has a video called "Sleeping with the enemy" that explains the mindset behind that.
Hmm i think you misunderstood, the idea is to create test that do not break easily, not to maintain test so they are not broken.
If the latter happens a lot, people should reconsider their testing strategy ( specially the involvement of tester and dev into it, like mentioned above ), because i totally agree with you this can be a waste of time better spent elsewhere.
@Daniel Sandberg Testing is-among other things-using both tools and direct interaction with the product to question and evaluate its behaviours and states. So in a way anyone carrying out this kind of activity is a "tester".
Unit testing and automated checks are really helpful; it's good to find low-level problems in code at the when they're easy to find. Checking the build for relatively shallow problems, close to the surface, is a really good idea too.
However, far too much of what passes for testing these days, in my view, is about demonstrating that we can build the product frequently and that it can work. Now, sometimes shallow testing might be enough. A lot of software isn't that important; low-risk; simple.
When money, health, safety, privacy, or fairness are at issue, though, complex systems need deep testing. We need to analyze them deeply, explore them thoroughly, push lots of data through them, given them a good hard shake, uncover hidden risk. We need to develop some experience with using those systems as they will be used, as realistically as possible, before we inflict them on the wider world.
I hope to implement some of these practices in an upcoming project. This may be because I don't have hands on experience yet, I've been confused about how acceptance tests fit. If I'm committing Acceptance tests to my codebase before the story is complete won't my pipeline constantly be in a failing state? Do I need to delay committing new acceptance tests until the feature is completed?
No need to hold off committing, and you should avoid that, instead mark the test as some version of “under-construction” and don’t run them in the pipeline until they are passing. Run them in a dev environment instead.
@@ContinuousDelivery thank you for the answer! We are using SpecFlow and it has a method to ignore tests we'll use.
@@LoftyCuber 👍
Nice t-shirt! Amazing content!
Thanks!
That shirt is dope.
wAtERfalL modEL!! Always and everywhere.
I like the shirt! 🙂
How do you develop DB schemas via the Outside In TDD way?
DB schemas are implementation detail, so you are free to design whatever you want in response to the requirements expressed in terms of user need.
I'd do it exactly as I describe the process of any other step in SW dev in this video. Describe what the user wants, go through the steps to create an executable specification that demonstrates that the user-need is met, then design a solution, including a DB schema, that fits.
If you are using a DB schema as an integration point between different components, services or apps. First I'd advise against this as a design approach. But if for some reason I decided to do it anyway, then I'd treat that as a design problem in terms of separation of concerns, modularity, abstraction and coupling - like any other integration point.
@@ContinuousDelivery my concern is not the executable specification, my concern is unlike refactoring code, I can't refactor my schema and scatter my data. It seems like that needs some speculative planning, although I wish I didn't have to to the same.
@@swagatochatterjee7104 Yes you can, there is even a book on this topic: "Refactoring Databases: Evolutionary Database Design" Scott Ambler & Pramod Sadalage amzn.to/36BjHrT
@@ContinuousDelivery thaks a lot
Please make real world examples of what is said here. It's a lot of nice word but doesn't mean much or say how to apply that in the real world.
The most important part to me is how can we take a legacy and tightly coupled system and bring it there. There isn't a single answers ofc but at least having examples it would be way better.
There are lots of examples. There are several on my channel, checkout some of videos in my “Case Studies” playlist Case Studies
th-cam.com/play/PLwLLcwQlnXBzoKPUPouBjd9B_zle3JuYD.html
The description of the process was how my team built one of the world’s fastest financial exchanges, at LMAX www.lmax.com/technology
@@ContinuousDelivery thanks, gonna take a look.
I love that bender shirt ❤
You have possibly got the least intrusive sponsorship spot on all of TH-cam... even your "please buy my book or training courses" is nicely low key. :)
Thank you! We try to get the balance right...
You mean endless Scrum meetings...I mean "ceremonies".... isn't a good way to develop software??
Please actually have solid "real world" applications of these continuous delivery implementations and not just "pie in the sky" ideas leaving viewers hungry for courses/books
That's not really an easy process. It actually goes through all conceivable steps. Maybe "easy" and "software development" don't go together, no matter how you twist them. I have trouble with the "executable specification". What is it executed against when nobody has thought about the design of the implementation, yet? You cannot have feedback from something that doesn't exist. "Yes, but it is like test-driven development and you will fill in the missing parts". Nope. On this level in particular, the design is a dynamic process and you just don't know what will come out when it is finished, therefore there is nothing up-front to describe an execution against. This makes no sense to me unless you get back into the habit of micro-specifying a lot before writing the "executable specification".
Not so! The exec spec defines what the user needs, not how we will achieve it. If you don't know that before you start, then what are you starting on? It may change later, but usually not by very much.
I agree with you that there is no real "easy" in software, but I think that this is as easy as it gets.
@@ContinuousDelivery A spec what the user needs. Check. On what kind of machine does this spec execute when the system which is supposed to implement the spec does not exist, yet? How is this machine defined and maintained, what is its scope, how can it give realistic feedback before the actual implementation?
@@hermannschmidt9788 That's not a requirement from the user's perspective in this sense. This is not about the service that is delivered, that is about the mechanism that delivers it. which is separate to these executable specifications. Naturally there is a point where a "translation" needs to happen so that these things are genuinely "executable", but before that point, they don't need to, and shouldn't, say anything about what is required for that translation. If you'd like to learn more, I have a very good training course on exactly these topics 😉
@@ContinuousDelivery Well, I've seen such executable specs (BDD style) and they were nothing but glorified tests that needed lots of extra work to supply the abstraction layer, which eventually made them executable on the actual implementation. They don't give true feedback in the non-executable stage. I have doubts about the artificial abstraction (as in language) they sit on, which is neither the immediate system the users put their hands on, nor the level of the "real thing" where devs run their tests.
@@hermannschmidt9788 Well, maybe you have seen it done poorly? I have seen this technique used to build some world-class systems in a variety of different industries.
This is a very limited view of software development. Consider the software for the Mars rover. The whole increment and make small changes ideas are clearly are worthless for a project of this nature. In fact you has better understand exactly what is needed want before writing a single line of code. In fact the code generation is the smallest, least interesting and easiest part of the job.
Actually not so. The small increments part *is* how NASA build Mars rovers. They test in simulation of course. There is noting about this approach that forces you to release frequently to production, but building so that your systems are always in a releasable state is the high-quality, safer approach. You don't create complex systems with one single step.
Someone is talking way too much...