Engineering

Bob: “Hey, what will we use to communicate with X in this project?” Ted: “We’re using library Y, of course! 5k stars at Github. Looks solid!” (5 months later…) Bob: “Ted, we have a problem. We need to update X and library Y does not have support for it.” Ted: “Hmmm… We could just monkey-patch Y and then create our own in-house version. Problem solved!” (and then it begins…) Dear CTO/VP of Engineering / Head of Development, please do not allow your team to do these kind of things. They are bad. They are bad for your software, for software, in general, and they will hurt your company, sooner or later. Why? You may think that this is the quickest way to solve the above stated problem, but let’s talk about what could happen: ...

Hi! This is my first post in this blog. Although it’s meant to be a tech blog, this post is the first part of a series where I mix software engineering, its practices and methodologies with a business background and why do software companies need to move towards continuous deployment. Stay tunned! Background and Motivation The world has changed a lot in the last 100 years. But if we stop to think about it, did it change more from 1900 until 1970 or from 1970 until now? Perhaps we could define the world evolution as an exponential function. Everyday we use the technology we know and innovate, creating new technology based upon the old one. This evolution pace is becoming faster and faster. It’s like the Moore’s Law applied in real life. Crazy. Given this, every (decent) businessman knows that his company needs to adapt fast to market changes. If you cannot deliver, your competitor in Australia, China, India, etc will do. If you cannot change fast enough, your competitors will eat you. ...