Diego Pacheco Tech blog

Everybody is familiar with the concept of technical debt. Some people might refer to it using different metaphors, Fowler calls it cruft , Allan Kelly call it a liability . I personally prefer Kelly's definition. No matter what metaphor we use, technical debt is a reality in all industries. Technical debt is everywhere.  Not all technical debt is created equal. Some problems are worse than others; for instance, if we have 6 lines of duplicate ifs inside a single method or function, it's not as bad as a distributed monolith. Have you ever tought about what's the norm? Do you think technical debt is the exception, the anomaly? Or do you think technical debt is the norm and happens by default? We will go back to this question later. I believe it's impossible to avoid technical debt. IF you think about it, let's say you have the perfect team and the talent. It's amazing; all your team members have 20+ of experience, in the same industry and have been working togeth...

Have you ever wondered if what you build has the right impact on the customers? Engineering is often demanded to be on time and cost-effective.  Bugs and incidents are known for disrupting the customer experience. Less bugs, the better; fewer incidents, the better. So when do we reduce bugs and incidents? Devops has an interesting practice called Blameless Incident Reviews  (BIR). Considering the devops culture and movement, blameless incident reviews are great because they drive the right culture shift from feat and blame to sharing and understanding. BIR is often pull-based, which happens when we have a number of production bugs that are worth sharing and driving lessons learned to the whole org. Devops is all about better ways of building and operating software. We cannot do better if we are stuck with the same practices all the time; practices need to be changing and evolving and a way to keep us fresh and learning at all times.

  Shape up is the new Basecamp book(former 37 signals). It's about product discovery. A book is a form or flavor of Dual Track agile . Is pretty interesting because it also blends with some Lean Startup ideas. 37signals/Basecamp was always an interesting company since they did not fit on the classical enterprise-like company neither typical silicon valley company. The books are often culture-heavy and show how they do business. This book is about product development, Discovery, Dual-Track agile, and a different way to manage scope. Basecamp explores the flexibility of Scope which to give them credit not often is explored. The book also shows obvious XP reference by tracking progress with Big visible charts and using lots of visuals to avoid heavy unrealistic planning. ShapeUp is cool but we also need to keep in mind they have executive buy-in since they literally run the company and do not rely on VC/Seed money, so this gives them the ultimate flexibility. Today I made a slide ca...

Agile is a wasteland . Don't believe me? Read Kent's Beck(Creator of Extreme Programing) article . IMHO Agile has been in decay since 2013. However, Agile become mainstream since 2000; in Brazil, agile become mainstream in 2015, more or less. Success means misuse. The demand for agile is very high in some countries like Brazil and quite inexistent in Europe and the USA(mainly Silicon valley). Scrum has often sold dogma and easy answers with easy certifications. Scrum is really a big part of agile being mainstrain and also why it is such a shit show. There is so much demand in some places and literally very few people who really understand the software and digital products which greats a very complicated enviroment. So having said that, should we drop agile completely? Well, in some sense, yes. Things we just do because of Dogma and we dont understand and really dont add value should be dropped 100%. However, would all problems just go away? 

  So if you read my previous post , I saw saying that for Platform / DevOps you dont want to have 1 single team but several small teams actually. However, when we are talking about Product Teams I believe we need to go the other way around. Could we have small teams in the product and yet be a good thing? Well depends. IF the Product teams are completely autonomous and selling their own product or completely independent module in sense of the business (Meaning autonomy is a business construct). Well for that case yes, have smaller and more teams will make sense however in practice what happens is the other way around. What happens is that many small product teams tend to create small microservices with have dependencies on each other and at scale, it becomes more problem they benefit. In order words, business verticals or bigger scoped SOA Services would make much more sense and also would fix several problems that small services at scale tend to create. If you want to know more ab...

Estimates and a very huge concern for pretty much company doing business now a day. Especially during COVID-19 times I dont belive the questions like when something will be done will be out of the table soon.  However, is very hard to get estimates right but is possible to take action to reduce the blast radius of estimates and try to get something reasonable.  Today I want to share a short video I recorded some thoughts on estimates. If you are following up muy blog you will see these ideas were published in previous posts if you did not read my latest posts on similar matters you can read it here: 1 , 2 , 3 , 4 , 5 , 6 , 7  and 8 . In this video, you will see why estimates often go south and what we can do to improve and deal with estimates in a reasonable way.

Observability is a must-have a property any mature distributed system solution and/or digital product.  There is no way to "buy" observability, you need to earn it. Observability is like car insurance. No one likes to pay insurance, however, if there is a care crash you do really really want it. However, you cannot acquire the insurance at the very moment of the crash it does not work that one. The car insurance metaphor would work partially If you have a monolith system. As you have microservices, therefore distributed systems, you have many more failure points and in order to detect that the "car crashed" could be much more hard and complicated. There are many challenges in order to have observability on the system. The main idea is that Observability is something LIVE which means it is not a one time job. So you want to have a better understanding of your system via instrumentation which will lead to better observability and this loop keep going. Some time abou...

Peter Drucker once said, "Culture eats strategy for breackfast". Technology is a very awkward field. In theory, we came from Math, science thinking should be our default mindset but we are far from it. We need science more than ever, as a society we are living a pandemic crisis, for sure will lead to some sorta ice age economical period who not only is never saw at this scale but also nobody can tell for sure what will happen. So yes, we need science because of the need for a COVID-19 vaccine and cure but we also need that in Software Engineering and Digital products. For some reason we are losing the basics, we are losing how to build software properly. Mostly because people don't understand how technology should work. Deming, one of the founding fathers of Lean once said Second-grade teacher creates second-grade students.  Crises times are often tough and difficult but for sure there are opportunities not only to improve things but also to re-think what we are doing...

Agile is +20 years old. Most of the companies did not get it. I'm glad to see the several new UX movements are getting it and are producing some amazing books, not limited to UX but in the helm of digital products and discovery like: Sense & Respond , Outcomes Over Output , The Hard Things about Hard Things  and Traction . I read all these books and really recommend you read it too. So the big fight that agile started and Digital Products / Discovery carry on is, stop focusing in Features make sure you understand your customer and deliver real value. Deliver value is not easy and still something everybody talks but feel know how to do it. The difference between a successful startup and a failed one is the ability to execute well knowing their customer and making products they love. I made some previous posts in regards to other forms of value I recommend you check it out here and here . In order to deliver the value, we need to focus on outcomes and stop focusing on output...

This is a complicated matter. Every single company on the planet deal with estimates somehow and use some kind of estimates. There are people who are pro-estimate and belive giving an estimate is a professional thing and we need to do it and there are people who believe we need to reduce the number of estimates we do(I'm the second kind of people). Estimates often are wrong and incorrect. However, there are people who are really good on the estimate and get it right with very few error margins however when you look into details you might realize that being good on estimates might be killing your business. You might think is enabling you to sell more and get better but easily it could be the other way around, no worries I will answer why. This is a very hot and passionate topic so brace your self and let's go. Estimates are old, most of the time they are lies and they are not reliable however we continue to work with estimates expecting they will work when they dont work.

Organizations need Lean more than ever. IT became a huge waste factory. Software scale works backward, the more money you throw in, the bigger the project the bigger your risk and bigger the waste you have. The technology work backward because If you think about Milk, the bigger the scale the cheap is the price. I was wondering how did we get into the position we are. Tech debt does not describe debt anymore, we are dealing with a totally bigger order of magnitude scale of debt. Tech debt can be big but I'm talking something beyond big. Maybe at the scale that some governments have debts with the  IMF . Why did we go south without noticing? I have some theories. Technology is like a time bomb, companies might start breaking because of it at some point. The debt become so high that multiple 3-5 years of investments might not be able to pay then off and business might start failing because of the bad technology practices. You might think I'm crazy. Because of business operates ...

The "analyst" is a very old role. I really think the tradicional role does not make sense anymore, we should see analyst as a discipline/skillset and not as a role. If the last 20 years of software engineer teach us something is that engineers are in the best position to work on proper solutions, however, someone needs to worry and focus on the business problem. IF you are in an Engineering Organization, engineers are great as POS / BAS but if you are dealing with delivery discipline and working with non-it people, engineers might not have the best set of skills to do the business analyst part. However, there are many things BAs and even Designers(UX) can learn from engineers. For this blog post, I will like to focus on the skills and the transformation BAs need to face today to keep up with current market needs, innovation and competition in order to be ahead of the game.

First of all, I want to explain why I added a puzzle as an image for this post. This is a metaphor I'm using with several people I work. People sometimes get lost and cannot keep with modern software initiatives. Well, agile is saying that for ages and people still don't get it. There is a huge difference between Simple and Complex systems. More and more making a digital product is from far to be a simple task. However, we still want answers that we cannot get. Sometimes this creates anxiety and we need to learn how to deal with failures, chaos, bad feedback and even that our solution my suck. Ouch thats very dark, right? No, not really, this is the reality, the REAL WORLD is a cruel place and ADULTS need to call tough decisions every day. So what's the deal with simple linear systems? well they imply that quickly you can understand what you are doing and make predictions about the outcomes. Well, digital products are not like that, we cant make predictions on simple line...

Product culture and mindset is one of the most important shifts enterprise companies need to go through. Project mindset has several flaws and yet we still follow it and thats need to change.  Project culture makes us focus on the wrong outcome like Dates, Escope, Feature, Cost instead of value and User Obsession. Since 2014 I follow Allan kelly work and read his books and saw several of his videos. I also exchange some emails with him back on the days. I was amazed how makes sense to back into 2014. Even almost 5 years passed and companies still don't get it. There are other movements that push to the same direction as NoEstimates , Beyond Budget ,  OKRs , Modern Agile ,  LeanStartUp . All these movements / Books have great synergy and they basically make you thing software development in a completely different way.