I noticed recently that whenever I'm trying to find a solution to a problem, I feel as if I can tell I'm going in the right direction by the amount of obstacles I run into while solving. I'm not suggesting I've found my internal compass for coming to good solutions, nor am I suggestions that my solutions are the best. Far from it.
Whenever there's a technical issue with a problem I'm tackling, my first and only thought is, "I can't be the only one to have ever come across this problem before." And then I ask the Google who has conquered this hill already, and it tells me that some user on StackOverflow.com happens to have done this exact thing. Hopefully. This single guiding thought is what gets me through most days.
And sometimes, it's not so easy to find someone facing your particular issue. I've actually met teams whose technical hubris is so great that they believe their personal genius is indicated by the fact that no one has solved their problem. That they are a unique flower solving problems in the most awesome way. So often, however, it's because they've gone so far off the beaten path that they can find no one else in their situation to help them.
Let me talk through a hypothetical:
I have a web site I've built. I need to get it deployed to a place where someone can see it. I could manually build the solution, and copy the files to a server. That's easy. But then I start deploying more often. And because I want to push changes so frequently, I end up spending a larger percentage of my time deploying instead of delivering business value.
So I have a couple options. I can either grab a COTS (Commercial, Off-The-Shelf) solution that can build and deploy my software, or I could write a batch file that does a dos xcopy and be done with it. There's a learning curve associated with the former solution, and almost none for the latter, so I go for the xcopy script.
Now I'm a couple years down the road. I never wanted to take on the learning curve of TFS or Team City or Octopus or any of the other build/deploy solutions there were out there. It doesn't take long, except now I might have four environments across many different products. What was one xcopy batch file has grown to many nicely refactored batch files, and the parameters passed in correctly build and deploy my solutions across my enterprise.
All I've done is spent the cost of learning and purchase of the COTS system over a much longer period of time. And who knows, maybe because it does what I want and only what I want, I've done it for cheaper. And it works. What's wrong with that?
Well, nothing really. Except you've committed to this solution, and every time something new comes up, it's a new problem that has to be solved. Need to deal with restarting application pools, services, change configs, it's a new problem. You have to spend time figuring out how it works in your framework. When anyone new joins the team, there's a non-trivial learning curve to it.
Now let's rewind time and take the other path:
Say at that critical juncture, I went with a COTS solution. When I need to do something new, because there's a larger body of people using the same solution, the likelihood that any particular problem you face has been solved goes way up. With communities like StackOverflow out there, it's easy to find the information you need. Not how to cobble a solution together from duct tape and baling wire, but to leverage the tool in the ways it was intended.
So with my home-grown solution, every problem I have compounds, and it gets harder to find a solution to my singular little problem. Every patch to my system becomes hand-crafted. And involving anyone else to aid gets harder. With the COTS solution, every time I need an answer, there's more likely to be someone that's already solved my problem.
This is not to argue for build/deploy systems, or make a case for buy vs. build. This discussion is only to illustrate the point: one way of knowing you're on the right track is when answers to your questions get easier and easier, not harder and harder. This whole concept seems to be related to the Pit of Success, or even Stacking Functions, but that's a discussion for another day.
Also, I want to point out that these arguments all go out the window if you're intentionally trying to innovate. For lots of solutions, including build/deploy, that's probably not you. If you're writing a bunch of custom devops tools to work around your solutions, for instance, that can be a smell that you're not going in the right direction. If you are a small company who wants to build the best new build/deploy system out there, however, then being off the beaten path may be a sign that you're going in the right direction.
I've often heard it said, "buy commodity, build competitive advantage." This advice is intertwined, I think. If you're working on commodity problems, pick up commodity solutions so the answers are out there. Save your energy to innovate on the tough problems your business faces. They truly need you, and they trust you to make these decisions.
No comments:
Post a Comment