Diego Pacheco Tech blog

  In the paper, almost all companies have an SDLC(Software Development Lifecycle), which nowadays is a form of Scrum and Safe. I know Governance is often a bad word and is attached to bad practices and dated methods. However, at Scale, software needs to be managed. Complexity needs to be managed down. Lifecycle matters because it allows you to execute the right strategy and take the most out of your software assets. When you have hundreds of tousands of services, things get out of control. It takes a lot of work to keep track of what's going on. I'm a big fan of explicit comunication about the state of affairs. For instance, Netflix has the OSSMETADATA file in the github telling the lifecycle moment of the service/lib. This might sound silly but it is actually pretty powerful because you can communicate the company's intentions toward that piece of software and execute the right strategy. I believe that having a clear map of your services is a great tool for prioritization

  Professional players spend a great part of their careers on training. A top football performer for sure will spend 4-6 hours per week in training. Why, as engineers we dont practice? Yes, perhaps we go to university and get a degree, but what happens after that? Many engineers need to get used to doing POCs(Proof of Concepts) on their own time, or read books or writing down thoughts in the form of blogs, or simply organizing ideas in the form of diagrams and presentations. IMHO this is a big mistake, especially in the critical times we live in where there is a pandemic, recession, war, and things are difficult all around the globe. Over my career in software, I never stop learning. I dare to say that software engineering is not about typing but learning. Learning is the bottleneck; learning is the gap. Learning is a key skill that modern and well-rounded engineers must have. You can do many things, simple things that can start small but, with discipline and repetition, will pay off g

Code review it's standard practice. Most of the industry does this via some git-based tool like Github, Gitlab, or any other flavor. These tools are based on deltas or diffs. They are really good for spotting what changed, so you can get that single character who would give you a big headache. When I started working with software, there was no git; people were using CVS in the best case when code was not being versioned in a folder with the sufix backup. I learned to do code reviews without any Delta tool. However, any CVS tool would have a diff capability there. IMHO Deltas are not enough nowadays, dont get me wrong, they are useful, but they have several gaps and issues. I'm not trying to blame the tools or to start any rant or say that CVS is better than Git, which it is not. I simply want to take a different perspective on reviews.

Have you ever thought about how to evaluate software? Outside of the context of Build vs Buy - Sounds like a crazy question, right? Well, the reality is that at scale, you must do more than just refactor everything for the sake of refactoring. Re-writes, Refactorings, and Re-Architect need to be opportunistic and deliver real value to the business. So if it's pretty hard to refactor everything, how to approach software at scale? Some rationalization of the state of affairs is important. Rationalization leads to proper prioritization paired with a good execution can be a powerful tool to deliver change and improve quality. First, the question might sound a bit overwhelming and difficult, but when you start diving deep, you realize what makes sense and what dont, and some shapes emerge. So before I go too deep into this matter, let's start with a simple question - why evaluate software? Why Evaluate software? Besides the context of Build vs Buy - There are plenty of reasons to ev