Software Engineering — A process
Hi all 👋
My name is José Miguel Malaca, I work at the Loop Lab of The Loop Co., as a Software/Web Engineer, and I was invited to give the very first Loop Talk that in the end is here, translated into this post. Nothing here written is some kind of rule to be followed blindly, but I guess that are good points to make us think on how can we do better and grow as individuals, and as a team. In the end I hope that these ideas are good for you to give a try.
When I was thinking about what talk I should give, I thought that I wanted to start from the foundations. Start from some aspects that I think are relevant for a good project/team build process. A lot more talks are going to be made here at the Loop Co., so why not start from the beginning?! So, what are those? Well, basically, I have selected four subjects for us to think about without a particular reason. The truth is that I like to discuss things and the Loop Talk was a great opportunity for that 😉. So, let’s start.
Communication
How the communication is done in your organisation? Do you use slack? WhatsApp? Trello? Or any other app? Or even multiple apps for multiple purposes? Or none? Do you write down the decisions that were made during a meeting? Do someone new that got into your project have a place where he/she can search for info about it? Can someone see on some feature trello card the first definition of it, to the last decision and definition that was implemented? I could make more questions, but I’m guessing you already got the point so, let me ask again: how the communication is done in your organisation?
We always have space for improvements, even if they are small ones, and this topic is always a good one for that. Here at the Loop Lab we work onsite. For anything that I need, I can just walk and talk with my colleagues, but there are some details that can make the difference even when we are all in the same room. For example, placing all the discussion about the development of a new feature on the same trello card or github/lab issue, working with RFCs or even to a good commit and Pull/Merge Requests messages. Imagine, 6 months later, you will have the context and details about what happen, what was done and why.
Another purpose of this idea of “writing down everything” is that it will make you think more. Well, at least it works for me. When we are talking sometimes, we are saying what goes on in our heads without too much organisation. The organisation appears organical during the conversation. This doesn’t happen while you are writing. You need to think a little bit more to organise your ideas so you can be as clear as possible for the other people to understand you. This process of thinking will help you make more questions, possibly will produce better answers and most likely you will make better decisions.
New Issues
Following those ideas about communication, I wanted to present a new one, working with RFCs. RFCs stand for Request For Comments and are a great way to have a clear picture of what’s ahead and needs to be done. Usually, when someone has something to build it all starts with a plan. A plan about what should be made and how. Yes, I know, right now you are thinking something like “this guy is dreaming, we like to get our hands dirty fast and start coding”. Or even, “that’s not our model — we build fast to fail fast — in this modern/fast world”. Ok, all good points, but why not start to try to work with this RFCs mindset?
Something new appears, let’s think about it, we ask to our colleagues for feedback, and in the end maybe a good plan appear. Or even, maybe, after all we don’t have to do that thing for some reason that we weren’t seeing. Again, I know, you are all thinking that all of this sounds good but working with these RFCs will take time and even, should we do it all the time? Even for smaller things? And who reviews these RFCs, all the team? All good questions that I leave you to think and answer. You are the best person to see if all of this makes sense for you or not. I guess that all I wanted to leave here for you is that probably thinking first and deploying bugs later is a good idea 😄.
Dev + Test
I guess that this topic is an old one for every tech team. but I wanted to take the opportunity to talk a bit about it and say that we should write tests for what we develop to give a good coverage around what is done. As we know, tests are small pieces of code that cover a predefined set of combinations and use cases of our systems. We can have a very good code coverage with a lot of tests but still can’t say that our system doesn’t have any bugs. Still, it’s better to have some coverage than to not have any, right?! Let’s make sure that what we develop really does what it is supposed to do. Or even that our new code won’t break scenarios that we already assume that are correct. I guess that there are more advantages in doing it then not doing it but again, it will all depend on you and your organisation. This testing process will increase the time to make something live in production but at least we can have the minimum confidence on it.
When Production fails
This topic appears to following the ideas from the first two. Anything can happen in production, and we can see ourselves dealing with a problem that we have no clues about or is out of our comfort zone. Plus, with the pressure of having the system down or with an error that is impacting the business in a not very good way. We should try to minimise this from happening, but if it does (and I’m guessing that it will happen 😄), we should have some tools to help who is taking care of the problem. It will take some work, like everything, but in the end there will be tools that could help. Why not make use of the projects wikis and place there docs that describe how some core modules of your system works? Docs that describe where are the configurations, how to access data store and servers, and so on. I’m guessing that a lot of our systems have a lot to reason about. We should do our best to help our new colleagues by giving them the tools to be autonomous on handling incidents.
Another detail that I would like to describe here is a Postmortem culture. A postmortem is a written review of a problem that happened and usually it will give the reader details of what went wrong, what was done to fix it and, most important, what will be done to make sure that it will never happen again. I already saw some big companies doing this and from the perspective of who uses a service that went down is really good to read about what happened.
A Smart Team
This is an idea that states that we should work smart and not hard. That we should work as a team and not as individuals.
Usually, when we talk about working hard it means more about quantity than quality, that we are more focused on the short term output. But having continuously more work than we can handle will make us more and more tired. Our ability to produce creative work will reduce, and it will be hard to take time to improve things. Things like technical debt, attend to bugs and make improvements on our system will be pushed to the bottom of the list of things to do. So why don’t we make a stand and choose to work smart?! Fight for that extra time that will help us understand the root cause of a bug, replicate a issue with a test, take some time to understand what we’re going to do next. The idea is not to accomplish less but the opposite. Accomplish more with the time that we have ou even with less work. And to help even more you can count with your teammates. Again, we are always very focused on speed, developing features fast, so collaboration can be as hard as communication can be. But, with time, a team that is working for a while will be able to bypass most of the issues by having everyone aligned and aware of what’s going on to really understand what is needed before doing it, making it a smart team.
Well, that’s it. I hope that all of this was a good read. There is a lot of info around the web about these ideas, so you will not have problems getting more details. See you next time, take care and rock on! 👋
José Miguel Malaca
