About this talk
This talk explores the themes of simplicity and complexity in software development, emphasizing the vital role of teamwork in solving technical challenges. The speaker engages the audience through a simulation of a developer's daily workflow, discussing common obstacles such as debugging and communication barriers. They introduce the KISS principle, advocating for clarity and simplicity in coding practices. The speaker argues that many complexities arise from human actions and AI, suggesting that effective navigation, UI/UX, and communication can mitigate these issues. They encourage developers to simplify processes, utilize best practices, and improve collaboration to enhance code quality and user satisfaction. Ultimately, the session stresses the importance of continuous improvement and adapting to change in a dynamic tech environment.
Full transcript
Hey. Welcome to the session. So, today we are going to talk about simplicity and complexity. But, this session will be very interactive. So, please don't hesitate to join me, okay? Today, we will have a kind of a simulation. We will work together. We'll be in the same team. And we will solve the complexity together. So, first I would like to start. How is your day at work?
Just a regular day. And hands up if one of them fits for you. So, maybe you are dealing with same problem every day. Hands up. Same Cool. And maybe you motivate yourself with coffee. Coffee lovers. Amazing. Amazing. And maybe you don't have big problems dealing with the big problems. So, you are a problem solvers. your days are just chaos. And you say that nothing to see here.
Don't visit me. Hands up. Chaos coordinators. Well, is the simulation that we are in today And I just tried to rephrase a regular day of a developer. But, first I would like to start. Who are the developers? Product people? Business product, engineering managers? Product owners? Okay, cool. So, hands up again. Who starts the day with cup of coffee? We are unhealthy. All of us together. So, I
call the day like a brief. We brief things. Like we start day with cup of coffee, drinking the our coffee, trying to plan our day. If you work agile, you have the daily meetings and catch-ups, something like that, right? And later on, after the meetings, you check the the commit history, like reviewing codes, finishing some tasks, if you are lucky enough. And maybe more meetings, like catch-ups,
small chats, something like that. But after that, when is more coffee? unhealthy people >> [laughter] >> Well, I call it more little things, like more coffee, more coding, wrapping up something. And if you are not lucky, you're in the meeting. Then, try to decide, now it is focus time, and we will finish the tasks. I'm ready for it, I finish everything, like a daily responsibilities, and I
will just start my task that remaining from maybe yesterday or week ago or last sprint. I will finish it today and I will just go home. It's my purpose, right? No. Because an issue is reported on production. 6 months ago, we released something, it was working fully fine for 6 months, and now something has changed, we don't know what, and we have to solve it as a
team Ready? What we are going to do? Checking last 6 what we have changed. But I am pretty sure that because I already check every day, doing the code reviews, checking the history, nothing had happened to affect this feature. But now it doesn't work. All I know is it doesn't work. So, we do very good things, review the code again for last 6 months, and recall and
revisit the business rules. Well, as you see, we are happy because I need a pair to fix it with me. Because I am kind of a blind, I couldn't see it. I couldn't find what's going on because I already said that this is not my problem. But apparently it is. So as a team, we do pair programming, we check the documentation, and we decided not to do
it because it was too much and not up-to-date. And it says something else. So I need going back to debugging again. But I realized that it's not going to be very effective. So we separated our ways. I said that an hour everyone works on it. If you find something, ping me. And I decided to keep debugging, trying to find it out, but I need more coffee and
more music. It's me. [gasps] >> Well, I am not that cute when I am pissed off. Because I found another bug while debugging something and checking the business rules. I fixed that. It was in production, but nobody complains about it. And now I am in between questioning myself, my role, and also motivating myself because if I solve it, it's ego, right? I solved it, the complexity, the
problem that we couldn't solve during the day. But on the other hand, I'm spending some time and effort, it's headache, it's communication, and what I am doing here? Well, good news. I found a happy path. Happy path is conflicting business rules. I have many of them in my code. And there is no solution yet, and I AI didn't help me. It just makes it over complex and
gives me the the other solutions. And when I fix it, it says that, "Ah, sorry, you are right." I don't want to be right. I want you to be right. I want this problem to be solved. That's it. And I need more coffee. Who needs more coffee? It's almost evening. I need more Unhealthy people, thank you. happy path also includes coming with some options to the solutions
and presented to the team. Seek all opinions, right? Because we are as a team, we need to decide it and go with a solution. And what is best for us? I love that part. It's super cute. I call it test-driven chaos. It's a comedy. And now we are going to run our test Not only me, all of us. So, it's a vehicle. We call it a vehicle.
It has a four wheels. Yes, I counted it. It has a four wheels. And it has two doors. It's not a bug. It's a feature. It's designed as this. And it can drive on the way. Yes, it can. And maximum five people can fit in it. Yes, I count the seats and it is designed for it. And driver is a must. Yeah, it's in the And it
is green. Debatable with UX designers, but it is kind of a greenish. Engine works fine. Yeah, I hear the the noise. It's it's it's working fine. And lights work fine, but I only test it on the light mode because I cannot simulate the night. So, I accept it and I move on. Congratulations. Applaud yourself. We made it. We solved it. We released it. But after that, all
of that, I'm so tired. I just want to go home. I am overthinking. All these tests are delayed and I need to do something because the time constraint is real and my tests are delayed and I'm very tired. I just want to go home. And what about the code quality? What will happen if someone complains about that feature tomorrow? Who will touch the code? Who will solve
it? Well, who wants to solve it? I am Virgin. I am a senior mobile engineer in the regular day and I am a public speaker engineer mentor and coach and I travel a lot. I love to play guitar. And today if you are one of me, then we are going to solve this problem, I hope. Who knows KISS principle? Hands up. Amazing. I asked the same question
once once I was in Germany in a conference and I saw many hands went up. I was so excited. I said, "This is amazing. Everyone knows it." And I skipped explain explanation part and I went into the details and couple of minutes later I saw very confused face. And they look horrible. They were confused and deeply uncomfortable. Then after couple of milliseconds, something like that, there was
a woman on the front row and whispered me, "I thought you are talking about the dating app." So today I want to tell you that I am not talking I have no idea what is KISS KISS principle in dating app. Later that I learned that they are coming from a dating app production company, whatever they do. And they use that short term. So it is computer science.
So I would like to ask again, who knows the KISS principle in computer science is science? Yes. Perfect. We are on the same page. So it says that everything should be simple enough and clear enough so you don't have to need Sorry, you don't have to explain it with using terms or shortcuts or more explanation over it. Like, this is home. This is tree. This is cheese.
This is bike and windmill. Like you are talking 3-years-old kid. So, everything should be simple enough for everyone. And I would like to ask you, what would it be like if everything was that simple? Like traveling, cooking, writing code, solving the problem with AI agents. >> You know, everything. Like a problem solving with your co-workers. According to KISS principle, most systems work the best if they are
kept simple rather than complicated. But who makes the system complex? My answer is humans. But lately it is AI. So, uh you should watch it. You should And I thought, what is the basics of simplicity? And when we talk about simplicity, we need to simplify it, right? So, there is no basics. It's like a game. So, it should be strategy of simplicity. And what are they? Like
a navigation, UI, UX, and business and performance. Let's go into the details, right? So, what I mean navigation, so you should know where your code leads. Like what is next? What is back? What is continue? What does it mean? Well, let's imagine you are met you are in Matrix, you are Neo, and you are calling the agents Smiths >> to fight with it. You will say the
word. But they get confused. They don't know who you are asking. They have millions of agents Smiths. So, you have to to be very certain what you are doing, what you are asking for. Well, it's the same for the code. What you are asking for. Where do you lead? Like user actions. What will happen when you cancel it? When you have an error? Then you go back,
then you have an error. And you need to resolve and identify like failing state and success state, data losing, caching mechanisms, everything, right? Like a logging. they call it easy, but it's not. >> And when you call it UI UX, the biggest problem is the gap between product and needs. Because as uh computer engineers, we are doing what is given to us, but we don't know what
it for our product. And who is it for, right? And what we are doing is hallucinating. Like an AI agent. How it started, how it ended, it's very different. We lost people during the process. We lost ourselves. Our purpose, and it doesn't match with each other of what we are doing here. Well, it's a good question. And how we can solve it is basically trying to be
consistent with your styling like um Android, iOS, web, back end, AI agent, because everyone has their own style, but you have to collaborate everything like a harmony. customers are not idiots. They are not there to consume whatever you give them. They need specific things, and you have to point out them to be better product. Well, performance. Nobody tells you that you are amazing. I love your performance.
It's amazing product, you know? I could send the money to someone with using banking application. Is it amazing? What it should does, right? So, you don't say that this is amazing. This is perfect. But when you have a problem, you hear from people. So you should manage. But manage what? The expectations from your manager, your teammate, your product, your customers, So this is not really only coding
work. It is communication skills. It's soft And when you kind of go back into the coding skills, you have to manage your resources like threads, network connections, and the files, memory, workload, using the animation, whatever you call it, is your resources. And you should improve. Well, we keep talking about the continuous delivery, continuous integration, continuous improvement, but it's all together. Because when you do less, it's more.
So you should simplify your flows, how you are dealing with the problems during your day, your regular day. And are you logging and error handling and caching everything? I don't know. What do you need? But you should point out what you need. I cannot talk on behalf of you or your product or your And using right third-party tools, SDKs, integrations, whatever you call it, I call it
as a hell of third parties. Because you keep adding more layers and it becomes complex to manage. It's unmanageable. And let's get back to business. What does it mean? Of course, money. Business means money, right? That's why you're working for. And what is the king's principle in it? Because you want to manage it better, right? You have to keep the money flow in your system. And when
you have a clear rules, it means that you have a clear path. And as a developer, as a product people, as an engineer, you know what you need to do. So you don't have to guess your work. You have to do your efficient work. Well, let's imagine everything is simple. So you know what to do, right? And clarity means happy users. And when you have a happy
user, it means that you have transparent rules and fewer mistakes and smoother process. So, it's a circle going back. So, you have money, you have this. You All circle. Fun facts, I love that. Because as a customer, I really don't care about how your product works. I really don't care. And your hard work, your operational rules, your overwork, And the complexity that in your team and your
product, it doesn't bother me. It's not my And your architectural design, technical whatever you do, is your problem. If you have a cut coverage, it's your problem, not my problem. As a customer, I really don't care about it. But as a developer, as an engineer, what I care is the culture, not the code itself. Because I should really know what I am surrounded by. It is the
people. People is my teammates, my product people, my manager, my customers, and the my product, I should know what is it for. Well, otherwise, it's just a chaos. And well, we should ask questions. Why we are doing this? What should I do? If it is not simple, we should make it simple. And as an engineers again, we are in a rush that we should just finish it.
But before finishing it, deploying something on production, why we are not drafting it and asking for feedback? Is it simple enough? Ask someone else in your teammates or other teammates. Just ask it. Is it easy to read your codes? Well, clean code, I think we can talk about it for a year or two. Because everyone has their own idea, but it is about your culture, your team
culture, your product culture, your company culture. Because you need to engage and collaborate more than you think. And the next question is, do you want your life to be better, worse, or stay the same? Well, my motto is things always get better unless they get worse. Yeah, makes sense, right? Or reverse. Things always get worse unless they get better. So, what is the point of it? Change,
right? Well, we have a strange job because we have to deal with many things. And if you are thinking that I am computer engineer and I only write the code, it's not the fact. It's not the fact. Well, we have a roadmap for it. But what is the roadmap for it, you know? We are talking about simplicity and and complexity, but we have a roadmap for it.
Like we have modularization, cleaning code, documentation, clear architecture, stay updated, and UI unit test. We already know about it, but what's the different when you think about the KISS principle? Well, modularization says that, "It wasn't a code base, it was a crime scene." Most of the time when you see that the code is horrible. Like onboarding your people into the code base takes months, 6 months, a
year most of the time. Well, modularization says that break your system into focused replaceable pieces like LEGO pieces, And if a function does more than one it's doing too much, so it doesn't work. Sorry. And documentation says that we had but it described a completely different Well, keep it silly simple, right? The best documentation is your code. But we are engineers, we love complexity. I don't know
if you're familiar with the disk color profile. Engineers are mostly defined as blue and the red. So it is when you are a little bit like a complexity, trying to play hunting games, solving the problems. It's wrong way. And if you have document why, like a paragraph or something, they say that you should rewrite what. So your function is not doing very well. But with the legacy
code, let's be honest, it's not the always the fact. You cannot rewrite legacy code all the time. There is a cost of it. Well, we will go there. And don't touch if it works. Hands up if you have ever heard once, don't touch And hands up if you said at least once, Well, there is a cost because you have to know your product and you are responsible
for stability. And you have to support older and newer versions. And nowadays, everything is going newer, right? And it is very hard to keep up the stability. And performance improvements always include the legacy code. And when you change something, you had to rewrite most of the thing. And this is very how do you say it? Very expensive. And there are risks because you can break many rules
or rewrite some of them. And then you have to collaborate with your product people, right? Because sometimes you say that this business rule is not what it anymore. You had to re-change it. And money innovation costs money, but don't forget not doing innovation also costs the money. Because you have to deal with the migration later. You just postpone it for a more expensive way of doing this.
If you are proud of how complex it is, that's the problem. Well, that's true. Because if it needs explaining, again the KISS principle, it needs simplifying. So, you are doing wrong again. And readability first, like a naming, comments, commands. It needs a style. It needs a teamwork. Not only you can save the world. and again, modular design. If you have a LEGO pieces, it's easy to change
it, And delete the unnecessary. I love it. The best code is deleted code. No harm. And update the docs, please. Can you update the docs, please? Well, clear architecture says that the architecture was perfect for different product or a different company. Well, what is labeled best doesn't fit in your culture or team or project, it's not the best. You So, you don't have to follow the what
is best. You have to follow what is your best. What is your best you can modify and update and use it in your project. And if you needed tour guide for your but this is not true. You know, something is going wrong and I need a therapist because I cannot be on board that in 6 months, is a big problem. And structure is a contract for everyone.
Again, it's a teamwork. Not only my job or responsibility to do it, but we have to deal with all together. And time is real. We have to be on time. So, you have to plan it in a simple way, your next moves. And document style, of course. I need hands up. >> Hands up. Yeah, it works on my machine, but it doesn't work on production. Sorry. >>
So, what are we going to do? We need to verify the behavior, not the implementation, because implementation will work. But behavior not. And you have to keep updated. And you can never imagine that an outdated test is worse than no test. And don't do it if you cannot update it. UI test gets more than you can imagine. Like a font change, rebranding, and icons, and everything. So,
don't say that this is manual work. No. Just make it automation. Alex is working on the book about the using the right frameworks and the how to do make the test frameworks. So, you can just uh thank him. If you need. >> [snorts] >> To wrap up. I love this part. We are not Sherlock Holmes. It's not our job. We are computer engineers and we need to
simplify flows and everything we are dealing with is for our own sake. And less is more. Don't try to add many things on top of each other. Each feature needs to be for a functional change. But if we make it more bigger, broader, it won't work. It's not simplifying the flows or functions. And there is a very good tactic. Ask your grandma. It means that you give
your product or code base or whatever you call it to your grandma and you explain nothing. And you just watch how painful it is. So, you can verify your simplicity with And you don't need to be Shakespearean. Just be easy. Be simple. Don't use complex words because I again I know of complexity. I But you shouldn't be proud of it. It should be simple enough. And Sherlock
needs Watson. I need documentation. Please help me to understand what the code does. And if you simplify everything, it won't take too much time. It's just a one or single single or double line of explanation. and our code should be a harmony symphony, not a hard rock metal concert all the time. Although I like it, but it can be very painful and give us headache. And think
about your teammates, right? We can do it together. Thank you very much for listening me. I'm Burcu. You can connect with me on LinkedIn. Thanks. >> [applause]
