Managing technical debt

hello everyone and we're gonna have niches that that Dr. less actually stock interactive session about to managing technical that so the question is are welcome I believe is supposed to be interactive by the way this is the 1st time the 1st interactive session ever done at any Europe items so 8 by reward of formed this is my colleague mentioned this is the very 1st interactive session that is on your right and I feel a little bit like the guinea pig but that that was passed so we should have the discussion here that's what I understand so why was some slides and we'll see how well this works a few things about 4

but I am technical measures that supplies will small company located inclusion of Romania and we're doing mostly by phone development work for those of you wonder what the technical manager that as well we are the people who pretend we can still write code so that's mostly about the book itself is about managing technical that I mean when I started the thinking about the subject I realize that is a pretty much like politics or religion everyone has an opinion and so that includes myself so more opinions the better and says I mentioned that this religion we're going to start

with the very beautiful impressionist picture from our colleagues from classic paintings of named this something around developers of asking forgiveness for technical that at the beginning of the spring that pretty much describes it to be honest

OK but in summary what we're going to try to do what I'm trying to define the purpose of the presentations that set the stage where some short history of all the subject itself but we're going see where exactly the technical that offers at what at which levels what are the consequences of this talk about interest and also about the type of projects that are of where you actually care about that overlap I'm not saying that you should know but there are projects where you can more or you can last alright I 1st of all the synsets in this session we have 1 hour I would like to solve all the time for discussions per subject of about 1 or 2 minutes depending on the interest and by the way senior single the lineup what's so in parallel with this stuff is really many singers around here so OK so what is that that 1st of all it was 1st defined by Ward Cunningham and it was defined in the early nineties as a metaphor more-or-less in terms of describing the actual development work when we choose easy shortened solutions against longer term on the proper way to implement style it is a metaphor because they die so really is directly to of the finance industry to loans and we're going to go and see what exactly is the bank and the interest that I mentioned earlier on there are multiple ways people have multiple opinions about what technical that means and what it should mean what it is 1 of those people is well market I'm sure you guys over the ball Robert Martin technically he says that Mexico is not really that that that's just the man now I towards this purpose he says that when you should make a conscious decision about technical that's what should happen is that you should try and write even clear code that you will have even the interfaces and so what does this work in real life this will show you that the so the answer was that the people usually do it in a Russian don't think about stuff that's partially true I think because when you make a decision that you're going to have to conclude that and will have to live with it is because your you have your you have constraints and usually goes of time constraints and the time constraint that's required to write book plenary interfaces and so on it's sometimes works sometimes it doesn't know that so that we have not been followed and this is where I we have the discussion if we're talking more conscious and unconscious technical that the his opinion is that the question if the mass is technical debt it's by itself is the wrong question the idea is that you you would have technical that India so it's more about defining the conscious approach and the unconscious approach and he splits this into what what he calls of the technical that quadrant I put it here this is not my my so it's copyrighted there and we have the requisite technical that and proven technical that and on the horizontal line deliberate and another OK directly 1 for the deliberate once we don't have time for design of course what the what I would like to mention is that both of these guys for advocates for design patterns refactoring writing clean coal right so design is is there the prudent approach for this for the deliberate part is that we must shift and we have to deal with consequences not have how many of you here were in this situation OK what is meant as well well alright Ford formed those in conscious we have the 1st early part of the mass what is the layering people do not really know what they are doing ov I solved the completely from Specular what's that might cause technical that low in the the other part is actually very very interesting know we know all we should should have done of Robert Martin in the public he has he says something like this if you have a complex system that you haven't built before you will know how to build it was built and is not going to be the way to build so that is that the other party it's true that in the end you do your best no matter what is why the quadrants why did they approach it in this way and what can we learn from these three-state yeah like calling attention for that that's what would be the last 1 whether think they call the technical debt the it would be interesting correct but why not and by patterns that might it might look like the right time when you when you're doing the OK this is where I sometimes can technically borrows strategically because if you need to shift to there and you will you if you then shift to this example maybe it will not have funding to do anything you want become strategic borrower and then it's not mn departments actually if you it could be a good thing to do that but at the end of the day was the difference between technical that and that this you can try to avoid that included as well not always within the patterns of also that what it's easier to discuss with business people because if you go into a business owner of someone who is the development manager or who doesn't really have his fingers into the development world if you're going to him and say OK we have and that and here we have any other kind of terminology or whatever it doesn't mean anything to for them it is OK it works why why changes why faces that encode that on the other hand as you guys already sent directly related to the finest so when you have a technical that you have 2 parts you have the principal and you have the interests of this they do understand this we will understand because we make a conscious missions decision to take a little ride and we know we have to build the principle we have about the interest and although auditory approaches that I presented ways that people are consciously that basically looking towards advocating what what they stand for and that this is the same will be the same with us OK In my opinion that that is

the status if there is that they have worried it isn't and is no real phi losophy around it is not something that you might want you might not have I is still low we describe this as more as a shown the sketch problem before you acknowledge it you what we will have it you don't but it's a matter of acknowledging that that so what's your knowledge is there people actually exist so what's your knowledge of the door leaving in I know of questions or comments the you know that it because you so the question is if there is any code that does not have technical that it depends how you look at it it depends how you look at to be honest doesn't cause you problems later on we do make a conscious decision that you going have I will you be able to cross that bridge was you're there whole hallways your code Paul clean audio interfaces in the EU you cannot have something specific and that I would like to come back a little bit at what the purpose of the presentation i don't have all the answers I don't think I have all the questions that's why we're here I was going to have a discussion about the being the 1st session that the your and that's interactive we have lack for microphone also in so others and is that OK at what levels of technical that popular I already put that up there the 1st level that they see it at the code level and this is what the what you mention how does then decoded at Colombo manifests itself the yes I was right the missing the scares coding College development where you have to ship feature has still not possible and if you miss a lot of the best practices so spiking because right on the head of the think very good a framework that so that depend on the becomes never of the question is a little bit larger with the framework because every from framework was sold parts of your problems so when you choose a framework is also a type of technical that it would take you 80 per cent of the way it does depend on how much you have to spend for the rest of the 20 per cent so that's another approach but let's say that you have your code consists of something like 300 lines of code of flow undocumented functions so you have perform functions or methods that sort of like 300 minus lines of code what is the technical that you that you see there why why that technical that quite a bit of documentation is missing is coupling technical that graph it will save you time so that so that something else time here is that yeah they lead you more or less how to make you know this it you might drop it off some point of right the credibility of saying OK something else online and with you think of this is a great how would you test method so an application that has you know functions are matters of 300 lines of code block you don't want that right OK that's true OK so people could would blow right 300 lines of function functions not have that OK so we have the principal defined here from what technical that once as our colleague said you were going to have to go back and figure out everything that we have to change the code you have to figure out what we're looking at because we it's on document for this what we have the interest that also here mentioned in regards that when you have to all sorts to someone else they will not understand the goal but how about so ourselves in of 3 6 months time of every

time that you have to revisit that function that is not no longer technical that that is already every time that you have to on board someone into an undocumented code that's no longer the technical that that is interesting debate every time that you have to we had to change the functionality we can the best who but bit within the function this test will have to be updated that is principle at 1 point and the interest from that from the point of so this is 1 example of technical that can argue that cold that was the impact how would you how would you how would you see the impact of echo level is high is if hi I think it's the simplest thing change we don't know yet the the example if you have broken API and a lot of code depends on the atmosphere but that is 1 step further from the broken API was talking about good technical that at the architecture level if you have broken the eyes and you cannot maintain your code when you change that and that's a lot of attention decision and have that that at an architectural now at this point I think do subdivision application level what you mentioned infrastructure level I worked on a project and that's what at a specific moment I made a decision about the the the model as a policy in the room we already know it and then had to leave with a base there would OK that was the wrong decision that was the decision that I had to pay at the architectural level and we've made a lot of principle we breathe a lot of interest people working on that application still gradients with in us something that's about decision would I do it again probably not right now I'm working on an application with a similar problem when I have the feeling that it might go the same way I don't to fix it is still there some other related OK what's the impact at the at the architecture level compared to the cold level if you mess of the architecture what do you you can't scale maybe you can maybe you can't it depends what kind of data How can what you can ask horizontally General architecture is broken the can vertical I worked on the application were the only options what was the scale of politically because we did a lot of simulations like tens of thousands of simulations of the price of the simulations we have this we we had 1 big object that all the threads share the same big object and it was a mutually exclusive of don't ask why that was not possible to have distributed it was another this is OK but of going back a little bit at the infrastructure level how can you will have technical the station is 1 of the have in many was set up by the infrastructure God that's 1 thing what if your application depends on local storage that's on your actual of applications when I have to scalar scale of you might yes and have to share the same file system would have to have a distributed storage sort the thing with the database OK the next level is at the specification of is all this is what the I think what I think why is it important to or why do I think that's so what was it important to have the specification level of sort out the specs with what kind of technical and that's results from specifications that you prior to of and this is 1 of yeah really does prevented to finding the best solution because although medical impact on the architectural level on what do you decide that you do and how do you do it so once you have a closed set of specifications make sure you clarify that because if you don't know what you're doing it properly the results can be but OK we don't little bit about

interest but we because about the subject tho before so that all that was that we discussed we have to pay the interest we saw that at all levels of the of the amount of heat into that we have to train is relatively low as we go on to architecture specifications we're gonna pay more and more interest everybody decision that we make at the architecture level will have a snowball effect no 1 problem that we have when we manage the technical is that project manager product owners business owners who want to know how can you measure that it will help you measure the interest why is this so large problem can how can we measure the interest because when we have a as loans OK we have the principle that we have the interest we know exactly the amount of money that we have to go to can we do this is aha I would suggest that it just you would notice that it gets lost features that's the worst thing as time goes on year later 2 years later it's implement the trees you cannot it is you cannot predict you can see from the start when you say OK I acknowledge that I have technical that you cannot see what exactly will be in the interest of this that but this time goes by it is easier than the easier of for people to see OK I have to fix something it takes a lot of times but when I think that the application will break following than other places usually that technical that makes your system both regionally and fragile when you have this it's not open to change and you can know everything that you deliver be a new features for bugfixes fixes take longer and longer so that's 1 way to measure the important thing is that every time that you have this you probably should discuss with the people who on because you're gonna have questioned why is this the simplest fixed state so long 1 why doesn't the cell to have this simple fix fix the ship why does it take so long to have this fixed you should never have been deployed on a production environment so inference of from we have to many of us that this question is not like to late I mean if you've already gotten to the point where features takes so long to implement it are we just now realizing that its technical that's this from 2 years ago it's a matter of acknowledging if it takes 2 years for us to realize that this is that that then we do something wrong at some point usually technical you can notice that people that a lot of than that but probably was not communicated properly In this work we have so here we are in the years to come up with better the program is fact right we have the look right to you have that's correct the requirements change during the last 2 years yeah I and that the again more of this a big

1 was it was responsible for that is that everyone OK well OK so this is the knowledge what does it mean that something is everyone's responsibility in nobody would do it exactly OK however you're correct technical that is everyone's responsibility and when you encounter it the least that you can do this community that is that we can do is communicated that this we can do is start discussions discussions discussing around OK now some of the things that I think that would have some impact on preventive search if you're building something in England know how to build a search for if you can find a proper solution ask I encountered with the lack of asking for how how the numbers of patients and it doesn't need to that it has nothing to do with pride or ego because in theme we're all trying to achieve the same thing pocket what BOC that's a proof of concept if you don't know how to do it create a proof of concept and that's the line of sight of the previous this just do the bare minimum that will allow you to scale and the infrastructure make sure that you have been interfaces your communication interfaces or correct be aware of how you're gonna skip hall you will you have to scale if it's going to have to be horizontal or vertical it really does depend on the application of at the

specification level the very 1st thing is communication if you don't have communication we will not be able to fix that because that at communicating make sure that you communicate problem of you wear off what kind of hobbies that you can and you have to communicate with non-technical people the 2nd line is what when we work on projects when we start the project usually we have a few a few steps that's BOC POV an do you guys know the difference between these 3 things POV perform value provide valuable what think about the fact that you're building an application you you all an application to to build what would you what the market that your and the ring is not exactly what you there is no reference to what you are doing OK you want to be sure that before you start building it then it you can prove yourself now this is done so instead in a number of ways you can from simple low-cost clickable Markov that would demonstrate the value for the stakeholders of for investors to having an actual application that works and then you can do something like life testing that you interacted use you analyze and decide if you're moving forward or not is very important that you know the proof of concept evolve and and the and do not let yourselves Bhopal leaning discussion something like this is a proof of concept that ends up in production who's who solace I don't OK and yet meaning of viable product the and what is what yeah yeah the exact and do not make assumptions and this is of the the famous last words are what could possibly go wrong know what to do when you actually have technical that the very 1st step is to identify at least in my opinion next we know the exact problem is communicated and make sure you translate this cost every time we want to fix something it's cost it costs money right so of make sure the costs of not only from all of the money perspective but also all the from the impact of the change that you're doing if you don't have a clean interface is if the cold that you roll is used in numerous applications make sure that you keep your keep your interface thank you can sustain and and communication and from the communication parts what results should the result it would be the plan to pay off the debt and this is a discussion sometimes when you build something in it's wrong you also have a lot of coders build on top of it so it's a decision that you you have to see if you have to pay the principal part of the actual that implementation and also the interest and which comes 1st you have to fix the code that relies on about implementation for you have to think about implementation 1st how would you approach physical force it's a dependency correct when you change the core part is is gonna break everything you have to fix everything else and this is just 1 of the cells so it was you have you can be smart about both these interfaces and keep the part of the bad parts for later on right I don't know no collaboration yeah as we discussed already is everyone's responsibility where all of the it's all responsibility to fix collaborate but when I O discussing about all evolves as a as responsible for the code 1 for the technical debt and for fixing it I'm not only discussing about the technical thing it has to be a collaboration with products and so on were all that were already you have to have timelines you have to have a plan and say OK this is how a line of fixed and this is how the being of the technical being offered technical debt and interest fits with the end of Part I am sorry that lies and so on this is actually

the last of the presentation did you guys ever hear of something like I don't care about technical debt literally like OK you guys hear something like this is a problem we acknowledges we're gonna fix it later this is OK so what the context when you hear this on time so if you will of the so that we don't have the resources through these these there's usually but the other thing that I saw was that there is a difference between companies and this is guys companies that leave out of delivering software or more interested or should be more interested in bringing of being of thinking that this does not necessarily is not necessarily true for companies for which software is a held to the business it helps develop things for them for the for the for the 2nd of what type of companies having manually tweaks for tool tree 5 6 releases having someone actually doing something that can be automated for instance it's acceptable pushing it to fix it might not be the right solution it's a business decision India however if what you do is actually software delivery and if if you leave out of software that's that's your core business and technical that is something that you certainly interesting and should be interested in more than anything else the that next you the and I and get to the people on the move from the implementation the infrastructure each time the eyes and you know the the question was what about all the way the usage of open source software written applications where you have the technical that how can mitigate or what you want to get actually because you get you get it for free 1st of all know what you're using and try to know the at the library the application the open-source project that you using know its limitations no it's boundaries this is something that you do at the beginning of a project if you can if you do not do this part of analysis if you don't take time is very likely that at some point you will end up with a lot of technical that's 1 thing that I think you can mitigate is once you know what the technical that is within the project is going to have an abstraction layer to communicate with your own interface for the stuff that you need if that is possible that would be optimal solutions if you rest the other solution well 1 thing I had to do was actually going to fix bugs in orchestras projects we were using because a battle distress projects since its department product now in a way it's also my code still 1 using in and it's part of my technical there so I have to fix it back and was to fix it create a pull request for it finger at don't keep it for yourself if it Michael might not getting for the integrated depending on like in the project anything else any other questions the concept and for freelancer or a contractor was the whole they should deal with technical debt quantity doesn't want to have to pay more for fixing bugs that may be dangerous for him 1st project code do you think we should handle that when we have Francis you have to them of their a very clean way of explaining that definitely that will cost you have to be able to have an argument why does this state as long as if they want why do you have to fix he has to see the fact that not fixing this would cost this much this much immediately and this much in the long run usually is very hard if you're a freelance developer to make this argument at the very beginning of a project the 1st thing that you have to lose a lot and even some people say that OK marked also singular project I trusted by default that is really the case trust is something that you are not object by the before was the client gets the faster C C is the result the results of your work is gonna be easier and easier for you to discuss these kind of issues which would deal with him so it's Maria communication problem and of trusteeship so the of then

How do I get a dollar measure of my technical that the events like hitting times In time span and for this you have to have historical data so yeah actually say we should measure the cost of fixing bugs so yes because if you have a lot of time somewhere right and have to say OK this is a simple fix when that what would be the pixel to have done like difficult so long to have a ship this translates to cost in terms of flow dollars immediately so the all all that I would like to what try to find ways this Our research paper here and there but talking about holidays protects rights to measure taken that and I'm really interested how come that we are that will develop a communities and of freelancers and all of us are value part of this don't have like some that we could you know just run on a code and we could get things like a there is some on they conclude that that fine at find is the index file from and you can already do that but there are some other metrics and you have to be smart about it how would you implement such a tool yeah so the question in fact that there the thing is really errors can have implications for 10 with that but uh just math and that really tells her work and that of modern art agism allows it to serve their sentence that and there because from this this is especially given the sentence of their transit across different from there's no direction solution from southern Europe find some according to the cost that it's affected that the cost may actually is 0 and in some cases because you can you can sometimes stated on today this is this is not the right way so it it might have cost us something to fix it but not exceed its position that's because the remarks but in regression and use them in the future that might force us into fixing it but this is 1 this is an example of is very good for instance in the banking industry some of the some of the banking industry actually has mainframes this urinal callable no 1 of the things that they're going to maintain and the gonna of interface and the around it and they have people who maintain it costs too much to have it fixed for instance because you get this is a natural way some of you are not yet as just common that sometimes you have situations where am paying interest is the best business decision for you because fixing it is too expensive and maybe the project is and and so and you want to change in this code you just pay the interest until them it's for it's fine it's cheaper here and if you have if you have a technical that that isolated modules you have your interfaces well-defined it does the job I just want to add to the question about why don't we have a tool that can just tell you there's a technical depth of this time of of this money there actually are tools that can tell you that if you look for example at similarity you can specify the cost of different but code violations and it was calculate calculated in dollars for time but basically goes to your code finds all the violations that you specify and to look into and just sums it up it's actually pretty good tools but pretty good too if for example you have of some legacy applications and you're building a new feature it's still you choose simply cannot eliminate the technical debt from the whole application you just you just know that this 1 new feature you be working on it all the time so you want to eliminate as much technical that from that cultural buildings right now so it can actually tell you that was the difference in from the rest of the application and there there's a lot of stuff you can specify but there as tools to do but 1 thing that is in the across tools they're going to measure it your code quality you can see that that's the 1st thing that that the 1st step right you can alter latency OK I have these lines of code I have undocumented code I noticed I have so much responsibilities here I have this this and that how do you measure technical that Europe the way of yourself architectural level 1 of the specification of the minimum of the go over that of course so for basic stuff yes you can use to if Michael might not translate to cost on the other hand was gonna fuse the technical that but we can team we have we were all developing on different the different levels it takes more or less time depending on implements depending on the experience of the person we implement it's not something that is out of the box you have it out of the box and everyone does it the same way home you a plant to pay out that that's how you didn't accept to Taiho do we they technical debt to remove it so of refractory for the roots are writing the medication from scratch the will which the whole can you can call can we reserve when we should do want horizontal over at which ones are actually actually I did what I mentioned there but I didn't explain it was all about communication and timelines and that like the decision if you're gonna pay think of the technical that and interest incrementally is that this is this is not a technical decision on a circle this completely unmaintainable and you're not able to write anything in the than the correct decision is to rewrite but even then you're gonna have situations when the decision is going to be what does not the united within the united incrementally so it's not something that you can see as a rule when you're doing this and 1 when you're doing when you decide to rewrite it when you decide to go fix it incrementally think about this the software these usually there is maintained developed for 5 years of actually actively developed and after 5 years you get into maintenance so that's that the time frame for a for a software depending on the industry that you that you work you

cannot just rewrite the piece of code that is 1 year old when it's not necessarily the best the best policy must cover the specification of the specifications were completely wrong but then you have the proof value should have validated this in terms of business so well I question is anyone here a fan of the boy scouts rule I mean that's 1 of the things I like to do when I get to the set of the coded I need to work on it I also fixed whatever's and in 1 person elected touches you go refactoring I think if you get to the point where you need to go back and we factor something for a long time it's probably so costly that you won't do it so maybe try to do a bit of refactoring every time we developed this anyone else a fan of the all when the boys get what I think it's important that you separated the code clean up from the functional changes that's all but other than that of crap taken up from the there 1 at 1st I was added to the skeptic about through it and I didn't believe that must for example our entire tests to borrow and function and the thinking brother of virtual worlds romance and nobody wanted to talk about but we started this was our 1st internal perfect phone started using this rule and of about half a year later it was in much of the design process slowly referendum and that and that every time we need a change something progressed through an additional the effects of that the tests instead that there were other parts of our system which were about design and said that there were only in worked also shown I can recommend that and 1st so don't be afraid of is that this is this blue working times but it requires much more much more time than we can imagine that there's just food you can write it would take about month yeah this is the thing 1 of the most basic and maybe you want the of because we show that the people of the impact of the that's 1 way to put it so it's about approaching of legacy applications application when you cannot get rid of that this model writing single then make sure that you don't have that you don't figure all about what my question is how do you and the new projects and this might also put prove it in this but also be solution for dealing with legacy applications when you go ramp up on the project is already being developed 1 of the best ways to ramp up is to add the unit test or at best when you have a legacy applications this also might be a good solution to see where your problems or because they're all C ports what you describe 1 is writing your code that is clean and nice and neat and the other part is actually a making sure that you do not have read the about regression and so on so you don't break anything that's already there In order to to be able to develop a certain degree of certainty you have to have at least the basic laws often application that's beating it as the integration that's whatever efforts of if it's survive application level we why something that you have to have a certain degree of testing that will validate that what you build is the good solution at least it doesn't break anything else but this is 1 approach that I would they work on the desk at more set up a lot of continuous information system reasons for that if it's not already there you really want I think it's really important to you that you have in that you have good code review that within the team you know you you agree upon certain standards and yeah people look at code give feedback and things like absolutely good quality you are for a very important now there are 2 types of coding don't try to call the view something that can be automated don't try to have I know that follows about violence and so on and we can hold it uses an automated tool for that's the problem we call the users that those when you have 50 lines of code query the user will say will find probably 10 or 15 each you have all of you for a gospel of 500 lines of code for the call and will be used to drink so make sure that this is awful and for don't have a large pool requests incrementally speak display of things up in such a way that will allow you to have a small smaller but it's not always possible but when you see you know you submitted 500 finds of gold and this isn't it looks good to me OK it again please I would like to make sure that this is actually OK because when you look at the code you know what call the view on local on the codebase also I think it's important if we can the CodeView process to follow the requirements that led to that co changed make sure that it also feeds the business value or the forest where the description of the requirement itself and this brings up another discussion when you have requirements and probably fewer working in a job you have user stories make sure that you have always have the tree parts of the user story as someone I want to do something because of that will allow you to have at least half of the discussion about the best solution for for the problem I wanted to stress out from solely in the team and communication part that sometimes are many too often we overlook the infrastructure never technical debt and goes people or borrowers tend to frame here and that they have to deal with uh the stifled database because it's there and he says no just maybe trying to discuss with the others guys and tell them maybe was dressed which he there on my on my on my parents and would allow me to avoid this kind of detail that that is the subject of exactly the the the the other guys so that very often

proteins or spilled between the development team and operations OK there are 2 things here 1 is the operation the school has to deploy your code and the development team who has to deal with the constraints that come from the operations if you don't have the communication between these things if you have the things it's a very hot spots on the other hand you developed was as you as a developer should live with the pain of the going what I wrote right everyone should live with that pain but only the odds guys and on the other hand possibly also the all guys who live with some constraints of all the application that we will as the only way to so be the oxidized try to be part of that parts of the see what they have to deal with maybe will allow us to better see why you have some constraints and some somewhat of limitations within the project or we can the but in the past this is a better solution compared Western but I still hope to technical debt using techniques like on a lose their their programming with your team are nature said we think small Peru question is clearer remember how use the programming versus mournful request on the yeah I mean what are the 2 techniques to avoid technical debt it depends on how your organization is set up if you can do better programming extreme programming that's OK I you so it depends on the context is not necessarily something that you forced this sort of but yes I think we still have a couple of minutes if I have something of for there are people out there who have followed different the level of that would that would be 1 thing that that I of having less of verifies is always useful but in this way you also really I think it's it makes sense to pair up watching a programmer where the more senior developer and it also might make sense to have the marginal person typing so senior cannot like step forward the journalist I'm just going to have to suffer a great and a junior doesn't get what's being absolutely and 1 thing that was suggested to me in in thing that I want the before was actually have a junior people believe using people's code for instance but that's different from the program both both people involved in their programming should follow the business rules that you have to make sure of that besides that so if you have a commission for everything that's called base related you should end up with the best solution from the construction so you register was count through their and that's some great successes conclude that because I ended up doing with my 1st to really break away power project ride droplet-like 20 thousand lines of code almost without the social quite syntactical that and firms that's running on like different platforms and so was kind of a pain so started to right tests and that have a script with coverage of high rise where have a list of perfect file so far as with 100 % coverage and for those files to coverage may never decreases because it was too early to enforce coverage always increase and because are just some things will return not testable so that's what I did and what adults verydifferent from me yet and that's only going to set it up but on the other hand don't rely on coverage what we might think because college also depends on how we write that test having 100 % code coverage is not necessarily a gold it's having your business but properly test that should be available it might be 60 % you might be present some things may not be worth testing that is that's my personal opinion I know there are people who say OK what we have to have full system that's for that but some not all it's not always possible if you write an open-source library for rely on the initial coverage should be as high as possible because other people realize miracles which in your project is also a business decision or when the mother's business decision but an educated decisions have you influence tested that have Europe the positive negative flows tested but 1st of all make sure that your code is actually that input processing out single responsibilities principles and so on so stuff on a new project for making a new project is year to test you with the we detail would it be smart educated to uh that uh service-orientated architecture moreover if if it fits your requirements and if it future project short we can use a so I mean that do you have latched purchased it approached stateroom reach are for very difficult task in which because the bad decisions or not they are not well again the answer is it depends you know what I've seen projects that our model it and people started wanted to split them up within microservices and the reason behind that was that it was you it would be easier to deploy if you go poem model ontology you will not be able to deploy and maintain micro-services so it depends we still have time still officially now supposed to and about 2 minutes ago but the topic break starts in 15 minutes I think we can in of reference to about 10 addresses 1 just continue some questions and especially in the scatter in the front and chat somewhere be . back as I have had 1 more 1 more slide actually this is like what happens when you

try to fix that little body in the form of fragile endangered environment there is