The Most Powerful Software Development Process Is The Easiest

What would an ideal software development process look like? What if we could do the minimum amount of work and get the maximum results from it? If we could then surely that would be the best software development process of all. What if we applied software engineering thinking to minimising the work involved in software development, what would we end up with. What is software development process for after all? This is more than only computer science or programming, this is about how we organise our work in order to minimise it, while still maximising the results.

In this episode Dave Farley author of best selling books “Continuous Delivery” and “Modern Software Engineering” defines his parameters for an ideal process, and then shows that we can achieve almost exactly this process in practice, so this approach is both ideal and practical.

-----------------------------------------------------------------------------------

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

-------------------------------------------------------------------------------------

👕 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!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[NoahHornberger]

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.

[orafasistemas]

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!

[RFalhar]

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.

[harry__init__]

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 👕

[marcellocalabresi]

Great content, now it's time to convince CTO, Release Manager, QA manager, Product manager to change the way of working

[Modzybear]

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."

[ChocolateMilkCultLeader]

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

[davemasters]

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".

[esra_erimez]

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.

[disgruntledtoons]

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.

[mikapeltokorpi]

Agreed. Regulated SW systems design will greatly benefit implementing similar automated requirement process you described here (with some abstraction).

[banatibor]

Thank you. This was eye opening, especially the part about how to turn a vague wish into implementation.

[BeckNovaes]

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.

[insertoyouroemail]

I love this video. I would make a slight adjustment regarding including solutions in user stories. If you are onboarding a junior, you can include solutions and be specific in the beginning and gradually be less and less specific. This helps with one of the biggest challenges for juniors; feeling incompetent and imposter syndrome. It usually only takes a month or two to get them comfortable with the process. I've even managed to get very (barely understanding what a function is) junior developers productive this way.

[markhathaway]

Excellent description with visuals and I love the T-shirt too.

[softwaretestinglearninghub]

This is a very interesting approach. THank you, David!

[theisegeberg]

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.

[DAG_]

Have you seen this applied in the video game industry? I'm looking to try this on our new project. Pretty excited about it!

[dodandos]

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.

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".