Simon Lasselsberger: Beyond Boring Text: Treating Your Architecture Documentation Like a Product

In this talk, Simon Lassberg discusses the importance of transforming software architecture documentation from a dry and tedious task into a dynamic product that fosters collaboration and understanding among technical teams. He shares his journey from being a chip designer to taking ownership of software architecture documentation at Runtastic, emphasizing the need for structured communication around architecture as organizations grow. Lassberg introduces the concept of the 'guidebook', a living documentation platform that not only maintains the architectural clarity but also integrates seamlessly into existing development processes using tools like Git and CI/CD pipelines. He outlines best practices and encourages a culture of collaboration through architecture decision records (ADRs) and regular architecture forums. This approach ensures that documentation is not just a checkbox activity, but a vital tool that supports the team’s shared understanding and alignment in the development process.

[Music] it's time for our next talk and I'm expecting plenty of questions to be dropped in for the Q&A section the end on this one cuz we've all been there we've all had those boring documentations no one wants to read them no one wants to look at them well guess what Simon lassberg is here to teach us about sexying up our documentation hi uh yeah I I

I hope so to do that so that's that's also the the topic of my talk yeah Beyond boring text we need to treat our architecture documentation like a product we have all been there but what picture comes to your mind when you think about documentation think about it real quick could it be that it looks and feels a little bit like this I felt bored and annoyed

when I had to document things all the time I always felt like that uh when I got the opportunity to formally take over the responsibility of the software architecture of the Austrian St brandastic I felt the same way and I knew that this would mean taking over this responsibility for the architecture would mean that I also have to take over the ownership of our yet non-existent software

documentation because that was a requirement for management but my attitude towards documentation changed dramatically when I fully Embrace The Challenge and uh this led me yeah when I fully embrace the challenge uh let me tell you what I did and maybe inspire you to also see it the way so let's start with a little uh little story in back in 2010 I quit my job as a

chip designer at infinion and started as a developer at R testic the company was still young about a year old and they developed apps that can track your sport activities via GPS and we had about 20,000 users at that time besides the foref founders and three other employees I was the fourth full-time employee we were in full startup mode as you can imagine everybody was totally motivated

and everybody was having a direct impact on a business and we were growing rapidly we clearly focused more on working software rather than on comprehensive documentation but I always kind of felt and tried to make sure that the architecture was evolving with us I felt that this was also very important alignment on the architecture happened implicitly although we didn't really talk or think about it as architecture

itself um we had informal communication and a lot of cross talk since we were all sitting in the room that you see on the slide so we basically communicated all the time that was great that was startup mode fast forward a few years R rentastic grew to around 150 million registered users and we had about 100 to 150 employees as you can see on the slide and

they all came from all around the world so we were pretty international team which was great to have something like this out of Austria we we had a well-designed microservice architecture at that time and a variety of apps and we were acquired at the time by Adidas for €220 million EUR this was obviously a great success and it also gave us the opportunity to buy a second

fbow table which was also great to have but to reach that state we had to evolve our development process initially we didn't put much thought into team structure as we grew we assigned new developers to platform teams that match their skills over the years we released more and more apps as I told you and the company expanded into strategic Fields like cardio strength nutrition and social features

with more than 80 developers the old platform team setup became unsustainable at that time I led the backend team of roughly 25 developers I tried to make sure that our backend architecture remained robust enough to grow with us communication within the back and team feel like we had it in this dark startup mode in the beginning and this was because we all set close together and remained

well aligned alignment with the other platforms though happened on a per project basis without the proper strategic or structured alignment so we decided to switch to an HL development process in the style of Spotify to reduce the communication overhead and the complexity for our product development from a technical perspective this was not hard to do because our existing architecture already supported the new setup we just had

to assign microservices and apps to teams my old job description and role was no longer needed in this new setup but I had the opportunity to take over a new role I became the lead system architect of festic I led the team of three additional Architects focusing on the company's architecture something I always did on the side up to this point but the new development setup also

presented many challenges because the old setup we were aligned on the architecture on a PL platform basis the new setup with the smaller cross functional teams disrupted this alignment totally so we had to address this issue we needed to ensure that the entire development team moved in the same direction in the tech same technical Direction especially and we had to do something about the communication to stay

aligned and by we I mean the group of Architects the job description of an architectect is to own and proactively Foster the common understanding of the design why because the alignment and shared understanding I'm talking about is what we often casually call architecture this is also what Ralph Johnson said in his definition of software architecture he said in most successful pro software projects the expert developers working

on that project have a shared understanding of the system design and this shared understanding is called architecture and I believe the best way to create this shared understanding is through collaboration however we need a structured approach to achieve this simply hoping for alignment to happen naturally is not something that's going to happen at this scale of a company this was the point where I realized that I

could combine something allegedly boring documentation and something I deeply care about the systems architecture to create something more awesome I tried to use the architecture documentation as a communication tool to create the common understanding between our HL teams and actively involve them in this documentation while the first HL value emphasized individuals and interactions over processes and tools I propose using documentation as a tool to support structured

and effective communication among individuals I like to treat this documentation as a product on its own and as working software the documentation I Envision must be useful not necessarily comprehensive and boring products have an audience a purpose and they solve problems for this audience software products need to be developed improved maintained and marketed and this is also how we need to treat our documentation let's give this

product a name and a mission I like to call it the guide book and its mission is this provide a useful engaging and dynamic documentation platform that Fosters and maintains a common understanding of the systems design the guide book aims to solve architecture ual questions for all members of the technical teams ensuring alignment and Clarity across the organization so the guide book documents the overall system architecture

but this is all still very abstract and wague and not actionable so let's take a more concrete look at what the guide book actually is it is a source code repository usually I use git that holds Market down files and additional assets to implement the architectural documentation it gives you a framework and defines what needs to be documented and it gives you hints on how to do

that well and it supports the whole process with tooling and automation one of these automations can and should be used in a CCD pipeline to render the markdown files to HTML and deploy it as static website to an internal web server so that everybody can access it easily there is one obvious question that I always get this why not use a Wiki for this wikis would be

an excellent choice for for this because they are accessible easy to work with and enable collaboration but they lack a lot of important things they lack on transparency and reliability since you typically only have one state of an article so it's hard to maintain a trustworthy State while changes are made and developed and a cation process is also not straightforward to implement on top of a Wiki

with Git on the other hand or any other source Control Management tool you can create branches collaborate on changes and merge a complete change set to the main Branch this main branch serves as a single source of truth of your documentation and respectively of architecture deploying this truth via a cicd pipeline like I said before ensures that your documentation is always up to date and accessible and

therefore also trustworthy for developers and architects who are used to this workflow in their daily coding tasks this is a natural flow of work in the end it's really only just people that are used to this workflow that will work with the guide book so it's also okay to have workflow this leads me to the main characteristics of the guide book it should be access accessible so

it should be accessible fast and easy it should enable collaboration so working with it should encourage open and inclusive collaboration as I said it should be trustworthy its content must be correct reliable and up to-date it should be easy to work with so creating maintaining uh new content uh should be fast and easy it also should be transparent so it must be clear how and why the

content was added and why other things were left out and it should be it should feel alive so it should feel that it is well maintained and that somebody takes care of it and drives It Forward uh with this we can take a first look into to the guide book so on the screenshot you see uh a part of the rendered website you see it has two

main sections the actual content and a section for the process around the guide each main section features multiple subsections you can understand the guide book like this house on top as the roof we have the Y remember we want to Foster the common answer questions for our guide books audience this is achieved by filling the rooms of the house with content about data patterns flows and interfaces

let's take it quick deeper look at them first up is data everything in software relies on data as you know data facilitates communication on technical on a technical level between components and serves as a medium also as a communication medium also for team communication data is an important part of our common language making it crucial to have total Clarity on the names the attributes the values of

our data also in domain driven design maintaining a ubiquitous language is essential to support this I recommend documenting domain models or entities or whatever you would like to call them using uml class diagrams because they're easy to understand and to comprehend all data documentation can be found in the skip repository in the directory data that is located in the content directory I mostly use plant uml as

you can see on the screenshot um with a set of custom macros though to make it easier to work with I also really like to work with wish Studio code as you uh might have guessed because the live preview and all kinds of Integrations and extensions are a Price Less Priceless timesaver and are a lot of fun to work with and in the tooling around the guide

book I also added a lot of default configuration that makes it easy uh to this when this page is deployed it looks like this this is also the usual way how users would consume the information not via the git repository but through the deploy website in the editor I only showed you the actual class diagram but to have proper data Comm communication it's also helpful to have

an article that embeds the class diagram to give more context like the ownership of the data or something like this and also maybe uh reference a structural architecture diagram like you see in the screenshot while it can be challenging to align all platforms on the central data model uh this effort is entirely worthwhile it helps eliminate a common Pitfall where software components have different interpretations of data

or change interfaces without informing others a unified model ensures consistency and transparency it's important to note though that this section doesn't document apis or interfaces it Solly describes the data that is used in the system focus on the data models that are used for communication between components internal data models that are private to a component should be documented should not be documented in the guide book for

sure changes to this data models can be proposed discussed and aligned using architecture decision records this process provides a structured way to handle modifications and ensures all changes are well documented agreed upon by the and agreed upon by the team to maintain the inte Integrity of the domain model but more in this process later let's take a look at the pattern next there is a rather complicated

quote from Fred Brooks uh I will read it out loud real quick I will condent the conceptual Integrity of the most important consideration in system design it is better to have a system amids certain animalist features and improvements but to reflect one set of design ideas then to have one that contains many good but independent and uncoordinated ideas to paraphrase this a little bit and make it

more clear uh I think that Fred Brooks emphasizes that having a consistent and unified design is crucial in system development it's better to leave out uncertain uh to leave out certain unusual features or improvements if they disrupt the overall design coherence a system should reflect a single well- integrated set of ideas rather than a mix of ones and this section is dedicated to maintaining that conception ual

Integrity by uh by covering common structures guidelines and rules these patterns ensure that our system remains coherent and reflects a unified set of design principles like API design guidelines or definitions of unit types like all distances are in meters or so or backend components must follow the hexagonal architecture pattern these are patterns that I'm talking about and I think that are good to have in the section

all pattern articles are located in the pattern directory located in the content directory as well it is advisable to give a short introduction first but quickly get to the point of what the pattern guideline or rule is all about your audience needs the information and doesn't want to read lengthy explanations these articles should be written in a more formal tone than for example flow articles that we

will cover next pattern articles can be viewed as rules or guidelines that must or should be applied while rules may sound rigid and seem to contradict the freedom that HL development promises these are rules and guidelines the team itself has created these are our own boundaries HL teams are free and safe to work within boundaries which makes them fast and if you don't like them we can

change them in an aligned and structured way it's also good practice to follow the conventions of the RFC 2119 which proposes using words like must must not should and should not to clearly Define requirements and recommendations here's an example of the definition of the units of a system you can see in this case it's rather boring text but it has no fluff it gets straight to the

point and provides examples so the audience can understand and find the information quickly if the topic allows it you should draw diagrams this helps your readers to understand and remember longer in this case it's not possible when you just Define units of of your usually these patterns are subject to extensive discussions among the team this is clear because they represent the rules and guidelines that the team

wants to follow be aware of this but don't be afraid to let these discussions happen and join in this is where the architecture takes shape and a common understanding is actually born the next section of the guide book flows it contains articles that describe the features from a technical point of view focusing on the flow of data between software components and the general technical Behavior think of

these articles like blog posts that answer specific questions such as how does the authentication of the mobile clients work or what are the general architectural concepts of our system this approach is inspired by the marketing book they ask you answer which emphasizes addressing the audience's questions directly and remember we always write for an audience if there is no one who will consume your content don't waste time

creating it so if there is no audience if there is no question then it might be useless to actually write an article for it aim for a sweet spot in the level of detail the article must provide relevant information but should not Del too deeply detailed information is likely to become outdated quickly so start at the higher level remember the guide book focuses on the general architecture

not on the details of individual platforms and focus on documenting longlasting aspects this is a little bit similar like what I said before skip temporary information like project progress or working documents you should use uh use interactions and conversations with your fellow developers and Architects or also create some presentations instead flow article articles should only record the decided truths of the current state or of a definitive

future state of your system the flow articles are located in the flows directory in the content directory as you might have guessed these Arctic is benefit almost always from the use of diagrams to enhance the understanding and to enable your audience to remember for a long time a rough default outline of a flow article looks like this so start with a proper title and a general in

introduction then add a structural architectural diagram showing the involved software components I like to use diagrams. net which is also integrated in the guidebook tooling and it's available also within Visual Studio code which is really nice so you C you could check out uh my website last incom diagrams to find out more about my Approach on software architecture diagramming and there is a lot of additional content

available you should also in the next section of such a flow article describe behavior of the feature using uml sequence diagrams or any other pictorial content you could even think about creating animations for example this visual aids help to convey your complex uh interactions more clearly you can see I like to use Graphics a lot because I think graphic material is way easier uh for for our

audience to understand understand it might seem a little bit more work to create these visual representations of data than just writing out text without thinking of a storyline but the time that you spend on creating visual representation of the content is totally worthwhile because your audience has a easier time understanding so be sparse with text but if you write it be precise remember the title of the

talk we want to be Beyond boring text we want to solve our users problems and answer their questions quickly the last content section is a rather small one and it's called interfaces and serves as a central entry point where team members can find documentation about apis for example a link to open API spec or links to descriptions of shared libraries this section May primarily be just a

list of links to resources hosted elsewhere as each platform may have have its own guidelines on how to document its interfaces often these documents are automatically generated out of code the goal of this section is to provide an provide easy access to interface documentation ensuring that the team members can quickly find the information they need to that they need to understand the API and chat libraries effectively

the interfaces documentation can be found in the interfaces directory well and as you can see in the random screenshot there really not more than list I said previously that the guidebook focuses on the general system architecture but the guide book's tooling itself can be added seamlessly to any git repository and this tooling also has an integration for open API documentation I added it here in the screenshot

to show you uh a potential Target of these interface links all of these content sections are there for a reason you can compare these sections to the building blocks of a language data represents nouns patterns acts as gramar flows form sentences by combining data or nouns according to patterns or grammar interfaces vaguely act as verbs or actions that can be performed on the data and although platform

specific documentation is not part of the guide book you can see that platform specific documentation could be seen as orthography the guide book itself represents our common understanding and to understand each other we also need a Common Language and this is why we have these four sections the second top level section of book um is the process and it forms the foundation of the guide books success

it's there to Cate and develop the documentation the guide book thrives on transparency openness and inclusiveness and encouraging everybody to use it move and move it forward and keep it alive process sounds really formal but it only takes two small things a group of technical decision makers that forms the architect forum and meets regularly and the second thing that we need is the usage of architecture decision

records that I mentioned a few already the architecture Forum uh meetings are crucial for reviewing discussing and deciding on current topics ensuring that all changes are well considered and agreed upon by the decision makers and stakeholders it's important to give the permanent members of this meeting the authority to make make decisions independently from my experience the most effective approach to this is to have one Tech leader

architect per platform as permanent member of The Forum in these meetings members can review Penning changes discuss new proposals and ensure that the documentation is is relevant and accurate a good Cadence for the meetings is between weekly and bi-weekly the meetings are open and inclusive and certain topics and for topics additional people such as developers should be invited it's also open for everybody to bring topics to

this architecture Forum so that you can uh ask for uh for support um from from The Forum the discussions and decisions that are made in this meeting are documented in the guide book as well and assigning the ownership of the guide book to the members of this architecture forum is also a critical aspect this group is responsible for driving uh progress ensuring updates are made and maintaining

the quality of the documentation and the toolip this accountability helps in keeping the documentation current reliable and Alive meetings and the definition of the purpose and the members of The Forum are located in the directory and as this process as I said embodies transparency the meeting minutes are deployed to the guide book as well so you can always see what was happening and lastly at the heart

of the guide books workflow is the concept of architecture decision records adrs are concise documents with a defined structure that record the title the status the context the decision and the consequences of architectural changes they provide a transparent way to track changes and decisions in including those declined I will show you an example of an ADR on the next Slide the idea is to have each EDR

reside on a separate branch in your gift repository you can create a merch or pull request if your source code management tool supports this this would allow you for uh to do asynchronous discussions and agreements and provide Clarity and fostering collaboration outside of meetings assigning an owner to each ad R ensures that uh ensures a responsibility and uh and and make sure that progress happens also there

should be no change made to the guide book without an ADR except for types or other minor changes of course by now you might have already guessed it adrs can be found in the directory if you have never seen it the screenshot shows you the template that is used for each new ADR as I said adrs record both what decisions were made and why they were made

they are a great way to communicate the rational behind decisions uh to the rest of the team and to future maintainance of the system the ADR document itself is small and focuses on the why and it just has a rather short documentation on on the uh on the decision uh in general the actual change that is proposed is done in the guide book directly and this change

is also part of the same Branch as the ADR is in the example of the screenshot the ADR document States the need for defining units of attributes and a very short description of the decision details uh for the new guideline is documented in a separate document in the section by now we have covered a lot all of the described sections contribute to the characteristics that I mentioned

before while the tips I showed you uh for the Articles and documents of the different sections also contribute to characteristics characteristic easy to use the tools I boun l in a dockerized setup for the guide book enhance its accessibility and functionality this setup ensures a consistent environment simplifies the deployment and makes it easier for everyone everyone to get started with and contribute to the guidebook ultimately supporting

our goal of fostering a common understanding of the system design and keeping it alive I plan to release this bundle that I call Lok in the next months so if you want to be informed about it follow me uh wherever you like or subscribe to my mailing list at lm.com documentation before I come to an end I'd like to encourage you to think further do whatever contributes

to our overall goal of fostering a common answering our audien's questions remember the guide book is an architectural product and we need to Market it and improve it you could for example um do monthly internal Tech meetups where you invite people to give talks about topics from the guide book or topics about their Daily Business technical talks mostly I did it this uh at fres and it

was a really uh really nice uh event that we had once a month I also uh used to send out monthly architecture digests where I just created more or less an automated newsletter that would send out all the uh a high level description of uh architectural changes that happened in the guide book you could also um develop more tools like something I call a software component map

where you have a a a detailed overview of the health and state of uh of your source code repositories or your software components and what is rather obvious I guess in nowadays with uh new llms coming up every day and they're getting better and better it would be nice to maybe integrate the content of the guide book in a chatbot that is maybe available via slack or

your common uh chat tool that you use I tried it it works um but um it's still not not too clear if you can really trust them because they tend to um maybe give you incorrect information but this is also an idea that we could build on top of the guide book as well so to wrap this up a professor of mine one said a bettered worn

out book is a good book because its state indicates it is used a lot digital assets don't wear out over time but the idea still applies documentation that is not used is useless and a waste of everybody's time because it doesn't contribute to the shared understanding we we as Architects must create useful documentation the guidebook approach significantly changed my attitude towards documentation I now see it as

a communication tool and a product where I can Channel my creative energy in both the tool and its content help my colleagues team members and the companies I work with I hope this talk inspired you to think differently as well my name is Simon I'm a software architect Tech and development consultant and then I invite you to follow me on LinkedIn Twitter or Facebook and I'm happy

if you give me your feedback and get in touch also if you want to get notified as I said before uh you can uh take a look at lcom diagrams or L incom documentation to get more information on uh on this content thanks a lot thank you Simon okay folks if you do have questions for uh be sure to use the Q&A Tab and relay them to

me and I'll I'll drop them across to him in fact uh we already have one coming in straight away from Ivan uh they ask if you are storing documentation in a single repository how can you control that a developer updates it after applying his changes to another repository wouldn't it be better to store documentation separated to projects repositories and having a commonplace uh just containing all the

links to those different locations yes that to that totally makes sense um the the guide book though focuses on the architecture not on the documentation of individual software components um and this this is what I what I tried to make sure so um the the architecture is something that concerns everybody all software components and it bans across everything so whenever whenever you want to do something on

the general architecture like I don't know rename an attribute in a data object or something like that this is something that you need to communicate to everybody if it is part of the communication between multiple components so you need to do it on an AR architectural level if you just change some internal stuff and you just uh um yeah that only affects one component then yes for

sure do it locally do it where the change happens but there is also change that happens on a global level and that's what the guide book is there for yeah in those kind of situations like you know I guess the the issue with documentation is always getting that balance between uh being farough and keeping it simple to a point where it's more easy to maintain I guess

like like where do you lean on that do you prefer the the foress that everything is covered or do you think it's more important to just kind of have that uh streamlined message across the board um yeah so I I think you don't need to cover everything like if if nobody looks for it um then it's not worth um uh writing something for it this is also

I I I there is a sweet spot obviously there is some important things that need to be written down even if nobody looks at it um or looks for it regularly um like like patterns right there is maybe details in it that you don't really look for it but it's so important that you write it down um I don't know that you always add a 0 z

uh in Jason when you have a when you have a float value or something like this nobody would ever actively look for it but if there is unclarity about it and we have discussed this once then you have it in the guide book and this there there is maybe more important to also have something in there that that is not looked for but in the flow documents

where you describe the general flow of of I don't know um how how is the authentication working this is a question that you have I don't know every two weeks or something like this if if you work in this area then it's totally worth it of of of of writing comprehensive documentation about it about stuff that never changes and is there for a long time and nobody

cares about it why why would you write documentation for it so um I guess like that's always a challenge as well right kind of proving to people that it's worth caring because longterm it's saving time I feel like usually in these environments one of the biggest challenges to overcome is convincing people that documentation isn't just a box ticker right it's not just a we done this we

move on you know how do you approach that situation because I'm sure you've had plenty of experiences where people are that stubborn about documentation uh I mean when you work with the guide book in the way I proposed it and you have this architecture forum and I'm focusing now on the architecture level right you have you have a group of people that own a product that they

care about or should care about and then they will also make sure that that you have the content there and that that that it lives right so there is really not not like there is not a lot of argumentation about it if if you like or or don't like to write this documentation it's like I I compare it to when you write software you usually should not

argue if you also write tests for it right so if you if you make a decision write it down right so um unless it's not written down it's not a decision so that this is just the natural process for this group right I'm not saying this is this is true necessarily for every line of code that you write so this is another level of documentation and there

is it's so important to have this architectural process like I said in the intro um you have to have this common alignment and it works naturally if you're a small group right yeah but if if you grow then uh then then then you would be happy to have something like this that gives you a very easy approach documenting decisions and making these decisions decisions I I guess

it's also a case you kind of have to hammer it in from the get-go because you know I feel like especially in those smaller environments where someone might have quite a lot of power over the thing you're developing um i' I've seen this before and I'm sure you've heard stories about this where people I mean everything gets to a point where it's like spaghetti coated and it's

almost intentional because they know that their job never becomes redundant so you know yeah I'm sure you've had some of these type of stories as well I remember there's a big one like an 880,000 employee company and there was a guy on the central systems he intentionally made it more complicated than needed be so that they could never fire him um you know is that ever like

something you've experienced and how did you overcome that concern was it just to tackle it before it got big um I'm I'm a consultant I work with with with many companies uh and yes there there are there are these cases is almost identical to what you just explained um but um that there is this point where you cannot move forward without doing software architecture usually um these

companies that have this spaghetti code or this spaghetti coders in there they don't care too much about architecture because if they would have done it then they would not have accepted this state and if you come to uh if if you just start at some point you need to start right and the the the thing I approach this usually is not not like you cannot for for

people to do something you need to bring them in and and kind of have Collective ownership of the problem and find find Solutions and usually exactly these spaghetti cerss are the ones that are the hardest um to kind of convince that you need to do it differently but they usually have a hard time of if if if you found a solution to a problem to to a

change to maybe a big change then and and they don't like it then ask just ask ask them the simple question what is the alternative to this and they usually don't have an answer and if they have an answer then it's something you need to consider so be really honest be not not not confronting them bring them in uh and and and and and see them see

see see their stuff yeah I like that it's it's in a way it's like if they aren't genuine you're kind of inviting shame that and that's for good reason right but what you're doing first of all is you're not approaching it that I want to shame this person you're like okay no prove to me what the BET method is and we'll go from there yeah I mean

usually it's it's the way the company is successful right this is why they can still think about architecture right if they were not successful they would just uh yeah die more or less right um but they are successful so they think about architecture and this is also where I usually come to companies they say we have a problem we need to move forward we are successful but

the state is currently not uh not acceptable and this this is the point where where you start um thinking about these things um yeah and and sorry that that was the point I wanted to make it just again um the people that are so important that you cannot fire them they have a lot of knowledge and you cannot get rid of them for a reason and they

are also the reason why the company is at the current state unsuccessful so you need to bring them in they are important they just need to work in a different way they are used to and this is a hard yeah I think it's that classic kind of feeling like you know you need to show the benefits of change because you know how it is especially in the

tech field like free years in people are stubborn some of their techniques are outdated but they love doing it um I've been there as a junior and I've been like look at all these new shiny things and there's a guy with 30 years experience going oh that's not how I done it back in my day and you have to somehow show the efficiency and explain to them

you know a long time ago we chucked our crap into the streets and we thought that was efficient right but but the guide B also helps you with that sorry we need to move on right um but the guide book also helps you with that of of of not jumping on on every hype right away right you you can't you can even as a junior developer you're

invited to make a proposal to change something right and then the architecture Forum will take care of it and they if if you open an ADR they will give you feedback because they will either say yes that's a good idea we need to make a project out of it or we do it right away or we don't do it for that reason or There is five other

adrs that cover the same thing and we always declined it because of this and then you can also tackle this and also bring them in and make them understand and learn I think the key owner is informed decisions in that regard um I think that brings us about to time here though it's been an absolute pleasure to talk to you Simon uh folks please do reach out

to him if you want to uh touch base on any other things he seems like he's more than willing to engage um but Simon absolute pleasure buddy I'm sure we're have you on future ones of this and thank you for joining us thank you bye okay folks so I think it's a 15-minute break time I mean I don't know I see a small Gap in that timeline

you know what that means get up stretch those legs go make yourself some more coffee for some of us it still feels way too early full disclosure usually I'm not awake for about another 30 minutes so I've definitely got to go pour out the coffee and I see you all again about 10 minutes 15 minutes when we'll be getting into our next talk in fact when you

come back we're going be talking with Peto about assessing projects so I'll see you then