Dino Esposito: Building a Technical Credibility to Fight Technical Debt

This keynote presentation by Dino Esposito explores the concept of technical credit, a term he introduces in contrast to the more conventional notion of technical debt prevalent in software development. He emphasizes that technical debt arises from shortcutting best practices during development, often due to time pressures or business priorities, leading to challenges during future updates or maintenance. Esposito outlines the different types of technical debt—intentional, unintentional, avoidable, and unavoidable—and stresses the importance of maintaining a balance between delivering features quickly and ensuring code quality. He argues for a proactive approach to managing technical debt, including measuring it, maintaining proper documentation, and engaging management in discussions about the long-term benefits of addressing such debt. Ultimately, he advocates for fostering technical credit within teams, allowing for trusted relationships where technical debt is acknowledged as part of the development process.

[Music] final Talk of the online portion of this event in fact uh we have to kick off or rather end in a beautiful way uh we have got a keynote speaker coming up now this particular person uh they are an accomplished offer they're a software expert they also happen to be the CTO over notable company crynet and they are here to talk to us about fighting Tech

debt so it's my pleasure to introduce our keynote speaker to close out day number two the one only Dino espacito everybody um this is a a talk that is uh let me go up with slides that introduces uh you to a relatively new term or at least a term uh Tech term that personally I've never heard earlier than I thought I created it I coined it for

the first time the term is technical credit and uh the title building a technical credit ility tends to oppose to the well-known issue around all technical technological projects that of technical depth my role in uh in business after a couple of Decades of being a consultant being a trainer speaker and making money and living out of that after the pandemic I had to I had to start

doing what I've never done before so working day by day regularly on uh a few real world project so now I'm a full-time employee I work for a company in a special industry the sport tech industry and all that I we do all that I'm responsible for is leading the IT team that ensures the tennis tournaments and puddle professional circuits could run so if you can watch

a tennis game a top level top players I mean if you uh could bet on tennis is because of the operations that my team and our platforms run so it's uh something that uh it's a business kind of business 24x7 365 24x7 business that still runs in the two months of the off season at the end of the year that poses seriously the issue of technical depth

debt and let me start with a quote paying homage to Oscar wild a man who pays his bills on time is soon forgotten and nobody yeah sorry I just wanted to quickly interrupt I think you've got the wrong screen showing we can see the presentation uh slides ah there we go it is moving now yeah so I think it was maybe on the wrong screen oh yes

so when I apologies I I didn't want to interrupt you in your flow no no problem so I think that it was an issue with PowerPoint and the uh right screen um uh I don't know what to okay we can probably go this way because if I if I zoom you lost the screen yeah uh so one thing I can do is if I uh share the

screen okay let me stop sharing for a second yep okay the entire screen probably now should work let me put down this and hopefully now it works can you okay it does I'll let you go back to the wonderful talks of Oscar okay so sorry about the technical issue but you know there was a sort of technical depb because I had probably not enough time or not

enough care to uh make a tripal check so that it could work so let's back to Mr honorable Oscar wild and his quote a man who pays his bills on time is sued forgotten and in the industry of software probably nobody wants to be forgotten so that's why we created unavoidably I would say technical depth what is technical depth let's agree on definition the definition for the

purpose of this stalk is that it represents the cons quences of taking shortcuts making compromises doing the undoable in the development process mostly related to software why do we do the thing or the the sequence of things that we know that are not probably the best approach to solve issues so why we take the shortcut too often mostly because it's a matter of priority is because uh

choosing quick expedient Solutions is uh it takes us faster to the point to the place where we want to be in terms of alignment with with the business but cutting short Corners sometimes uh is also a matter of yeah essentially it's a matter of business yeah let's cut the long story short so times and priorities it's a matter of business we want to go as fast as

possible down to Market we cut corners and in the long run this becomes the root cause of work delayed or not probably hitting the market go to the depb it's also a matter of costs so because technical debth in this talk around software are we just talking about poly written code frankly I believe that there is just a little bit more to it than merely poorly written

code because at the very end of the day if you have a poorly written code that works that it's not per se an issue the challenge the problems show up at a later time when and if if this poorly written code that works requires updates so the point is only when and if you have to put your hands on the poorly works sounds like a a little

detail but it's all based on this aspect so what makes a poly written code primarily coding practices an optimal coding like uh introduction of code smells limited abstraction poor naming convention lack of error rangling the use of hardcoded values lack of test or limited relevance of Applied unit tests these are just examples of coding practices that in the long run create an issue bringing down the level

of quality of code but there is more design choices when you end up with a high coping uh when large parts of your code or critical parts of your code regardless of the size contain some obscure code behavior that is not obvious for most of the team to figure out so when you have dependency for certain critical operations on just one or two people on the team

that may leave at some point when the understanding of the business context and the business domain for which your code is required is not completely cohesive in the team I again want to mention bring my own experience we work in sport and most of the platforms that we have work with tennis or or or pad which is a similar Sports logic if you don't know the mechanics

of tennis not not just as a game but tennis as a as a an organization as an infrastructure if you don't know how tennis tournaments work which are the rules which are the processes and they are particular as in nearly any other industry that's an issue if if you cannot figure out why a certain rule has to be applied why that specific rule is critical you end

up writing code or you may end up writing code that is suboptimal as far as design choices are concerned but also the breakdown of tasks that form the actual implemented processes could be problematic if you have an overly broad or overly microscopic tasks unclear dependency if you miss considering edge cases that's is really missing Hedge cases is a sore point when your estimates due to lack of

knowledge are unrealistic all these are problems that could uh create contribute to poorly written code and this poorly written code all together form the Deb now what is this word Deb and what is the other opposite word credit uh both terms both words debit and credits have Latin Origins even though their meaning the original meaning have evolved over the centuries Deb in particular represents the um obligation

some cases just a promise to repay something of value uh whereas uh the credit the opposite indicates the trust and uh subsequently the inclination to concede new debts that has to be repaid point credit is the point in software technical credit that I want to uh explain better in the in in the rest of the talk but Deb if let's focus on Deb to understand why credit

also in software is crucial in the history Romans have been the first to introduce Deb's instruments to facilitate trades and economic transactions but later on in the middle age pant often hold labor and goods to land owners in return for protection or just the right to use the hand to produce the goods that had to be returned to the owners but interestingly just in the middle age

around the fudal systems we saw especially in in Tusan around the of Florence in Italy the emergence of first formal banking institutions and we have seen the use of Deb as the means to finance Wars and Royal Endeavors later on renessence the enlightenment periods have seen the rise of banking systems very close to the modern ones then it came the Industrial Revolution and the global trade and

the development of complex financial instruments and also along with that the establishment of Credit Systems so debt is allowed but is balanced by Credit Systems and finally in the in in the 20th century debt has become a ubiquitous aspects of world economies and compassing any sort of Deb from personal to corporate to Sovereign okay so much for the debit but what what about the credit the credit

refers to the ability to access services with the promise of paying them in future and it's essentially based on trust technical depth can help a team to deliver features more quickly and in a business effective way technical debit plays a role in development of software technical credit of the team is the trust that any technical debt accumulated will be repaid over a decent amount of time which

means keeping the overall software result highly maintainable uh I've tried to go with so far with a comparison between financial depbt and Technical depbt but there is an important distinction to be made uh the origins unlike financial debt technical depth is not intentionally or almost never sold has a financial debt you ask for money you don't ask for bugs you don't ask for for lack of documentation

you don't ask for poorly written code but in a way organically technical Dept Surge and accumulate so it's something that we have to be ready to face which is precisely the takeaway number one of this presentation in life thatb happens and Technical depbt in software is no exception no matter what so the ability to repay technical debt creates trust between parties in much the same way um

history of repaid Deb makes banking systems to trust you more than anybody body else so as a definition technical credit is the so far as long as I know never heard term that wants to indicate the organization's trust in the team's ability to introduce technical depth to deliver quickly but is still able to act timely to keep the code back in shape now technical depth surges in

a organically but uh how is born overall there are probably four different objectives that qualify the act of birth of technical depth intentional unintentional avoidable unavoidable intentional technical depth is a conscious decision that the team makes to opt for a quick and maybe rudimentary solution just to fulfill a deadline or a given requirement to you know balance uh technical uh requirements with business requirements so it's intentional

you know what you're doing unintentional is when is when coding errors or shortcuts introduced because of lack of knowledge lack of skills in a way that is unknowing avoidable technical issues is when established best practices standards or guidelines are missed or disregarded without the level of Consciousness that would make otherwise intentional and then there is also an segment of technical depth that is instead um unavoidable uh

when is really really unavoidable because there are external factors uh such has requirements that shift uh dependencies between features that are not completely explained or not deeply explained not completely understood decisions that have to be postponed to put the final words on what has to be done or maybe technologies that that change underneath in these days of generative AI is is fairly common for a project that

uses llms Technologies relying on libraries like Lang chain or maybe if you are on the asure side of the coin um semantic kernel from from time to time from week to week you you find a completely different API or a significantly different API the technology is a moving Target in some sections some some time frames and if you are heavily relying on any of those your technical

depth is in unavoidable the part of the technical depth of these four segments of technical depth is the worst and one that should ideally be U Focus you should be focusing more to avoid is just the avoidable part so when uh established best practices are skipped for no valid reason when guidelines are not followed when documentation is not written for no apparently valid reason okay so if

technical dep does exist it just happens in life as in software the problem becomes how to deal with it when it comes to this uh one point is uh key to have printed in in mind eradicating technical a is an unrealistic aspiration so the perfect world in which code is clean code is following guidelines literally in which code is readable documentation is full and cohesive that that's

the perfect world it's a completely unrealistic aspiration it's much more realistic instead coming up with a set of practices that makes allog together dealing with the technical depth doable and when it comes to this um a pragmatic much better than dogmatic view of the problem would considerably help to achieve concrete uh results so the first uh point to uh to to focus on is when to act

technical depth surges organically you like like a root grass in in in NS you you you you you let the grass grow at some point you have to intervene and cut the grass so when to act to decide the a possible Right Time or good enough time you need to have a method to measure the current level of depth you need to Monitor and and establish a

threshold and when around threshold whatever the threshold is whatever the measure is you intervene now concretely you can use tools that automatically measure calculate kpis that represent all together the level of depth sonar cube a static code analysis tool is a possible option otherwise you can go with manual code reviews that are scheduled regularly or in certain amount of time people meet look at each other's code

come up with reports Global general meeting a number and a decision is taken we act we can still postpone the action okay taking the decision to act how to do it how to concretely deal with technical dep how to try to reduce the amount of bad software in your code base overall there are a couple of possible ways in which you can do and none of them

is perfect one is set up a separate project just with the purpose of dealing with technical depth and removing it the other approach is removing technical depth in improve the quality of the code um at the same time in which you deliver new features and release new versions for making a decision between these two options is necessary to have uh the awareness within the company uh that

technical Deb is an issue that is to be addressed at some point to convince management to support technical Dept you have to find a way to justify the cost of fixing the debt of repaying debt uh one mostly uh commonly recommended way of doing that is populating a backlog of items related to technical debth each issue that form the de is documented each associated with an estimation

of the cost to fix it and another estimation of the benefit that could return to the company to the overall team by fixing that problem so it's again a matter of selling management the time to fix things depending on the culture of the company depending on the SC depending on the number of factors uh sending it as a separate project or as a delay the new release

a little bit every time but in the end over a given amount of time you end up with a cleaner code base is another approach and there is no option that is patently better than the other but there is no probably no third way out to deal with technical depth no best practices and let alone that has to be clear in everybody's mind silver bullets so separate

project so a project exclusively dedicated to the reduction of the technical depth or ship and remove an approach in which you keep on shipping you releases while removing as much as you can uh bad things in the code so in in a way is leaving the code base cleaner that you found it much the same way you work with restrooms if you're an educated person when you

go uh to you that invited to leave the restroom better than or cleaner than you have found it the same principle applied to code base ship and remove is also the toilet principle if you like it single inventory of Deb items now another concrete point here is okay assumed that a backlog of depth items should be kept the next point is this backlog should be the same

as technical items or should it be a separate Deb specific backlog um some people object that if you keep everything in the single code base it's preferable to keeping technical depb items in a distinct backlog because if it's distinct um it can be the cause that Highs real issues from the view of product owners and managers so it should be the list of item technical items technical

debit items should be in a place that is visible and frequently viewed by product owners and managers so beyond the development team uh because without the awareness at the company level of the issues very rarely the technical depth is seriously addressed and uh if we go if we tend to go for a ship and remove approach here a few techniques borrowed from the agile space are very

very helpful uh it's a matter of finding strategies to seamlessly integrate debth reduction tasks with routinary uh development uh if you commonly used strategies to allocate time and resources exist and we will take a look at them um in a moment but if uh management doesn't understand the relevance of technical depth no way uh there is no no no real way for uh for people to for

for teams to significantly reduce technical depth and to sell this to uh you have to try to sell it uh as a a good point for the company without telling it so reducing the depth is something we need to do because we have done something wrong earlier this is an argument that very rarely managers accept so you have to tell only half the story uh we have

to fix this because that would give us a much better product new releases in a shorter amount of time you have to see the the the good part of the of the problem uh canonical example of how to sell management uh uh the review and the fix of technical depth in regular cycle is you know showing that if you have a significant number of bugs in production

and uh you figure out that those bugs that are you know affecting the stability of the application but also are ruining the reputation of the company then you can sell this as a project that involves codebase analysis maybe the implementation of more automated tests to essentially give the good point that in the next releases we will have in a way mathematically less bugs this is a way

of presenting an effort that is essentially a cost in a way that has a great appeal to managers because you will demonstrate that by spending this time and having this costs on budget now for no new visible feature in the future this will take us to deliver more releases better than we're doing now with less bugs putting it the other way around so let's uh spend a

little more time on each item of the backlog and reduce the depth while making process put down this way with no visible uh gain it's always a noo for manager because the manager perceives that has an effort and money that goes away that Fades away with no concrete uh return so it's all about the best strategy overall is trying to bundle depth removal items within project items

trying to hide them or just selling that has uh mechanism to reduce uh bugs the alternative to selling something to your managers is that you as a team leader have have a strong personality strong Charisma that you just uh don't even mention technical depth you resolve technical depth actions within your team the to-do list the backlog doesn't receive any special treatment the list of items are there

business items are there you do all of them in the reasonable time it takes maybe longer than the bare minimum and in the middle you fit technical technical depth item removal in any case the golden rule for every developer in the world is leave the code base cleaner it okay now agile techniques actions on technical depth with routine development there are essentially three them uh time boxing

spikes and slack time time boxing is about reserving a fixed amount of time usually 20% in every development cycle just to tackle technical depb So 20% of the time in each cycle it doesn't matter how long is the cycle 20% seems to be a decent amount of regardless unless you have a very quick cycles of one or two days to fix things that you touch so anything

you touch in the implementation of new features should be reviewed for 20% of the time in light of fixing what is patently uh an instance of technical now because the tasks you you're still working on are part of the Sprint in this way you can still guarantee dedicated focus on producing new stuff new features but also you have a dedicated focus on reducing depth in a structured

manner so you you you can kind of repay some 20% of the technical debt every cycle another approach is spikes uh what is a spike is a a short amount of time that can be measured in days that are explicitly dedicated to the investigation of a feature one of this uh sample spikes investigate technical Deb as a whole within the project or just specific items we have

this query that is particularly slow or is giving us troubles can we spend a few days one two days focusing just on that to see what is the problem why it is so slow if there is anything else we can do and then if there is something we can do it Zack time is a what charismatic Tech leaders will probably do regardless so adding some extra time

deliberately to the timeline just to handle un planned work and if uh no unplanned work would AR the slack time is used to address technical depth problem so just if it takes n n plus Delta is the time it takes and the extra Delta is for whatever can happen or just reserved for solving addressing investigating this is what we can do if uh we deal with technical

depth but there are also triggers in the software development process that uh generate the depth that takes to the organic growth of Dept in first place we have time constraints pressure to meet a dead lines tight deadlines are the most reasons for triggering technical Dept and because they cause essentially quick and dirty solutions to deliver over time quick and dirty Solutions be honest often remain quick and

dirty Solutions because they work so in place in first place they are written quick and dirty because we have no time to do it better but then because they work we don't touch them anymore so uh ideally instead a deliberate let's call it discount on quality should be instead not just a a discount you put in your pockets but should be the commitment to fix it soon

takeway number two you will never have the time to fix it later so no matter how much you commit the promises you make about the fact that you will be able to to fix and clean things at a later time you will either you do it now or never this is the hard lesson that honestly in 25 years and more of career and even more in the

in the four what projects I have learned you will the real investment that you can do as a company but also individually as a developer the best you can do is find your way your personal way to produce better code right away so when you work when you code in default mode code you should be able to produce code that is not marked not qualified not labeled

has an instance of technical depth this is the best investment that you can make on your in on your developers Deb amplifiers lack of documentation is a an aspect of debth that amplifies whatever piece of depth already exists so let's assume that there is a piece of code that is written as a shortcut in a suboptimal way well great if that behavior is not documented maybe just

documented has something to fix at some point with a certain level of urgency that is something that can only amplify further depth now documentation writing documentation whether it's code it's it's commands within the code it's serious commands within the code or is separate documents developers tend to be focused all the time on development tasks features business features and anything related to documentation is perceived has a boring

administrative task so it tends to take no time or just the time left after everything else has been done the point of documentation is a sore point and common sore point in all organizations and honestly I'm the first Who hates writing documentation and I'm the first I'm raise my hand who tries to even in the team to reserve documentation to the people in the team that are

the one that could deliver new features more slower so if you can if I trust you as a developer if I have a great I assign you recognizing you Great Value I will keep keep you far away from writing documentation I will keep you focused on business TXS I'm the first as a leader that will be do that but at the same time I recognize that lack

of documentation is a great amplifier and the way out to this is having people who can write uh code that doesn't need great documentation in default mode so greater better developer working well enough in default mode however much more than documentation about the work done I believe that uh business is business this Mantra is uh the painful point the most painful Point scope creep that's the technical

name so when the scope of a project or even in a smaller context the scope of a particular feature grows in in an uncontrolled way it comes up with a with uh feature well defined features but then while implementing that while demonstrating that to customers more and more and more and more requirements can we do this can we do that can we add this can we add

that show up and in this context the role of product owners the role of marketing and sales people is crucial because they usually make money out of the work they get and the more work they can get regardless of the doability and impact and the effects perverse of scope creep regardless of that they just try to bring more and more and more inside of the company business

is business but scope creep as a matter of fact is a reality and is a relevant depth prototyping one of the best and most like the uh compliments I have received over the years in my career is that there was a a guy in a company I worked for at least decade ago that said well the the the part that I like most about Dino is that

when it delivers us a prototype a PC a proof of concept that's pretty much good to be production code it's pretty much production ready uh this is Maybe this was maybe true for the few pieces of code I contributed to that company in a specific time of my career but it's not true in general so PC rapid prototyped application is uh usually not enough to be production

ready but because business is business it is perceived as good enough to go to the market to be the first to Mark the territory there is nothing bad in wanting to be quick and first to go out to Market again as long as there Remains the Consciousness the awareness that it was just only a rapidly prototyped app that has to be dismounted scrapped in some cases and

written from scratch if we apply after the rapid prototyping step the Mantra that doesn't matter the code is bad as long as it works it's okay this unveils the again offers another view of the perverse mechanics depth lack of skills uh one of the stories that I often tell about how the arrogance to believe you smart enough as a developer that can take you away from understanding

the real mechanics of the specific business domain was that essentially I inherited a system designed by an architect who never spend enough time to understanding some aspects of 10 his processes so we inherited a system in which things were called with a wrong name and the behavior was actually correct but to but the description the would the message you got reading the code as a description of

a process was completely significantly away from the real business so lack of skills expertise of domain and also expertise of software vment if you're too young of a developer are Adept amplifier but let me also show about the the point of skills also the the other side so when sufficient expertise of software and sufficient knowledge of the domain could make Miracles and systems could be developed in

special situations in a very short amount of time basically the company I'm currently working for um received was about to sign a contract for rewriting a significant part significant portion of the uh tennis operations uh system for a tennis organization but this contract was about to be signed essentially at the time in which the world was realizing about the pandemics so it was March 2020 so so

the world of tenis stopped for about 6 months and uh the project was freezed six months later it was a late summer of 2020 the project was resumed the contract was signed the company got the contract signed and had to start working but the final deadline remained the same so from the originally planned nine months of development to go live the 1st of January 2021 became only

three months October November December to still deliver first of January 2021 in production but the team was very small made by super software experts with an incredible knowledge of the domain so basically we developed in three months what would have been fitting in three times the amount of time just because we knew exactly what to do so it was a mere matter of writing code as fast

as possible and doing only the integration tests that were required for the various parts to connect together skills play a role as um a depth amplifier if too low but also as a the enabler of software Miracles when they are big enough note uh speaking of uh technical amplifiers I have found that one more point is uh worth mentioning and it is when you have in the

project strong dependency on thirdparty external libraries Frameworks or components uh this days uh in is fairly uh that you find in organizations sometimes applications line of business applications that are still done with uh asp.net framework non core or very old versions of Java or very old windows forms uh Frameworks that is a serious issue and it's a technical depth point that has to be overcome in any

way because otherwise any effort you do required or not any new fish you try to implement can only exponentially increase amplify the effect of technical debt from debt now to credit so in general when debt is used in for business reasons it contributes growth so if you if if a a country has build a bridge has to build an infrastructure it needs money so in way the

country creates a Dept or country or a company creates a debt and this depbt finances the building of something new and the the the revenues out of this new built thing repay the debt so the best point for an organization and also for a team is a proven record of recovered past technical deps in past projects because this depend becomes an allowance to emit other technical Dept

in the future have you ever heard about the broken windows Theory uh it refers to studies made by a couple of I think psychologists James Wilson and George Kling uh in around the her the early Hades essentially uh the theory of broken windows is uh about the fact that visible signs of disorder in a public environment like you know broken windows in buildings about graffiti litter everywhere

Grassroots lead to an increase and crime and antisocial Behavior so the surround environment is the cause of further degrade degradation of the a degraded environment is the cause the first cause of further degradation so according to the work the research of Wilson and Kelling a broken window left unrepaired tells potential offenders that no one cares about the building about the window about maintaining order in general so

that in a way some criminal behavior in a way is tolerated now the broken windows Theory to some extent applies also to software writing code without due diligence sends a message to the next developer that comes after you it says code quality is not a top priority in the company and the Cure of course is a that code smells and you can find plenty sources on um

on the internet through Google through chat GPT you can find tons of examples of what is called a code smell code smells are the same as broken windows in software and the technique to fix to repair broken windows the technique to repair code smells is refactoring this picture which is courtesy of the neurosense laboratory of the University Chicago tries to give uh you know an idea of

a a visual idea of the broken windows Theory you see uh a degrade lot of degradation you know on one picture you see the same scener kept in order and uh that is the essence of the message that you leave to who comes now fixing technical depth and then gaining technical credit passes through a few firm points and you might be surprised maybe to to see to

find out that I'm not a great fan of acronyms like dry yagy kiss and solid don't repeat yourself you ain't going to need it keep it simple or maybe solid I'm of the four here but the fundamental point is that just going with solid just going with dry with any of those doesn't help Beyond a certain point so my favorite statement is that those design principles offer

for sure valuable insights but they should be treated like agiene the same way you wash your hands eating is the same as using solid but not because you wash your hands regularly you will never face any disease so it's not the guarantee that you will never anything will never go bad but it helps so principles like dry yag ni s than anything else offer insights but it's

really naive to think that missing on one of those principles will syns or save a software project to S exemplify I say not because you you use a factory method instead of a Constructor your project will fail or succeed agile it just doesn't mean faster uh historically agile was a arranged as a a vocabulary of definitions with a primary focus on delivering the right features rather than

just working at a faster Pace talk to your customers to understand what they really want to give your customers a better service so understand which are the right features and deliver them and deliver them PE meal one small step at a time because delivering at small steps allows to change direction if you got wrong something some some some requirements after each step that was the original meaning

the intended meaning of agile not because you can deliver you deliver pism means that you give everything good great in in a shorter amount of time so make sure that the definition of agile is clear because otherwise the same point of agile becomes an amplifier of technical depth and the fighter of credit and finally the other point is testability is much more important than tests you can

have 100% coverage of tests but there is one big huge sword of demal hanging over the head of unit tests is all of them relevant for the business so per say unit tests are guarantee of nothing but if your code lenss itself to be tested so if the code lens itself have to have unit tests easily written to test the behavior of the code so testability that

is a real great statement about the code and a team that can produce a testable code gains a lot credit and summary we are close to the presentation there is a the Zen of software architecture that I it's it's a vision it's a thought that I put together together unifying things and opinions and thoughts that I've captured from all over the world in 25 years of career

the seasoned expert often identifies just one solution where a junior architect may see multiple options to choose from it's more or less the same as great minds think alike keep this in mind and uh the Z of coding could be summarized as you will never have the time to do it nice and clean later the only chance you have to write the code as clean as possible

the only good time is now so the best investment in your career that could put you in condition of managing technical depth because you have technical credit and Technical cred ability is work to be able to write best code as possible clean code as possible clean and simple as possible right away and in doing so feel free to use any help you can from code assistance typically

resharper but also why not llm based co-pilots so end of the story what is uh the the bottom line raising the quality bar make yourself a better developer prioritize clean code as a a default behavior and uh be part and help to grow a team with a strong technical credit because that would make more palatable for a savy manager to consider incurring in new technical depth and

cleaner projects uh all that I have said in this one hour keynote presentation is chapter 11 of the clean architecture with.net book just out from Microsoft press check it out if you have a chance I think it's all for for me anybody there thank you uh yes so now we've got a little bit of time left over for questions so uh if you've got anything that you

want to have Doo answer now now is the time to go for it uh I think we have actually got a few already coming in so uh we'll start off with Jago here they ask based on your experience with one from task reduction methodologies uh which do you prefer time boxing Spike or slack time slack time all the way by definitely slack time Reon no no doubt

the the reason is it gives the most flexibility just add an extra amount of time because you never know I in everything I do in life and in software uh has a SL time so when I have to go to the airport I take I had never know what goes on what goes on and there's always a car accident you can find on the way so it's

lack time definitely because uh yeah it's an extra amount of time ction time that can be used for any any purpose so definitely that uh so another question coming in this one from vladislav they ask is agile uh is the agile way working one that will increase your Tech debt compared to the waterfall method I'm not sure that is uh it's correct to to to put in

this way if waterfall is or or agile is has an impact directly on on technical dab I think that you know waterfall comes from a scenario in which Things Are are very well understood before they are coded and agile is opposite to that in which you start doing things and it's not completely clear the final Direction taking so uh probably waterall per se is uh in a

waterfall scenario technical depth either is originated at the very beginning because there is there are flows in the vision of the project and flows are introduced at the coding level or it's good enough and mechanically you move from one step to the next agile is more prone probably to technical depbt because you you you are allowed by Design to change direction frequently and when you change direction

without a method without a strong commitment without technical credibility you risk yeah in in this case it's probably of the two agile is more error prone more technical Deb prone but it also offers if you raise the quality bar of individuals if you build a technical credibility it can be it can be clean and at the same time flexible so yeah uh so now one from JAG

they ask as you said the the lack of skills is one of the debt amplifiers uh what is your recommended way to address that well soft skills uh is one thing business skills is uh is completely another thing um personally in in the experience that I have in my everyday work the aspect that you know relatively young developers I found lacking so what I would qualify as

lack of skills is lack of abstraction so it seems that is some cases even people with know coming with with a a very good educational background without on field expertise and years of on field expertise I I found problematic for them to to find the right abstraction to Envision that there is a common pattern generalized and and and and generating an output in terms of how you

structure The View how you structure the the the process how you ratify the orchestration of of a large task so lack of abstraction is the the most critical point that I I see in uh in in other developer and the one that I encourage at the same time uh lack of P having the the perception of how things work in abstract is something that is very problematic

to to teach uh is uh it comes for sure with expertise it comes the more you study things like you know yeah principles dry and so forth if you look at aspects of programming languages like interface encapsulation much more than plain object orientation if you look at the the the features of programming language well beyond the fact that is object oriented or function or whatever is the

programming model uh it helps you know studying software stuff software things but it's something that is in your in the mathematics of your brains primarily um so yeah that is um that is the fundamental Point business skills you have to be in the business period yeah okay that's a good answer um so Jos came with another one it's funny actually because I'd written down some similar because

I I was intrigued by this is um it's back when we talking about you know the idea of taking these shortcuts it builds up the debt you have to go back you have to address this Tech de at some point do you prefer prer to utilize the original team for that or do you think it's worth having a dedicated team a specialist team that focuses on that

personally it's one team period end of the story because I my point my vision and the the the direction that I'm giving to um to my teams is you should Endeavor to become a better team made of better individuals so what I say to people okay you are working here for the company now you are here maybe in a couple of years you will be elsewhere but

if you have passed from a company where I was working I want to leave you to give you a good memory of me and I want that you go out of here if ever uh has a better developer than uh than than when you came in so I I want to invest as much as possible on improving raising the quality bar of individuals developers and then the

code so I want to have better code through better people I guess it also adds a layer of ownership and responsibility right where if you have a separate team there's there's less onus on you to get it right you can just go oh oh that's not my problem that's uh that's Tom down the road's problem yeah sort of that yeah exactly because yeah but also I imagine

that possible you know fights could be in the underpinings of the relationship between team it also depends on the organization how large it is I always work I'm working now in a relatively small organization we are 20 people at all even though distributed all over the world but so we are a small kind of team I never worked and hopefully I will never work for a large

very large Enterprise organization so maybe that could be different if you if you are there but the only situation that I've lived for a couple of years in a larger than usual organization that was a fierce competition between the team of testers and the team of developers and everyone was fighting at the other that was not really giving a great service to the company as a whole

yeah I I've been there I've experienced that like it's the classic um enemies of each other right devs and ters they're looking to blame each [Laughter] other but you know what din I think we've kept you long enough my friend this has been absolutely wonderful to listen to um folks if you do have any more questions be sure to reach out to him great to see the

engagement from the chat um but once again a pleasure my okay all right we'll see you soon bye byebye okay folks that actually brings us to a wrap on the unline portion of the show that's right Dev days devops and cyberwise Europe 2024 is only two days in of its 4 day cycle but the next few days you're going to be treated to an inperson experience so

if you a full ticket holder hopefully uh we're going to see you in vilnus uh parting up afterwards but in the day making sure that you are all serious and definitely engaging with the subjects um but before I do close out the online portion it's really important to remind you guys there's still so much networking to do for those in person great obvious one there grab a

beard talk with someone get deep into it but for those online remember all these people you've seen you've listen to they're very receptive they love they adore actually having someone in their DMS talking to them about these things definitely reach out to them and also uh be sure to check out our sponsors without whom this could not have been done really big shout out to course our

Platinum sponsor which was progress software a bunch of gold sponsors actually we've got swedbank Cloud amqp uh Dev experts so cyber and revolute as well as our bronze sponsor spitler Europe and then finally our inine sponsors battery Andia if you are there in person I'm sure you'll see the banners all around be sure to check them out I'm sure they'll have a few samples on site as

well um but big shout out to all of our guests big shout out to everyone working behind the scenes on the remote broadcast and also to all my fellow hosts as well as speakers who have been busy throughout the last two days not just on this channel but also on six other channels which means you've already on two days alone got about 120 hours I think of

content roughly to cycle through so be sure to check that out after the event when they'll all be available online but that's going to be it for me thank you to everyone who has tuned in thank you to everyone who has been engaging here uh if your journey does stop now farewell hopefully we will see you next year when this kicks off again in 2025 but to

those going to vus have a good time enjoy it you know it's business but also a little bit of fun I've been to plenty of these offline events and well don't get too crazy but also make sure you enjoy the experience and make some memories of the people and I'll see you all again very [Applause]