Who didn't love when Jurassic Park hit in 1993? Hot damn if I didn't own that on VHS as soon as it came out. Velociraptors. T-Rexes. 3-D GUI Unix operating systems. It was the shit. There have been some downturns, but when Jurassic World came out with Chris Pratt in a leading role I couldn't pass it up. Clearly things had been taken to the next level and I needed to submit and enjoy. I saw it later than most and, despite reviews I heard, I thoroughly enjoyed it.
I love when humans try to control the uncontrollable and pay the price. If you're going to build a dinosaur park... I don't care how much effort you put into trying to control the dinosaurs... you are going to lose. There's something very gratifying for me watching these wannabe puppeteers suffer the T-Rex bite they genetically engineered, bred fierce, and sought to tame.
Software delivery is a vicious dinosaur. You start with an idea. So innocent, harmless, but requiring so much care and nurturing. You grow it gradually. It begins to require more and different kinds of care to keep progressing. As your little dino grows you realize that he's getting unruly and you need to build some safeguards into your system and delivery process. Maybe you need to add some tests, some automation. Before you're done with any of that... BAM a major bug hits. Your dino's fully formed teeth are capable of biting through the steel cable you engineered to keep him in. We'll introduce a stronger, higher gauge cable, AND let's electrify it.
Lather. Rinse. Repeat.
We all face significant challenges that we need to solve on behalf of our customers. There will be an endless string of problems that we run into along the way. We'll solve some of those by leveraging any combination of libraries, frameworks, and solutions - some well-known, some well-understood, some cutting edge, and some not well-understood.
You have options. More well-known technologies likely have a larger support base. They probably also have more and better documentation, and a community that is seeking and solving its problems. On the flip-side, technologies that are more well-known and understood may not be solving the latest problems, and maybe not in the most effective way.
Cutting edge technologies are likely solving or streamlining more problems, or more significant problems. They're a jump forward of sorts. Maybe you can solve the problem in far fewer lines of code. Maybe concurrency is simplified immensely. Maybe deployment and scalability become low-hanging fruit. Being a newer technology though, it is likely not as well-understood, possibly not as well-documented. Certainly the adoption level is lower, which means that community support is going to be lower.
The former might result in a more manageable, tamable stegosaurus. It's less rapid than other approaches, but consistent. Your stegosaurus is going to eat, sleep, and shit in a fairly predictable manner. It's not going to bite you, and any fires it may start will be manageable.
The latter might result in an unmanageable, unpredictable T-Rex. It's fast, vicious, and will bite your head off as soon as it gets the opportunity.
Remember when Dr. Grant and the kids were running through the field as a flock of dinos ran past them?
These guys seem reasonable. Extremes are rarely the right answer. Maybe a Gallimimus software delivery pipeline is a proper middle ground?
Whether you realize it or not, you own the characteristics of your delivery pipeline. The series of choices you made since the inception of your idea created your pipeline. It's not done though. You are constantly adjusting and molding it.
Investing in change... in new and valuable technology is important. After all, who doesn't want to avoid solving solved problems, and leap forward? But, we must treat it as an investment. If it's the right business decision do it, but do it intelligently. Don't take on a conversion or technological change expecting stegosaurus-like outcomes. You might have a raptor on your hands. You have no business taking on a change like this without an investment in understanding the ways that it can bite you and accounting for those. If you think you're going to convert from a COBOL stack to a Java stack, a .NET stack to a Scala stack, an on-prem stack to a cloud stack, or any other kind of major conversion, expect unpredictability. Likewise, don't breed a T-Rex / velociraptor hybrid without expecting some casualties.
As you move forward make intentional decisions about the state of your pipeline. Consider:
Maybe the right thing for your organization is to engineer your own dinosaur. But mayyyybe not an Indominus Rex. Maybe a stegoraptor though?
I love when humans try to control the uncontrollable and pay the price. If you're going to build a dinosaur park... I don't care how much effort you put into trying to control the dinosaurs... you are going to lose. There's something very gratifying for me watching these wannabe puppeteers suffer the T-Rex bite they genetically engineered, bred fierce, and sought to tame.
Software delivery is a vicious dinosaur. You start with an idea. So innocent, harmless, but requiring so much care and nurturing. You grow it gradually. It begins to require more and different kinds of care to keep progressing. As your little dino grows you realize that he's getting unruly and you need to build some safeguards into your system and delivery process. Maybe you need to add some tests, some automation. Before you're done with any of that... BAM a major bug hits. Your dino's fully formed teeth are capable of biting through the steel cable you engineered to keep him in. We'll introduce a stronger, higher gauge cable, AND let's electrify it.
Lather. Rinse. Repeat.
We all face significant challenges that we need to solve on behalf of our customers. There will be an endless string of problems that we run into along the way. We'll solve some of those by leveraging any combination of libraries, frameworks, and solutions - some well-known, some well-understood, some cutting edge, and some not well-understood.
You have options. More well-known technologies likely have a larger support base. They probably also have more and better documentation, and a community that is seeking and solving its problems. On the flip-side, technologies that are more well-known and understood may not be solving the latest problems, and maybe not in the most effective way.
Cutting edge technologies are likely solving or streamlining more problems, or more significant problems. They're a jump forward of sorts. Maybe you can solve the problem in far fewer lines of code. Maybe concurrency is simplified immensely. Maybe deployment and scalability become low-hanging fruit. Being a newer technology though, it is likely not as well-understood, possibly not as well-documented. Certainly the adoption level is lower, which means that community support is going to be lower.
The former might result in a more manageable, tamable stegosaurus. It's less rapid than other approaches, but consistent. Your stegosaurus is going to eat, sleep, and shit in a fairly predictable manner. It's not going to bite you, and any fires it may start will be manageable.
The latter might result in an unmanageable, unpredictable T-Rex. It's fast, vicious, and will bite your head off as soon as it gets the opportunity.
Remember when Dr. Grant and the kids were running through the field as a flock of dinos ran past them?
These guys seem reasonable. Extremes are rarely the right answer. Maybe a Gallimimus software delivery pipeline is a proper middle ground?
Whether you realize it or not, you own the characteristics of your delivery pipeline. The series of choices you made since the inception of your idea created your pipeline. It's not done though. You are constantly adjusting and molding it.
Investing in change... in new and valuable technology is important. After all, who doesn't want to avoid solving solved problems, and leap forward? But, we must treat it as an investment. If it's the right business decision do it, but do it intelligently. Don't take on a conversion or technological change expecting stegosaurus-like outcomes. You might have a raptor on your hands. You have no business taking on a change like this without an investment in understanding the ways that it can bite you and accounting for those. If you think you're going to convert from a COBOL stack to a Java stack, a .NET stack to a Scala stack, an on-prem stack to a cloud stack, or any other kind of major conversion, expect unpredictability. Likewise, don't breed a T-Rex / velociraptor hybrid without expecting some casualties.
As you move forward make intentional decisions about the state of your pipeline. Consider:
- Your current state
- The relative newness of the thing you're evaluating. Is it well-known and understood?
- The learning level and talent of your engineering organization
- The trust level your management team has for your engineering organization
Maybe the right thing for your organization is to engineer your own dinosaur. But mayyyybe not an Indominus Rex. Maybe a stegoraptor though?
