Hello everybody, welcome back to TNT. My name is Hobbs, this is a vlog where we talk about best practices in the data world.
We’re going to be talking today about a little story from my own life and one of the best practices that involves which things you should make yourself.
Welcome back everybody, as I promised, a little story about me. So, I’ve had some trouble with my basement for the last year or two. And I was talking with my dad about it and we were talking about different ways we could go about fixing it, the basement floods. So, he said, and I’ve never forgotten this, he said ‘There’s always two ways to fix things. There’s DIY and there’s PAP.’ And I of course asked probably the same thing you’re thinking which is, what on earth is PAP? And he said, it’s Point and Pay. You find someone else who is good at this problem and you [point and] say fix it. And then they come in and they fix it.
And I see this struggle, this back and forth push, with different clients that I interact with. About whether or not they need a custom-made solution that they could build themselves, possibly for much cheaper, or whether or not they bring in an expert and get someone else to come in. Or, in some instances, using prepackaged software rather than writing their own.
Now, I don’t want to step on any toes, but I think that there is a lot of value to the PAP approach. To taking something where someone else has already gone out and they’ve forged through the jungle, they have found the pit holes, they have scared away the tigers, they have stepped on the snakes, they’ve done all of this stuff and they have arrived at what solves 95% maybe 99% of the average users problems. Rather than saying here’s my unique scenario and I’m going to design a tool set specifically for my scenario. Usually if you take that DIY approach, you’re going to get a tool which solves 100% of what you want [but] at the cost of an immense amount of time dedicated and lots of hours poured in. And then the maintenance, keeping people on staff who can maintain this custom-made application or tool. These are sort of the costs that I see with the DIY approach.
So my advice to you: where you can, steal mercilessly. Here’s what I mean by that. The internet is full of people who have solved problems. And many of those tools are available to you. Don’t reinvent the wheel, don’t go out and do it yourself. Especially once you start talking about large enterprise-ready systems, where you’re pushing things out into production. Find someone who has solved the problem, who is an expert, and borrow their advice. Use the tools that they suggest. Go out to the people of the world who have done the thing and learn from them and bring back that wealth of knowledge [from] those explorers who have gone ahead of you, and use the tools and the systems that they suggest.
One very specific example: I work in Power BI quite a bit and I was trying to figure out how to trouble shoot a Power BI model that was working very inefficiently. And so I was thinking about it and I was thinking about writing this custom application to come in and pull out that SSAS cube that lives in the background in of all of these things and then I discovered that low and behold this group of brilliant, brilliant, wonderful human beings had built the vert of hack analyzer. And all you do is you plop it down and you point it at the thing you want and it does the thing that you want it to do. And all of this information, they had solved all of the problems that I cared about.
To summarize, you’re going to be faced with choices. Everyone has to balance their books and you’ve got your own budget and you’re going to have to deal with that. In those scenarios though those are my two pieces of advice, wherever you can, find experts out there on the internet and learn from them. Bring in a consultant if you have to but go out and find someone who has forged the path ahead of you. And second I really do believe that it is worth paying the cost to use a pre-made tool rather than trying to build one yourself both in time savings and in staffing costs down the road.
I hope this was helpful for you and I realize I’m knocking the hornets’ nest when I talk about this because people like to do things themselves. Especially developers, they like to solve their own problems. So if you’ve got feedback, if you think I’m wrong, by all means post a comment below. I would love to hear from you. And if you’ve got a topic you want me to discuss, I’m happy to do that as well.
If you need some expert advice [on your data projects], we would love to talk to you about that and see how we can partner together.
Hope you guys have a great week.