<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Jorge Rodríguez</title>
    <description>The latest articles on DEV Community by Jorge Rodríguez (@jorgerdg).</description>
    <link>https://dev.to/jorgerdg</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F348239%2F3316f914-de26-4772-8791-04c967f5b5e5.jpeg</url>
      <title>DEV Community: Jorge Rodríguez</title>
      <link>https://dev.to/jorgerdg</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/jorgerdg"/>
    <language>en</language>
    <item>
      <title>Bugs will happen. Are you prepared?</title>
      <dc:creator>Jorge Rodríguez</dc:creator>
      <pubDate>Thu, 02 Jun 2022 11:02:02 +0000</pubDate>
      <link>https://dev.to/theagilemonkeys/bugs-will-happen-are-you-prepared-3m5g</link>
      <guid>https://dev.to/theagilemonkeys/bugs-will-happen-are-you-prepared-3m5g</guid>
      <description>&lt;p&gt;It's very common for developers (and managers!) to focus on new features, performance, or bug fixing when coding. But when a project is complex enough, there's a hard truth that we all must take into account: &lt;strong&gt;bugs will happen&lt;/strong&gt;. Period. I have never seen a new project go live without issues. In fact, I don't think I've ever seen a project stay bug-free in production for more than a month straight. Software engineering is imperfect, and &lt;strong&gt;our code must be prepared to deal with it&lt;/strong&gt;. This post is about what you can do to make life easier for you and your team.&lt;/p&gt;

&lt;p&gt;A couple of years ago, a bunch of us at &lt;strong&gt;The Agile Monkeys&lt;/strong&gt; started this huge project for a bank. We rebuilt a critical part of their system, with an &lt;strong&gt;event-driven architecture&lt;/strong&gt; that would be processing &lt;strong&gt;millions of monetary (and non-monetary) transactions daily&lt;/strong&gt;. The team did a fantastic job and it's still in production and working well to this day. However, &lt;strong&gt;it was not a bed of roses&lt;/strong&gt;. We faced some important challenges that I believe made us all much better developers today.&lt;/p&gt;

&lt;p&gt;As usual with any big project, there was a lot of &lt;strong&gt;technical learning&lt;/strong&gt; involved. From do's and don'ts in event-driven architectures, to communication both inside and across the teams. There were loads of lessons learned. But there was one huge takeaway that I took from the project. We dedicated &lt;strong&gt;way too much time&lt;/strong&gt; to code optimization, bug fixing, and new features. And we didn't work enough on &lt;strong&gt;defensive programming&lt;/strong&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  What's defensive programming?
&lt;/h2&gt;

&lt;p&gt;Quoting Wikipedia directly:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Defensive programming&lt;/strong&gt; is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. Defensive programming practices are often used where high availability, safety, or security is needed.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The emphasis here is on &lt;strong&gt;unforeseen circumstances&lt;/strong&gt;. &lt;em&gt;Bad Things™&lt;/em&gt; will happen, no matter what you do. So &lt;strong&gt;you have to prepare for them&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;At our first launch, we thought that we had a &lt;strong&gt;very robust application&lt;/strong&gt;. It was performant and well tested. But, again, &lt;em&gt;Bad Things™&lt;/em&gt; can and will happen. In our case, it was an &lt;strong&gt;unknown rate limitation&lt;/strong&gt; on our &lt;strong&gt;vendor production API&lt;/strong&gt; that temporarily shut our application account down. Then, even when our services had a retry mechanism in place, they all ended up retrying simultaneously. As a result, a large majority of our transactions &lt;strong&gt;failed&lt;/strong&gt;. Recovering from those errors required a lot of work from all of us. We were clearly &lt;strong&gt;not prepared enough for an issue at such a scale&lt;/strong&gt;. We found ourselves doing a lot of manual, tedious work to solve the transactions in pending status. It resulted in many hours of hard work, and it naturally grew into some &lt;strong&gt;automatic tooling for reconciliation&lt;/strong&gt;. Tooling that we should have implemented right away, instead of dedicating that much time to optimize performance, fixing bugs or even adding new features.&lt;/p&gt;

&lt;h2&gt;
  
  
  Reconciliation tooling
&lt;/h2&gt;

&lt;p&gt;In regards to the tooling that you should have in place, it will greatly depend on the needs of your system. But for an event-driven architecture like the one that we were working with, we found it incredibly useful to have an &lt;strong&gt;Admin API&lt;/strong&gt; (be careful with the security on this one!), with some automatic checks and reconciliation logic. The methods in this API would be able to replay events, look for inconsistent values in DB, or for the most extreme scenarios, even update some DB fields directly.&lt;/p&gt;

&lt;p&gt;That, combined with an &lt;strong&gt;event store&lt;/strong&gt; where every event received is kept (especially if not completed successfully), will allow your team to work wonders. It's important that the developers are able to &lt;strong&gt;safely and consistently replay the events&lt;/strong&gt;. One of the issues that we faced in our project was that, even though our log aggregator worked very well to grab event data, it was not &lt;strong&gt;consistent enough for our scale&lt;/strong&gt;. A small percentage (below 1%) of events were lost, but it equated to thousands of events that need to be manually searched for. Having a more complete and reliable event store for our needs was &lt;strong&gt;a huge relief&lt;/strong&gt; for our reconciliation process.&lt;/p&gt;

&lt;p&gt;There's another very good benefit that you'll get from all of this tooling: you can &lt;strong&gt;automatize those checks and processes to run periodically&lt;/strong&gt; once you've verified their robustness. For instance, you could run a reconciliation task daily on all of those events that failed or stalled for more than an hour. Once the tooling is in place, there are many advantages that you can enjoy!&lt;/p&gt;

&lt;p&gt;So, for every reader out there, I'll be proud if you can just carry home the following takeaway: &lt;strong&gt;bugs will happen. Are you prepared to deal with them in production?&lt;/strong&gt; If not, start dedicating some time to it, even before bug fixing or optimizing your code. Invest in a calm mind. Future &lt;em&gt;You&lt;/em&gt; will thank you when enjoying the spare time with your friends instead of dealing with on-call issues!&lt;/p&gt;

</description>
      <category>programming</category>
      <category>design</category>
      <category>devjournal</category>
      <category>eventdriven</category>
    </item>
    <item>
      <title>Coronavirus can be the perfect opportunity to embrace remote work</title>
      <dc:creator>Jorge Rodríguez</dc:creator>
      <pubDate>Fri, 13 Mar 2020 17:08:35 +0000</pubDate>
      <link>https://dev.to/theagilemonkeys/coronavirus-can-be-the-perfect-opportunity-to-embrace-remote-work-5999</link>
      <guid>https://dev.to/theagilemonkeys/coronavirus-can-be-the-perfect-opportunity-to-embrace-remote-work-5999</guid>
      <description>&lt;p&gt;At &lt;a href="http://theagilemonkeys.com"&gt;The Agile Monkeys&lt;/a&gt;, we’ve been working remotely for 10 years. From the start, the founders of the company always challenged every business convention that did not make any sense to us. Spending a lot of hours in an office was one of those. We always thought that &lt;strong&gt;is important to be able to work focused and at the time and place that you find more productive&lt;/strong&gt;. Working from home (or wherever you like) was a part of it. Now we see a lot of companies struggling to implement that philosophy, and chances are they’re struggling because they didn’t have the time or motivation to build a culture around it. Maybe the Coronavirus pandemic will help to change some misperceptions about remote working that we’ve been hearing for a very long time.&lt;/p&gt;

&lt;p&gt;It is very common to see companies getting paralyzed if their employees cannot get to the office. This is often seen when there is extreme weather or even major traffic jams. Companies seem to just accept that paralysis, probably because it does not happen frequently enough. But a lockdown of a couple of weeks? Well, &lt;strong&gt;that’s a different game&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;It is very easy to imagine why companies that embrace remote work have a competitive advantage. They &lt;strong&gt;will not stop working&lt;/strong&gt; just because their employees can’t go to the office. They will not be forced to negotiate to extend deadlines or contracts with providers or clients, because they will keep working at full throttle. This is the kind of thing that &lt;strong&gt;seems so obvious from the inside&lt;/strong&gt;. Yet the average company has typically refused to accept remote work.&lt;/p&gt;

&lt;p&gt;It turns out that sometimes this kind of crisis is the boost needed to force these changes in society. &lt;em&gt;Acme Corp.&lt;/em&gt; and the rest of the companies who are so proud of their open-plan offices will have to &lt;strong&gt;reconsider whether remote work is a good option for them&lt;/strong&gt;. If for no other reason, they will have to, because while they are on hold, their competitors will be able to go on with their work.&lt;/p&gt;

&lt;p&gt;It is true that not all jobs can be performed remotely, but it's also true that those would also benefit from a general shift to offsite work. Think of how traffic would be affected by removing all those commuters, not required physically anymore, from the roads. And I haven’t even mentioned &lt;strong&gt;the ecological benefits of such a decision&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;Unfortunately, establishing a remote work policy for a company is &lt;strong&gt;not as easy as sending a company-wide e-mail&lt;/strong&gt; (although that can be a good first step!). This kind of work requires the company and employees to think carefully about how they will alter their work habits. Everyone will need to &lt;strong&gt;change how they approach challenges and especially how communication and documentation are handled&lt;/strong&gt;. It won’t be possible to just stand up and go over to your workmate to ask them about how they dealt with an issue in the past. &lt;/p&gt;

&lt;p&gt;Often, that scenario is considered a drawback when remote work is being discussed. But what if we look at it from the other side? That workmate has just been saved from an interruption. Now multiply that by the number of times it happens in an average workday. &lt;strong&gt;That workmate is now perfectly able to focus on their work&lt;/strong&gt; and, once they feel like they can stop and attend to other matters, they’ll get to your question. Or even better, they might just share the solution as an internal document so that no one gets blocked waiting for them to respond. This is why &lt;strong&gt;asynchronous communication&lt;/strong&gt; works so well for remote environments.&lt;/p&gt;

&lt;p&gt;As offsite contractors, we have worked with several top-notch companies and institutions like eBay, Harvard University, Rent the Runway, Zara, and many others, always with a think-remote-first approach. And we know that &lt;strong&gt;working remotely has been one of our secret sauces&lt;/strong&gt;. When properly done, remote work can make you better: more productive, more efficient, happier, you name it. But to take advantage of it, you must start thinking as a &lt;em&gt;remoter&lt;/em&gt; because, suddenly, documentation and communication are key aspects of your organization. And it will pay off. &lt;/p&gt;

&lt;p&gt;From our beloved &lt;a href="http://www.hellocanaryislands.com/"&gt;Canary Islands&lt;/a&gt; in the Atlantic Ocean, we have been able to work while our clients suffered from extreme weather. Or power outages. We can also continue working even if transport or traffic blocks our clients on the way to their headquarters. And we will keep doing it if they are forced to stop working due to a lockdown. &lt;strong&gt;We will always be there&lt;/strong&gt;. And we hope the current worldwide difficulties will be the catalyst for other companies to experiment with remote work and discover its many business benefits.&lt;/p&gt;

</description>
      <category>coronavirus</category>
      <category>remote</category>
      <category>business</category>
      <category>development</category>
    </item>
  </channel>
</rss>
