9 ms·

When I was a young, opinionated software professional, I would have agreed with this wholeheartedly. But now that I'm nearly a couple of decades into my career,

When I was a young, opinionated software professional, I would have agreed with this wholeheartedly. But now that I'm nearly a couple of decades into my career, I've seen 1000 different workflows justified by "we're different, we're unique". And if you ask how they're different so that they'd need a unique process to manage bugs, to manage invoices, to manage inventory, you get pretty much the same answers across the board. You hear about personalities and power structures and anecdotal preferences. And sure enough, that's exactly what you see at the link: Each person’s mind works a little differently, and each person remembers and processes information a little differently. Yes, you're unique. Just like everybody else. 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 search for the perfect tool or the perfect workflow or the perfect process always ends up being the enemy of good.

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.
tootie 6y ago
It's more true now than it used to be. A lot of business software in the early days was an attempt to directly replicate paper business process on a screen. Enterprise software was sold as being low friction and not requiring users to learn anything new. And it was built by developers who started with a data model and then build screens to match. I think we've finally tipped to the point that business processes are designed as digital first. The current gen is also following much more user-centered design.
- cratermoon 6y ago
  You're absolutely correct: business processes are changing rapidly in a way that they haven't since the assembly line and Taylorism. We've had decades now of users and companies "paving the cartpath" by replicating paper on screen and learning what translates, what doesn't translate, and how to evolve. The workflows and the tools are evolving together now through a feeback loop, and that's a good thing. Consider order fulfillment and shipping for small to medium businesses today compared to the era before FedEx and eCommerce.
edgarvaldes 6y ago
Yes. Just see any ERP implementation. Its better to take as many defaults as possible and go live, than spend years trying to implement your own convoluted unique workflow.
- Aeolun 6y ago
  That’s generally because the ‘own workflow’ is insane in the first place (10s of years of managers adding their own crazy conditions).
koonsolo 6y ago
Good explanation! These companies start out thinking they will make a better product than anything out there. But due to limited resources always end up with an ugly monstrosity that is hell to work with. So they end up with something more expensive (but that cost is hidden), and something worse than what's off the shelve. I always ask them "So are we the only company in the world that is developing software?". Tools are pretty powerful, so you build your process around them.
ish 6y ago
I ask clients (and myself quite frankly): what is the competitive advantage of doing it this way? Do you get a leg up on your competition? What's the opportunity cost of spending time and money on this instead of your core product or mission?
momokoko 6y ago
Process is a crutch for bad management. If you are constantly moving from process to process because they aren’t working, you likely need to replace a significant portion of the management team. Almost all processes work well enough. And there is nothing wrong with trying to find an optimum one. But process is not the solution. Quality management talent is.
- contingencies 6y ago
  I cultivated an extreme dislike for managers for years. Then I became one. Things are a whole lot different from the other side. You perhaps overlook a few things: (1) Managers are people too. They make mistakes. They should be able to recognize and correct them as others. Ideally quickly, transparently and with the insights of others. (2) Needs evolve. The right process for proof of concept R&D is not the right process for global domination with a mature product. (3) Management is about competing concerns. Often a decision must be made within a limited sphere of experience, time and resources and reviewed in the future. There is no 'right' decision, and it can be fiendishly difficult to quantify decision quality in many such circumstances without the benefit of hindsight. (4) Different people can respond very differently to the same management, so 'bad management' is perhaps too uni-dimensional a notion to hold much meaning.
  - momokoko 6y ago
    I never said managers where bad or that I disliked them. Sorry you got that impression. In this case all I was referencing was that frequent process changes and repeated failures of process are typically an indication that a change needs to happen in management not process. No where did I state management be eliminated altogether. I stated that better managers need to be brought in to replace those that are underperforming.
    - contingencies 6y ago
      Cool yep. Process change costs real money too ... observe the ETL phenomenon as an example. perl dies hard.
jariel 6y ago
"the great tools that have achieved widespread adoption understand the problems, and all their caveats, better than you" Tools that get widespread adoption are mostly those that move quickly to add every little feature every manager/exec asks for in order to secure the contract. Once they become incumbent, they become the standard, because managers are responsible for the 'big purchases'. There's tons of very accepted systems that are 'not very good'.
agumonkey 6y ago
I also wonder if there's some twisted emotional flow in people to consider whatever hell they conquered as the way to go forever. Questioning their ways is seen as such an insult there must be something deeply wound in their brain.
abhgh 6y ago
I agree with you, in the context of working in a corporation. It's not a bad thing to pick tools and structure your workflows around them, because sometimes such tools serve as 'mental anchors' for standardizing a process. The article seems to focus on personal productivity tools, for which the author's conclusion might relatively hold to a fair extent.
starfallg 6y ago
Spot on. Some things just need to be good enough. Spend effort on solving the problems with the biggest impact, your workflow and tools don't deserve that much attention unless it's completely not fit for purpose. Also changing your process and tools too often and too drastically usually makes things worse. People spend all their time keeping up with changes to how things are done as opposed to actually doing things.
Konohamaru 6y ago
How unique are people? You take a bunch of teenagers, ask them to non-conform, and they all come up with the same pierced, hair-dyed fashion. As if they're clocks ticking at the same rate. If you have several million clocks reading the same time down to the microsecond, that implies the existence of a master clock they were synchronized to.
zmmmmm 6y ago
I think you need to distinguish here between "core business" where you generate your competitive advantage, and everything else. In your core business, were you are going to make the critical difference that determines why your business or organisation exists, shooting for the most finely tuned, unique solution that maximizes that advantage - or at least, enables capability to do that - is critical. For everything else - I agree. The more bespoke you decide to be the more pain you create for very little value.
dllthomas 6y ago
There's a story about early fighter planes... searches a bit... this seems to be the one, although I've not read this exact version: https://www.thestar.com/news/insight/2016/01/16/when-us-air-force-discovered-the-flaw-of-averages.html https://www.thestar.com/news/insight/2016/01/16/when-us-air-... The military was ordering planes designed for the average pilot. But because there are so many dimensions along which someone can vary, most people are far from the average on some dimension, and when SHF and they need to be able to reach the right thing at just the right time, sometimes they couldn't. Each pilot is unique, just like every other pilot. Accommodating that proved important. Now... how well does that translate to building software? I can certainly see reasons why it wouldn't. But I don't see an argument that wouldn't apply to the planes as well, without actually measuring things.
- donw 6y ago
  > Now... how well does that translate to building software? Well, let's dig on on what the Air Force ended up doing, overall. First, they studied and improved the ergonomics. Specifically, making things like seats adjustable. The tool became more adaptable for a wider range of pilots. At the same time, there is a limit to how far that can go, especially when we are looking at 1940s technology. The Air Force thus imposed body-size standards for pilots -- 5'4" to 6'5" is a wide range, but it excludes outliers. Too short, too tall, too wide, or too heavy, and you couldn't be a pilot. My Dad was in that category -- too big to fly his dream plane. Controls were adapted so that unique functions had unique hand-feels. Flaps had a different shape of control than landing gear, and all of that was standardized across aircraft. So what does that tell us about workflows for engineers? Well, we can say firmly that physical ergonomics matter. Bigly. Uncomfortable seats, poor-quality monitors, high-latency or slow network connections... all of those are deal-breakers. But in terms of things like process and practices... standardize what you can, give everybody a sane baseline from which to work, and then empower them to customize as much as possible for their team or group. At the end of the day, software is shipped by teams. There's this odd, pervasive myth of the Morlock and Eloi in the software world. E.g., that engineers are either beautiful artisans in designer specs to which every whim must be catered, or that you just need to shove a pizza under the door every couple of days and production code will then appear on your servers. Don't open the door, though. None of that is reality. And to work in a team, you get to surrender some of your personal work-autonomy, in order to leverage the cognitive multiplier effect.
w_t_payne 6y ago
Unix had it right. Provide a toolbox with modular legos that you can customise and fit together to make the tools that you need.

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.

tootie 6y ago

It's more true now than it used to be. A lot of business software in the early days was an attempt to directly replicate paper business process on a screen. Enterprise software was sold as being low friction and not requiring users to learn anything new. And it was built by developers who started with a data model and then build screens to match. I think we've finally tipped to the point that business processes are designed as digital first. The current gen is also following much more user-centered design.

cratermoon 6y ago
You're absolutely correct: business processes are changing rapidly in a way that they haven't since the assembly line and Taylorism. We've had decades now of users and companies "paving the cartpath" by replicating paper on screen and learning what translates, what doesn't translate, and how to evolve. The workflows and the tools are evolving together now through a feeback loop, and that's a good thing. Consider order fulfillment and shipping for small to medium businesses today compared to the era before FedEx and eCommerce.

edgarvaldes 6y ago

Yes. Just see any ERP implementation. Its better to take as many defaults as possible and go live, than spend years trying to implement your own convoluted unique workflow.

Aeolun 6y ago
That’s generally because the ‘own workflow’ is insane in the first place (10s of years of managers adding their own crazy conditions).

koonsolo 6y ago

Good explanation! These companies start out thinking they will make a better product than anything out there. But due to limited resources always end up with an ugly monstrosity that is hell to work with. So they end up with something more expensive (but that cost is hidden), and something worse than what's off the shelve. I always ask them "So are we the only company in the world that is developing software?". Tools are pretty powerful, so you build your process around them.

ish 6y ago

I ask clients (and myself quite frankly): what is the competitive advantage of doing it this way? Do you get a leg up on your competition? What's the opportunity cost of spending time and money on this instead of your core product or mission?

momokoko 6y ago

Process is a crutch for bad management. If you are constantly moving from process to process because they aren’t working, you likely need to replace a significant portion of the management team. Almost all processes work well enough. And there is nothing wrong with trying to find an optimum one. But process is not the solution. Quality management talent is.

contingencies 6y ago
I cultivated an extreme dislike for managers for years. Then I became one. Things are a whole lot different from the other side. You perhaps overlook a few things: (1) Managers are people too. They make mistakes. They should be able to recognize and correct them as others. Ideally quickly, transparently and with the insights of others. (2) Needs evolve. The right process for proof of concept R&D is not the right process for global domination with a mature product. (3) Management is about competing concerns. Often a decision must be made within a limited sphere of experience, time and resources and reviewed in the future. There is no 'right' decision, and it can be fiendishly difficult to quantify decision quality in many such circumstances without the benefit of hindsight. (4) Different people can respond very differently to the same management, so 'bad management' is perhaps too uni-dimensional a notion to hold much meaning.
- momokoko 6y ago
  I never said managers where bad or that I disliked them. Sorry you got that impression. In this case all I was referencing was that frequent process changes and repeated failures of process are typically an indication that a change needs to happen in management not process. No where did I state management be eliminated altogether. I stated that better managers need to be brought in to replace those that are underperforming.
  - contingencies 6y ago
    Cool yep. Process change costs real money too ... observe the ETL phenomenon as an example. perl dies hard.

jariel 6y ago

"the great tools that have achieved widespread adoption understand the problems, and all their caveats, better than you" Tools that get widespread adoption are mostly those that move quickly to add every little feature every manager/exec asks for in order to secure the contract. Once they become incumbent, they become the standard, because managers are responsible for the 'big purchases'. There's tons of very accepted systems that are 'not very good'.

agumonkey 6y ago

I also wonder if there's some twisted emotional flow in people to consider whatever hell they conquered as the way to go forever. Questioning their ways is seen as such an insult there must be something deeply wound in their brain.

abhgh 6y ago

I agree with you, in the context of working in a corporation. It's not a bad thing to pick tools and structure your workflows around them, because sometimes such tools serve as 'mental anchors' for standardizing a process. The article seems to focus on personal productivity tools, for which the author's conclusion might relatively hold to a fair extent.

starfallg 6y ago

Spot on. Some things just need to be good enough. Spend effort on solving the problems with the biggest impact, your workflow and tools don't deserve that much attention unless it's completely not fit for purpose. Also changing your process and tools too often and too drastically usually makes things worse. People spend all their time keeping up with changes to how things are done as opposed to actually doing things.

Konohamaru 6y ago

How unique are people? You take a bunch of teenagers, ask them to non-conform, and they all come up with the same pierced, hair-dyed fashion. As if they're clocks ticking at the same rate. If you have several million clocks reading the same time down to the microsecond, that implies the existence of a master clock they were synchronized to.

zmmmmm 6y ago

I think you need to distinguish here between "core business" where you generate your competitive advantage, and everything else. In your core business, were you are going to make the critical difference that determines why your business or organisation exists, shooting for the most finely tuned, unique solution that maximizes that advantage - or at least, enables capability to do that - is critical. For everything else - I agree. The more bespoke you decide to be the more pain you create for very little value.

dllthomas 6y ago

There's a story about early fighter planes... searches a bit... this seems to be the one, although I've not read this exact version: https://www.thestar.com/news/insight/2016/01/16/when-us-air-force-discovered-the-flaw-of-averages.html https://www.thestar.com/news/insight/2016/01/16/when-us-air-... The military was ordering planes designed for the average pilot. But because there are so many dimensions along which someone can vary, most people are far from the average on some dimension, and when SHF and they need to be able to reach the right thing at just the right time, sometimes they couldn't. Each pilot is unique, just like every other pilot. Accommodating that proved important. Now... how well does that translate to building software? I can certainly see reasons why it wouldn't. But I don't see an argument that wouldn't apply to the planes as well, without actually measuring things.

donw 6y ago
> Now... how well does that translate to building software? Well, let's dig on on what the Air Force ended up doing, overall. First, they studied and improved the ergonomics. Specifically, making things like seats adjustable. The tool became more adaptable for a wider range of pilots. At the same time, there is a limit to how far that can go, especially when we are looking at 1940s technology. The Air Force thus imposed body-size standards for pilots -- 5'4" to 6'5" is a wide range, but it excludes outliers. Too short, too tall, too wide, or too heavy, and you couldn't be a pilot. My Dad was in that category -- too big to fly his dream plane. Controls were adapted so that unique functions had unique hand-feels. Flaps had a different shape of control than landing gear, and all of that was standardized across aircraft. So what does that tell us about workflows for engineers? Well, we can say firmly that physical ergonomics matter. Bigly. Uncomfortable seats, poor-quality monitors, high-latency or slow network connections... all of those are deal-breakers. But in terms of things like process and practices... standardize what you can, give everybody a sane baseline from which to work, and then empower them to customize as much as possible for their team or group. At the end of the day, software is shipped by teams. There's this odd, pervasive myth of the Morlock and Eloi in the software world. E.g., that engineers are either beautiful artisans in designer specs to which every whim must be catered, or that you just need to shove a pizza under the door every couple of days and production code will then appear on your servers. Don't open the door, though. None of that is reality. And to work in a team, you get to surrender some of your personal work-autonomy, in order to leverage the cognitive multiplier effect.

w_t_payne 6y ago

Unix had it right. Provide a toolbox with modular legos that you can customise and fit together to make the tools that you need.