 My talk is about anti-patterns in open office. It's basically anti-patterns you find everywhere. So, let's see what I talk today. I tell you a bit who I am, what I want to do with this talk, what are anti-patterns in general if you didn't heard it till now. And then we look at four anti-patterns, exemplary that I have chosen, that I could find or I think they are in open office. They're concerning two different development practices or disciplines, programming, methodological styles or ideals, project management, also open source does have project management, not only close source and software design stuff. For the people on the video, there are two slices. One is not splitting the slides. I split the slides quite often so I do not overestimate the people. So, who I am, my name is Peter Kovach. As a profession, I'm an IT consultant for ETL systems. I usually work with big data stuff. For more than 10 years, I use privately open source since 2004 and since September 2016, I joined the open office community to improve open office. So, as you see, I'm not really an application developer, but someone who usually moves big amount of data around for companies. So, while I move big data around for companies and for big ones, not really small ones, I find anti-patterns always. And funny thing is, I find them in open source as well. So, anti-patterns are common. Just keep that in mind. And even I have not told you what an anti-pattern is, but we will look at what people do or did. We will assume what might have happened, but it's not to bash people. It's very important for me. It's bash the code. There's something not very well done with the code, and it happens always. Even if you go for best face, if you're trying to do something very good, at some point you don't have time, you want to shortcut or something, and then you use an anti-pattern, because it's usually the dark force of the side of coding. And my goal is for this talk that you are aware about bad designs, anti-patterns, or what not to do, or that you have done it, and maybe keep in mind that you will return to that part of code and try to find a better solution. So, what are anti-patterns in general? Anti-patterns are ways to develop something that have proven to not be very good. So, we do not focus on what worked. We focus on what hasn't worked for various reasons. In methodological patterns, we look at abstract ideas, stuff that we know from development science or software science, how do you call it? That we learn actually in school or university or something. Programming patterns are steps, development steps or programming steps we use in order to achieve a goal, and the anti-pattern as it works, but it will get back to you at some point in the future. Software designs is when you have an overall idea how to, your program is structured, but yeah, well, it is maybe sounds good, but it doesn't work out. Project management pattern is, usually, has nothing to do with coding at all, but with organization in all around what you do in the cooperation or in the cooperating way. And this is really also not so, usually not so much in focus and open source, but more in companies, but it's also there in open source. So, let's look at one methodological pattern. My anti-pattern of choice is copy and paste, who hasn't done it? We have here some actual code out of trunk from open office. The code is not important for me so much, but let's go a little bit. We have a template of some sort, yeah? So, we can reuse these steps of code by just modifying these variables in this fat, in this bold type thing. The underline stuff is the function we will get. Then this boost-desk-assert is some quality checking. Then we have here a code line and a return statement that we will have. This green mark statement is important because right next to it, we have the same function almost. I mean, there's some differences, small differences, but believe me, it does almost the same. So, especially this one here and this one here, the green parts are really the same. So, my assumption is that because this code is used and we do not know maybe what is the real impact, we do not have time to researchers or we are not interested in researching it. So, we just place almost the same part of code by copying it next to it and use that instead for our new stuff we want to do. Yeah, maybe at some times this one will be dead code and we want to delete it or whatever. But basically, we have parallel usage of the same stuff and you might think in the long run, this will come back to us because we could have get that code so no one is not really knowing what this code does and is quite unsure what to fix or what to change. And the other one is, yeah, maybe also that it's not so clear what to do next or so on. So, in case you just believe, don't believe me, it's the same. Intervert position is this sign of, this sign of you find here. Yeah, this is also a piece of code which is above the code and the bit mask is also there which has been put here. Yeah, so it's really, really, really the same. So, yep, look at the next stuff, still the same code, cargo cult programming. I like to use that when I learn a new feature and then I use it always, if it doesn't make sense or not, I use it just to train me to get an experience when it works when it doesn't work. I think this happened here because this guy really or this piece of code really loves templates. We have these two codes, we just have a steep look at it which provides us a function. This functions are used in this class here, which is a pack pixel column iterator. Then we get the next template with row iterator. And as the last one, we have the iterator itself which can do both. Now, yeah, this is really fancy. If you order our code only using templates, we can really put a puzzle together and just puzzle what fits together or not. But in software development, we have, especially in CC++, we have more ways to program it to make it better to make it readable. We could have a program iterator or a pack pixel class that can work with a row iterator and a column iterator. We just load the special iterator we just need for our special case. We could integrate this function in here because it's also the same as we have seen it. So it would get very much readable. And templates we have used do not help really because they opaque us what the code really does to us. So it's really difficult for the next volunteer developer or worker, co-worker to understand what you did. He has to phone you, has to write your mail or whatever to just understand what you did. Let's move on to the software design pattern. I choose the big ball of mud. I actually find that very funny. What is it? It's about you have a big software and you do not know really where something is. I picked something from a layout from OpenOffice. I think it's very old but it's still accurate I think. And now we have folders in OpenOffice where we have different modules where we find our code. And let's just try to figure out where in our software model does modules fit. Yeah, Siri, I don't know what it does but I find it here. It's not very speakable. Yeah, it's a little bit obvious but I could get an imagination what it really does if I dig into it here now. Yeah. So, yeah, I think, yeah, okay, sounds good. No big ball of mud maybe. P, you know, P, okay, I assume it with Python somehow. You know, I find here and here, I know what you know is. It's a defined word in OpenOffice development. So, you have a good idea what it may be, what I might be finding it. So, also no ball of mud where I do not know what it does or where I have to put that to. SC, SC is a lot difficult. Very old. Has anyone an idea where what SC could be in this screen? That's not Calc. Yes, Star Office. Very old and Calc we have here. Okay. But we also need a little bit to know about the history already. So, because Star Office is not part anymore of OpenOffice, yeah, that's history. Or LibreOffice for that shake, I think. Sallhapper. Yeah, now it gets difficult. Yeah, for me as a new developer it's really difficult where to put that. I put that here but I'm not really sure. Yeah. EPM. Yeah. I have no clue. Yeah. This is a potential candidate for big ball of mud. It does something, it's a park to you and you do not know where to put it. If you look into it and it gets clear, maybe not. But on the first glance it's difficult to put it somewhere. So from my perspective I would say we are probably have some balls of mud around in the code and who wonders at 100,000 lines of code. I mean LibreOffice developers face the same challenge, yeah. I bet. I read once as a heroic effort we reduce code by 90% at one place somewhere in LibreOffice and then change log which is really good. Why it's big ball of mud I think or other anti patterns. And the last one I want to present today is the death march. The death march is let's look at Wikipedia where you can find lots of anti pattern that you can look out for. The general feel of the project reflects that of an actual death march because project members are forced to continue the project by their superiors against the better judgment. So an open office we usually do not have so much hierarchy but maybe if you work in a company and your boss says, hey that's a good idea, follow it, follow it, go it and you're not behind that idea. You do not have any commitment for it. It's really annoying and you are on a death march. You could also have this in open source because when the community says, yeah, yeah keep going, keep going, keep going but you do not want to keep going. I mean you've done your share. You want to rather to go out with your girlfriend or something but everyone says, yeah here your contributor keep going. You're also on a death march. Avoid this. It just makes everything suffer I think. So this is my short walkthrough through anti patterns and what I could find or could think of in open office. The last one of course we had that some years ago where people quit because they said, hey I can't go any further. I don't follow you and it's okay. It's really okay. And to step up and say, no I can't do it. Keeps courage. Have courage people. Yeah. Any questions or how do you have idea how to avoid anti patterns? A new project. Would you stand up for people and say, hey friend, I read your code just for interest and it doesn't look good. Now you have arguments why it maybe doesn't look good. Anti patterns are really experienced when they do not look. Can I see a fix in coding anti patterns in open office is a lack of unit tests to safely recode something. Just to make it prettier. My own Java code, if a function exists, a unit test exists. So changing the implementation is safe because I can go and check if it's the way it's supposed to. I don't have that in open office. No, often not. But often these, for example if you have a lot of copy and paste or template stuff you've seen in the beginning. It's difficult to write a test against that, that the new code does the same what the old code does. The people who have written it are long gone. Maybe it's the third or fourth generation. I looked it up for this code since the code is at Apache. There have been no change in that part. They have no changes to be done. So that code has been from oracle times or sometimes or even older. Maybe from where Star Office was just Star Office. So we have that and this is really difficult to approach to change it. But you have to at least make a note that you have to change it at some point. If it seems stable for a couple of decades, why should I change it? Because you cannot maintain it. But I don't need to maintain it between doing what it's supposed to do in the last 20 years. Do you know it? Yes? So forgive me if I can't say it. But I think the issue is what the verses are. What makes it stable, what you have lots and lots of stuff that lose the job and you just keep letting it do it. Or just to reduce the footprint of the application and don't keep the history that you have kept for years. And your pattern is that what did you want to keep it? You want to do it what it does and don't change it with me. And he says just clean it up. It's like if you have a room full of books and you say it does and we have to clean it up and you want to make it as it is. And I think there's a balance between it. If you have a time it's needed. Sometimes it gets too long. I know it's not tidy. Yeah, I don't think we argue for the camera. The argument was we have to find the balance between tidying stuff, tidying code up. And leave it as it is because there is no issue in it. And this is a question we always have to ask. But if you change something, this is the message. And you see why you are changing or your colleague or friend or whoever sees that what you do will fall back. And at some point it's really difficult to change. As we have it now in open office. We have a lot of antipatterns and it's really difficult to change because we cannot verify it. If it's still then doing some effect and we change little things and they have really big impacts throughout the code because we cannot overlook it. It really gets very, very difficult. So avoiding antipatterns in the beginning is much more worth than fixing it later on. Oh, yes. My own code, but I'm writing something from scratch. Anything that exists has a unit test. And they interface the script. And if I find I'm heading for copper base, it's easy to fix it. Yes, yes, yes, exactly, exactly. And I want to share the awareness for it that you have to look for it, that what it does to you, I mean you see it only in old code. And my time is up. I thank you for your patience, your attention.