6 ms·

That's funny. I was the opposite. When I was younger, I would just say "lets default to other people's solution to similar problems and move on" but as time wen

by cheez 6y ago

That's funny. I was the opposite. When I was younger, I would just say "lets default to other people's solution to similar problems and move on" but as time went by, I've become more "let's define our problems well and find surgical solutions by others". It's a slight difference but makes a huge difference in productivity. Another way to say it is instead of taking someone else's blueprint, we build our own blueprint and use pre-fabricated parts to realize the blueprint. In the end, sometimes solutions look very similar but there is that one little bit that gives you a competitive advantage that no one else has.

iforgotpassword 6y ago
Agree. Interns or grads always want to throw whatever the most hyped tool in some domain currently is at every remotely fitting problem. Ansible all the things! That's not to say you should always roll your own. This is one of those things that's really hard to become good at: Decide early on whether to go with an existing solution or create something from scratch. (and if you go for an existing solution, which one?) There's many arguments for both sides, one thing often mentioned is that settling for some popular solution or framework will make it easier for others to get into your project, but if you bend over backwards to get three different tools to do what you want instead of writing a hundred lines of bash, you might be doing something wrong.
- cheez 6y ago
  What I do is decide that I am in charge of defining the machine, and the tools implement the machine. The tools are a means to an end. If the tools don't exist to implement the machine, I write them. If they do exist, great.
  - mcny 6y ago
    > That's funny. I was the opposite. When I was younger, I would just say "lets default to other people's solution to similar problems and move on" but as time went by, I've become more "let's define our problems well and find surgical solutions by others". It's a slight difference but makes a huge difference in productivity. I thought the same way except I was even more insane. I thought lets just teach everyone English and we won't have to do any internationalization/localization.
    - deleted 6y ago
      [deleted]
    - 908B64B197 6y ago
      But then you lose the advantage of being the first to localize for a given market! But seriously, in a lot of cases, translating and localizing is actually the easy part of internationalizing a business.
      - mcny 6y ago
        > But seriously, in a lot of cases, translating and localizing is actually the easy part of internationalizing a business. In my defence, I was not a very travelled child. I didn't even know about all the different kinds of power socket standards around the world.
mlyle 6y ago
> In the end, sometimes solutions look very similar but there is that one little bit that gives you a competitive advantage that no one else has. I'm all for doing something "different" if it gives you some kind of core competitive advantage. But the pain of being off the beaten path can really exceed small benefits you get in unexpected ways. Save real innovation and risk for the things that are core, unique to you, and possible sources of large competitive leverage. Be boring elsewhere, maybe with an occasional small sprinkle of something clever mixed in. Evangelize the small bits of cleverness, in hopes that someone else will start maintaining it. ;)
- cheez 6y ago
  I'm not sure if I'm misreading you, you're misreading me, or we're on the same page :-) Ideally, I map out workflow and find tools that fit the workflow in the Unix philosophy. Well-defined, do one thing well. As opposed to monoliths that purport to do everything. My experience has been that doing things in this way builds a system that is extremely robust to significant changes.
ta17711771 6y ago
> The fact is, the great tools that have achieved widespread adoption understand the problems, and all their caveats, better than you. Picking any established tool to manage information and workflow and getting good at using it will usually yield better results. The stagnated companies with questionable data analysis because they're looking at beautiful SAP or other ERP graphs that have been filled with incomplete data by their end users on awful interfaces would disagree...if they knew.
cratermoon 6y ago
Years ago I analyzed the build vs. buy question and came up with a rule that I later found to be not so original: buy for parity, build for competitive advantage. Most of any business is commodity stuff, typically things like HR, payroll, logistics, finance, security. Except if your business is one of those functions. Take Amazon's logistics for example. They aren't just any online retailer, they are the dominant online retailer in large part because they optimized the hell out of their logistics pipeline. But if it's not your bread-and-butter, then yeah, go ahead and change your workflow to whatever COTS software you pick requires. You'll be fine. I worked for an insurance company, and they picked PeopleWare for their HR system and used commodity software tools for their actuarials. I worked for a very large shoe company they has SAP at the core of their (extremely complex) product lifecycle management system because their real business differentiator is their design and marketing. That same insurance company had a customer sales pipeline tailored to a specific market – high-end professionals like doctors, lawyers, and similar – so they had custom software for that. That same shoe company had customized design and bill of materials systems so they could get their shoes to market quickly and globally.
- contingencies 6y ago
  Nice one. Added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
- cheez 6y ago
  You said it better than I ever could have!
  - cratermoon 6y ago
    I can't take credit for the phrase, only for being thoughtful enough in my early career to more-or-less work it out from first principles.
- jmole 6y ago
  I'd call it "rent for parity", not "buy". If all you have is a license, it's effectively a rental - not a purchase. Rent for parity, buy or build for competitive advantage.

by cheez 6y ago

iforgotpassword 6y ago

Agree. Interns or grads always want to throw whatever the most hyped tool in some domain currently is at every remotely fitting problem. Ansible all the things! That's not to say you should always roll your own. This is one of those things that's really hard to become good at: Decide early on whether to go with an existing solution or create something from scratch. (and if you go for an existing solution, which one?) There's many arguments for both sides, one thing often mentioned is that settling for some popular solution or framework will make it easier for others to get into your project, but if you bend over backwards to get three different tools to do what you want instead of writing a hundred lines of bash, you might be doing something wrong.

cheez 6y ago
What I do is decide that I am in charge of defining the machine, and the tools implement the machine. The tools are a means to an end. If the tools don't exist to implement the machine, I write them. If they do exist, great.
- mcny 6y ago
  > That's funny. I was the opposite. When I was younger, I would just say "lets default to other people's solution to similar problems and move on" but as time went by, I've become more "let's define our problems well and find surgical solutions by others". It's a slight difference but makes a huge difference in productivity. I thought the same way except I was even more insane. I thought lets just teach everyone English and we won't have to do any internationalization/localization.
  - deleted 6y ago
    [deleted]
  - 908B64B197 6y ago
    But then you lose the advantage of being the first to localize for a given market! But seriously, in a lot of cases, translating and localizing is actually the easy part of internationalizing a business.
    - mcny 6y ago
      > But seriously, in a lot of cases, translating and localizing is actually the easy part of internationalizing a business. In my defence, I was not a very travelled child. I didn't even know about all the different kinds of power socket standards around the world.

mlyle 6y ago

> In the end, sometimes solutions look very similar but there is that one little bit that gives you a competitive advantage that no one else has. I'm all for doing something "different" if it gives you some kind of core competitive advantage. But the pain of being off the beaten path can really exceed small benefits you get in unexpected ways. Save real innovation and risk for the things that are core, unique to you, and possible sources of large competitive leverage. Be boring elsewhere, maybe with an occasional small sprinkle of something clever mixed in. Evangelize the small bits of cleverness, in hopes that someone else will start maintaining it. ;)

cheez 6y ago
I'm not sure if I'm misreading you, you're misreading me, or we're on the same page :-) Ideally, I map out workflow and find tools that fit the workflow in the Unix philosophy. Well-defined, do one thing well. As opposed to monoliths that purport to do everything. My experience has been that doing things in this way builds a system that is extremely robust to significant changes.

ta17711771 6y ago

> The fact is, the great tools that have achieved widespread adoption understand the problems, and all their caveats, better than you. Picking any established tool to manage information and workflow and getting good at using it will usually yield better results. The stagnated companies with questionable data analysis because they're looking at beautiful SAP or other ERP graphs that have been filled with incomplete data by their end users on awful interfaces would disagree...if they knew.

cratermoon 6y ago

Years ago I analyzed the build vs. buy question and came up with a rule that I later found to be not so original: buy for parity, build for competitive advantage. Most of any business is commodity stuff, typically things like HR, payroll, logistics, finance, security. Except if your business is one of those functions. Take Amazon's logistics for example. They aren't just any online retailer, they are the dominant online retailer in large part because they optimized the hell out of their logistics pipeline. But if it's not your bread-and-butter, then yeah, go ahead and change your workflow to whatever COTS software you pick requires. You'll be fine. I worked for an insurance company, and they picked PeopleWare for their HR system and used commodity software tools for their actuarials. I worked for a very large shoe company they has SAP at the core of their (extremely complex) product lifecycle management system because their real business differentiator is their design and marketing. That same insurance company had a customer sales pipeline tailored to a specific market – high-end professionals like doctors, lawyers, and similar – so they had custom software for that. That same shoe company had customized design and bill of materials systems so they could get their shoes to market quickly and globally.

contingencies 6y ago
Nice one. Added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
cheez 6y ago
You said it better than I ever could have!
- cratermoon 6y ago
  I can't take credit for the phrase, only for being thoughtful enough in my early career to more-or-less work it out from first principles.
jmole 6y ago
I'd call it "rent for parity", not "buy". If all you have is a license, it's effectively a rental - not a purchase. Rent for parity, buy or build for competitive advantage.