To kick off a new season, I start with a deep dive into the QUEST framework-which-isn't-a-framework. QUEST is a mnemonic that helps you remember essential software delivery tasks. This previews my upcoming "We Are Developers" conference talk in Berlin 2023.

In this episode, I take a view on the Agile Manifesto, the 5 Ideals from the Unicorn Project as well as John Romero's 10 Programming Principles and rewrite them, group them and then provide you with a way to remember how to apply them (and what they mean) every single day whether in your team, for your teams, or your customer.

NOTES

The Agile Manifesto

https://agilemanifesto.org/

The Five Ideals from the Unicorn Project

https://itrevolution.com/articles/five-ideals-of-devops/

https://richardwbown.com/software-engineering-happiness-the-five-ideals/

Scope: ensure that the team can work on a context over which they have complete control. See Team Topologies, see SOLID principles, see DDD.

Flow: Work in small batches with complete mastery of our domain.

Agility: Make our context better every day. Improve our experience.

Freedom: to experiment, to try without fear.

Delivery: provide solutions to customers with minimal possible overhead.

John Romero’s 10 Programming Principles

https://www.youtube.com/watch?v=IzqdZAYcwfY

https://github.com/anttiviljami/romero-programming-principles

https://richardwbown.com/john-romeros-ten-principles-for-building-great-software/

Kent Beck’s Presentation about Refactoring and Cost of Upfront Design:

https://www.infoq.com/presentations/refactoring-cleaning-code/

It’s a great talk and worth watching. Because it exposes the social side of software development.

QUOTES

Hello and welcome to the Loving Legacy Podcast.

My name is Richard Bown.

I've been working pretty hard on a talk, which I'm gonna be giving

in a few weeks time at the We Are Developers Conference in Berlin.

It's called The Quest for Better Software, and it's.

Based around the framework that I came up with earlier this year, although I

don't wanna call it a framework, I just wanna call it a word, a mnemonic If you,

if you like a way of remembering how we can make our software better every day

and how we can make our software teams maybe a little happier every day too.

So today I'd just like to go through the presentation.

In short, , I'm also sharing this on YouTube, so feel free

to look at the slides and gimme some feedback on there too.

The subject of this talk is about creating better software.

And over the last year or so, I've been catching up with many of the

theories or the books, podcasts, talks around creation of quality software.

Um, after many years of actually building software and being

in the trenches, so to speak.

Um, working with teams, working in teams, working as a software developer myself.

I've seen many things that enable us to improve quality, deliver features

faster to production with more clarity over what the expected outcomes will

be, better results, essentially.

So I have some practical experience, quite a lot of practical experience with this.

I also have now have read quite a lot of theory on this and

listened to various other opinions.

And at one point, or rather towards the end of last year, maybe earlier

this year, I thought, well, this is great having all of these books,

but how do we remember all the stuff that we have to do as an individual?

Because typically when we go into an organization, we're working in a team.

To build some software.

There are very many opinions based on people's experience and

what they've understood, learned, read their education and so on.

Um, and it makes it sometimes muddy.

It makes it sometimes quite difficult to understand how we can get the

best out of our software and the best out of ourselves and our team.

Um, every day it becomes sometimes just a case of we are building something, but

we don't know quite why we are doing a certain task, like a quality related task

or maybe a code review or, um, analyzing a pool request or creating an environment

or loading some data for testing.

Some of these things, we just kind of fall into a routine around them.

So in this talk, I wanted to explore some of the best practices that we have in our

industry and which are given to us by our experts, , and maybe make things a little

bit clearer for us every single day.

So the talk is the quest for better software, daily habits, for happy

software teams, and happy customers.

Um, so quite a bold statement, I suppose you'd say, and regarding the talk.

I also want to discuss fear as well, because fear is something which

in a day to day way of working, we shouldn't really come up against.

We don't want to, to feel that.

We want to feel that we can express ourselves in our best way,

especially in a software development job, which is quite creative.

We wanna be able to feel that we can.

Do what we like, um, within certain guidelines, maybe within

certain guardrails in order to express ourselves safely.

, another way of looking at, this is the phrase psychological safety,

which is currently very popular in the world of software engineering,

which enables us, again, to describe a way of expressing ourselves without

feeling that we will encounter fear or without fear of something bad happening.

Um, Also because this is a presentation I'll be giving on a stage in front

of potentially 500 people, fear is something I will be feeling.

I'm pretty sure when I get up on a stage and I heard a great quote,

from Dara O'Brien, the Irish comedian the other day, saying that it's the

prospects of failure that lights the fires, the cold, unused stare of

the audience is a great motivator.

So that's his view on fear.

I think he.

Many, probably 30 years ago, turned a switch in his head to

say, okay, well I might fail, but this is a way that I can motivate

myself to be a success on a stage.

So that's a standup comedian's view of how fear can influence them or

encourage them to produce better work.

However, day-to-day as a software engineer, we don't

want to be encountering fear.

We want to be able to feel safe and be able to.

Execute to the best of our abilities.

So how can we do this?

So one of the books I've read over the last year or so has been Kent Beck's,

test Driven Development by Example.

Um, and whilst I wasn't really an XP or T d d follower in any way or at

all, I didn't know very much about it.

I wanted to open my mind and my ideas to.

Different ways of approaching how you build software.

And I have to say, when I read this book, when I read test driven development,

um, by example, I suddenly thought, aha, okay, this is what I've been missing.

Because test driven development is all about writing tests

before you write the code.

So writing a failing test first, then writing, , a piece of code which will

pass the test and then refactoring that code to make it better and make it more.

Neat, tidy, um, cleaner and so forth.

That's essentially what test driven development is about.

So you change, you flip, change the dynamic, you flip it around so that

you will create the tests first.

So inevitably you will have good coverage because you'll have tests.

Covering every single piece of code that you write.

You will also think about your design.

It forces you to think about your design as you go because you will encounter

way that your code is being used as the first thing you need to think about.

And a lot of the time as coders, as software engineers, we see a

requirement or someone's asked us to do, to do a piece of work, and we will

go and write some code to do that?

So we'll create a class or a couple of classes and we'll hook them

together and they will do something.

But we don't typically think about, okay, well how is it gonna

be used further down the line?

Essentially, unless you do make that flip and you say, flip in your

head and you say, okay, I'm gonna deliberately write the test first.

This is what TDD is all about.

It forces you to design as you go along.

And consequently, I watched a, I recently watched a YouTube of his,

it was around his stuff, all his good stuff, he was talking about a new

book, which he's writing at the moment.

Um, and this was a quote from the beginning of that book, , which

really struck home with me as well, which is software design is an

exercise in human relationships.

, and that.

Tallys with a lot of the feelings that I have around how software, good software

is built and deployed, and also how customers come to see that software too.

So as, a quote that I could be use to maybe sum up this talk, it's essentially

this software design designers and excise in human relationships.

, so test driven development by example, as I've mentioned by Ken Beck.

Okay.

Onto the subject of my talk, which is something that I also saw the other day,

um, and I'm not sure if it's entirely serious by the author, but I do have a bit

of a problem with lists of things to do or not do, and you, what you'll see as we

get into this talk is that essentially, I've got lots of lists in there.

Yeah.

Lots of lists of things that we should think about, things that we should

probably consider, things that we should do, best practices, et cetera.

And it becomes quite unmanageable because we can only keep a few things

in our head, as I'm sure you know.

Um, and as a man you end up having even fewer things in our head cuz we

get very easily distracted by stuff.

So.

How can we possibly hope to keep all of these best practices, all these

ideas, all of these things that we read no matter how good the quality of the

source, and how well intentioned and well presented, all of these various

ideas are, how can we keep them all in our head, keep them all practical.

So today I'm gonna be focusing on three pieces of work.

These are.

The manifesto for Agile software Development, the Unicorn Project by

Gene Kim, who's also, um, co-author of Accelerate, is also co-author

of the Phoenix Project all around DevOps maven and very sensible

guy who knows a lot about DevOps.

Um, There's the DevOp Enterprise Summit that he's always appearing at.

I think his company also runs that as well.

So he's a name in the world.

World.

DevOps, the Manifesto for Agile software development, obviously.

Um, I hope you've all heard of that.

If you're working in.

Professional commercial software development today.

It's kind of underpins a lot of the things that we do day

to day, the way that we work.

Um, scrum, lean, Kanban, et cetera.

Um, individuals over interactions and also signed by many great software

engineers, although all of them unfortunately I noticed are male.

But it was, you know, 20 years ago before apparently female

software engineers existed.

That was a joke.

Sorry.

Um.

No, that's the, that's also the point as well.

It's not a joke.

But including Kent Beck, um, and Robert C.

Martin and many others, famous people and the.

The person down on the bottom right there you'll see is John Romero, who was

one of the founders of its software.

And together with other couple of other guys, they wrote Doom and

Quake and many other games, which I spent way too much time playing when

I was at university, when I should have been working on other stuff.

Um, but his 10 programming.

TIPS or 10 software development tips also feature in this torque.

So without further ado, onto the first one, which is the Manifesto

for Agile software development

. So Agile is something which has

for do we need to it anymore?

And previous to that, it's always been, um, before Agile existed,

before the idea of Agile existed, it was Prince two or other software

management philosophies, which tended to be very waterfall in their approach

to software delivery, which meant.

That you would get, gather some requirements from a customer, turn those

into specifications, and then drop them down to maybe design a design phase, work

alongside some developers or designers to create some designs and then drop

it down into a phrase of development, which when some code would get written

and then that would stop, and then that would fall off into a phase of testing,

and then some testing would, or quality assurance, and then that would continue.

Until it stopped and fall off into a another phase of testing or qu

or customer acceptance or another round of development, who knows?

You know, it was waterfall it, it went in steps essentially through our process.

Agile was a reaction to that, and it said, well, We understand fundamentally that

we're not gonna get specifications, right?

So therefore, why don't we make it faster?

And why do we make this that feedback loop quicker?

How can we make that quicker?

And to do that, we prefer to un to work with, um, prefer to work

iteratively closer together with our customers, closer together with

our release in our release cycles.

Um, and the various.

Tips, I suppose you call it, or principles that came from this

are preferring individuals and interactions over processes and tools,

working software over comprehensive documentation, customer collaboration

over contract negotiation, responding to change over, following a plan.

So basically keep it nice and loose, but let's focus on delivering stuff.

Great idea.

A great idea, which has somehow become.

Lost maybe over the last 20 or more years and to a point now where we have kind of

seen a bit of pushback from around Agile processes around Scrum to just, well,

let's just build some code that works.

However, agile still underpins a lot of what we do and a lot of the terms there,

maybe familiar to a lot of you, so.

To analyze it in more detail.

I looked at the principles, the 12 principles behind the

manifesto, the four main points.

I don't think there is any argument about that.

We do want to work with people better, and we do with e with each other.

We do want to have better software, uh, working software.

We want to work closer with our customers, and we want to respond to change faster.

Those are all great points.

I can't argue with those.

So, okay, so the manifesto for Agile Software Development, um, which

has 12 principles as part of it.

We have the five ideals of the unicorn project, which are locality

and simplicity, focus, flow and joy, improvement of daily work,

psychological safety, and customer focus.

Plus we have John Romero's 10 programming Principles, and I'm gonna go through

all of these in turn and break them down and then reassemble them.

So starting with the manifesto for Agile software development, we see number one.

Our highest priority is to satisfy the customer through early and continuous

delivery of valuable software.

And I think you'll agree that this is a good priority.

It needs to be early, it needs to be valuable, and continuous delivery.

Well, we can debate that one, but I think this is a good

one to take along with this.

Number two, welcome changing requirements.

Even late in development, agile processes aren't as change for the

customer's competitive advantage.

Well, I think in some ways this is a restatement to the first one, um, but

it's a good one to maybe take along.

We'll keep it in amber, which means we'll take it along with us.

Number three is deliver working software frequently from a couple of

weeks to a couple of months with a preference to the shorter timescale.

Well, I think we've already said this in number one, so

we're gonna discard this one.

Number four, business people and developers must work together

daily throughout the project.

I think this is a good one.

Let's keep it.

Number five, likewise build projects around motivated individuals.

Give the environment and support they need and trust them to get the job done.

Yeah, we keep on on Number six.

The most efficient and effective method of conveying information to and within

a development team is face-to-face.

Okay, we say that's screen for the minute.

We will tweak it slightly later because a lot of us are remote these days.

Number seven, working software is the primary measure of progress.

Well, I would disagree with this.

I think working software is great, but it needs to be working

software, which is actually doing what the customer needs it to do.

That's more important, so we will ignore this one.

Likewise, number eight, agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain

a constant pace indefinitely.

I don't think this is useful.

I believe agile processes promot a way of maybe promoting themselves as part

of the way that we, you move forward.

They don't themselves promote sustainable development, whatever that actually means.

Um, when constant pace is a little bit, I would say overrated.

We want to be able to change pace for sure.

We want to be able release stuff when we want to, but I don't think constant pace

is particularly useful or achievable.

Number nine, continuous attention to technical excellence and

good design enhances agility.

I think we can agree that that's a good thing to think

about and take along with us.

Number 10, simplicity.

The art of maximizing the amount of work not done is essential.

Agree.

Um, 11.

The best architecture's, requirements and designs emerge from self-organizing teams.

I would say maybe, but definitely not true.

And finally, at regular intervals, the team reflects on how to become

more effective than tunes and just its behavior accordingly.

Now, I agree with this in concept.

However, I believe what I'm trying to propose is that we

don't make it a regular interval.

We make it continuous.

So I'm not gonna take this along, I'm gonna build it into our process.

So those are the 12 Agile principles.

And from my, from my opinion, the important ones are the ones in green.

The ones in orange are ones that we should definitely

consider and take along with us.

And the ones in red are either duplicates or perhaps misstate something, or

perhaps are already wound up in our, or bundled into our process that we're gonna

take forward just to simplify things.

And we're gonna get rid of the ones in red.

Okay, so moving on to the five ideals.

These come from the book, the Unicorn Project and the Unicorn Project is a

work of fiction written by Gene Kim, and it is the follow up to the Phoenix

project book, which was based on same company called Parts Unlimited, who are.

A American company who are selling car parts, secondhand car parts, I think

also new car parts, um, through a, through a chain of stores in the US

and they also have an online presence.

And they've realized that they're a company which is kind of at the mercy of

its software and IT systems and for too long has still pretended that it's, it's

just a car parts company rather than a.

An internet business or a business that sells online, therefore, it's

kind of realizing too late that it needs to improve its systems.

And the first book, the Phoenix Project, is all about the operations of the IT

operations and also systems thinking.

A lot of talk around, um, ideas that are created, um, or, or discussed in

the goal by you, like gold rat, um, systems thinking like I mentioned, also

lean, uh, Toyota production system.

Lots of those ideas come into the first book, in the second book is

more around software development.

So the Unicorn project is more around software development process, how

teams work together, how individuals feel, , or how they can express

themselves in the context of the system.

So some systems thinking does in as well, but Unicom project is

very much more about software development, but both are excellent.

I would recommend you read both of them.

, I found both books.

As someone who's had experience in these kind of projects

are very relatable as well.

They're kind of like, get out of my brain.

You know, because they do provide such insight into the

way things work in industry, the, ideas that people have around.

Imposing more structure to make things better, um, is kind

of counter counterproductive.

That that idea is core to certainly, well probably both books, but certainly

the Phoenix project as well, around how the, the default reaction in lots

of circumstances is to create more process around our, for example, release

processes or our quality processes.

so the five ideals of software development are number one, locality and simplicity.

So this means being able to make changes.

As a team in your own scope, that is building, testing and deploying without

being dependent on other teams or their work, which means a simple code base

which is not tightly coupled to the rest.

, so ideally, maybe again, you could think about architectures.

You could work in a scope where a team has complete control over their context.

A lot of these ideas discussed in books like Team Topology or perhaps we

can understand some SOLID principles or perhaps even architectures such

as microservices architecture.

So that's locality and simplicity, how teams can get delivery

towards the customer quickly.

And secondly, related to that, comes from the first.

Focus, flow and joy.

If the work is decoupled and independent, then teams can feel they're

achieving flow through their work.

And this means being able to get stuff through to production quickly and again.

Number three, improvement of daily work means that the teams or the

individuals can address technical debt and architecture decisions every day to

make their own code better, to make their improve, their feeling that every day they

can do something to improve the next day.

There's a great quote from Gene Kim in Accelerate where he says

it's important to raise awareness amongst technology leaders about how

technical debt and legacy systems slow down valuable development work.

And number three is all about addressing that as we go.

So number four,

psychological safety.

And as we mentioned earlier, it is being able to work without fear.

To try without fear, and according to accelerate, according to the um,

Dora reports and the research that goes on every year around teams

and high performing organizations when it for software delivery,

psychological safety is one of the top predictors of team performance.

It's a good thing to, that people can express themselves essentially in teams.

Finally, customer focus.

So this is of course providing solutions to customers with minimal possible

overhead, continuous delivery of value.

, basically , putting the customer at the center of everything that we do.

And what I've done is I've gone through these and renamed them

slightly or reworded them in order to make them fit in with the other

concepts that we already have.

So locality and simplicity.

I've changed this to scope to ensure that the team can work on a context of

which they have comp, complete control.

See team topologies, solid principles.

D, D, D, focus, flow, and joy.

Flow work in small batches with a complete mastery of our domain

improvement of daily work.

This is around agility, making our context better every day,

improving our experience.

Psychological safety, freedom to experiment, to try without

fear, and customer focused.

This is about delivery, providing solutions to customers with

minimal possible overhead, continuous delivery of value.

So we have now done the 12 Agile principles.

We have done the five ideals of software dev development by Gene Kim.

Now we're on to the last leg, John Romes 10 programming principles.

Thank you for keeping with me this long.

I didn't realize this talk was so long.

It is now way too long, but I will edit it down and I will use

this podcast to give myself some feedback, which I can take into my

talk, which is only 25 minutes long.

So thank you for sticking with me.

And here's the last third.

So John Romero's, 10 programming principles, no

prototypes, polishes, you go.

But I've renamed this deliver stuff quickly and continuously.

Number two, make it always deployable, runnable, and it in

this case is your software, which I've renamed as focus on robustness.

Number three, keep your code absolutely simple, which is simplification,

helps the code stay more maintainable.

Number four, great tools.

Make great software.

Use or build the right tools.

Time to get important tools, right?

Number five, test your own code, deliver quality.

Number six, if you see a bug, fix it quality all the time,

or you incur technical debt.

Number seven, use the right tools to help you build the right code.

Number eight, write your code for this piece of software only code in the now.

Focus on what you're delivering.

Number nine, encapsulate functionality to ensure design,

consistency, architectural decisions.

Should enable good customer experience, design, and code for the customer.

Number 10, code transparently, code for the team.

And I've said on this one, be thoughtful towards others in your team.

So those are rewording of John Romero's 10 programming principles done Very quickly.

I will link his talk below as well.

You should check it out so we have.

The 10 programming principles of John Romero.

We have the five ideals of Gene Kim.

We have the 12 Agile principles.

What do we do now?

Well, what I did is I grouped them and I grouped them like this, so we will see.

Be thoughtful towards others in your team.

Ensure that the team can work in a context over which they have complete control.

Work in small batches with complete mastery of our domain.

Freedom to experiment, to try without fear.

Work with motivated players.

I've lumped these all together under the name team.

Number two, keep workflow simple and focused.

Focus on robustness.

Keep improving our code base and design simplification helps the code

stay more maintainable code in the now use or build the right tools.

I take time to get the important tools right, et cetera.

I've put these under simplicity.

Number three, Accepting changes late in the process, delivering

stuff quickly and continuously.

And you'll see this one, this is the third part of the acronym.

This has the a mixture of all three.

Source materials in here as well.

So we have accept changes late in the process, which

is from the Agile manifesto.

Deliver stuff quickly and continuously from John Romero.

We have delivery, provide solutions to customers with minimal possible

overhead from the five ideals along with continuous delivery value.

Um, and I've lumped these together under the customer label, but

I've called it end user because it works better with the acronym.

That's our third number four, freedom to experiment, to try without fear.

Be thoughtful towards others in your team, working in small

batches, working within your scope.

Within the scope you have complete control over.

This is obviously about being, in this case, what I've call Call is unrestricted.

Unrestricted means that you as a team, Have the ability to do whatever you like.

You have , lack of fear.

So this is certainly around psychological safety.

And within your world, you can do whatever you like to express yourselves

in order to, , meet your goals and deliver better quality software.

And finally, I.

There's just two points here, both from John Romero, which is not really

necessarily brought up in the others.

Maybe implied and maybe this is the end result of what you get.

But this is all around delivering quality, quality all the time.

So the final letter is Q for quality.

Therefore, you see we have quests, Q U E S T, quality, unrestricted

end user simplicity, and team.

Somehow we got there through.

All of those pieces of work and those pieces of work are

in themselves, summations of lots of other pieces of work.

So I hope in some ways this has provided a a way that we can consider every

day how we can think about ourselves, how we can think about our team,

how we can think about our software, and how we can act on it as well.

So quality first Q, first end user in the middle.

Customer end user at the center of everything.

If you just remember those two points, then perhaps I'd have done my job.

Quality unrestricted end user simplicity team, thank you

so much for sticking with me.

It's been a real honor to go through this.

For you for the first time ever, and I hope you find this useful.

Please let me know in the comments and please get in touch if you're having some

success applying this to your daily work.

This is Richard Bown for the Loving Legacy Podcast, wishing