4 ms·

I once landed a job as a web developer in a marketing department where IT was gatekeeping production hard. Although all the code was in git (the real git), dep

by iamEAP 7y ago

I once landed a job as a web developer in a marketing department where IT was gatekeeping production hard. Although all the code was in git (the real git), deployment involved a magical shell script someone in IT had written ages ago. Only after a bunch of rocky, outage-causing deployments did we have the sense to start digging into this magic script. It turned out it was just a bad, thousands of lines long re-implementation of git using perl and mysql that captured and stored diffs and rsync'd them to production. ...And this was well into the era of CI/CD and infrastructure automation tools. Eventually, the company brought in new IT leadership that put an end to that kind of nonsense, which freed us in marketing to buy purpose-built PaaS for our needs. Obviously do this kind of crazy stuff as you please on the side. But at work, build only what uniquely adds value to your company. For most, dev tools are probably pretty low on that list.

angry_octet 7y ago
I really disagree, a small amount of customisation of tools can reap significant productivity gains. I think your anecdote is really just an example of bad management, not bad tooling. Could easily be that some management doofus had prohibited git from being installed on the 'production' system.
- peterwwillis 7y ago
  I think the problem is the idea of 'tooling'. A table saw by itself is mostly useless. With a fence and a miter gauge, it becomes useful. With a push block, stop block, subfence, outfeed table, infeed table, featherboard, crosscut sled, tenon jig, and dado set, it is the single most useful tool in a woodshop. Keep in mind it is still one tool and all those accessories are not "tooling", they are accessories to a single tool that increase what you can do with it. The tool always works the same way, and anyone can use it with any of those accessories in any woodshop in the world. In effect it becomes a new, larger solution, made up of many features that extend the utility of the tool. That's not really what we have. Mostly what we have are jigs. A jig isn't an outfeed table or a crosscut sled. It's a hack for a particular job. If you need to make one specific cut 300 times, you nail together some scrap wood, dial in the miter gauge, angle the saw blade, and make your cuts. And the jig is scrap once again. But in the heady new world of "DevOps engineering", the jig is now "tooling", and we pat ourselves on the back that we were able to nail some scrap wood together and claim it created business value. Of course, it's not a shitty jig like in the bad old days of shell scripts ("ha ha! remember when we were productive with this simple code that was portable and not gigantic or complicated? how foolish!"), because instead of making it out of scrap wood, we now make it out of scrap steel with a MIG welder. We're advanced now. And I'll go further. The fact that most woodworkers make their own tablesaw extensions is illustrative of the problem: craftspeople like having fun with their toys. Is there value and experience and dollar savings you get out of making your own crosscut sled? Sure! But it'll also take you 1-2 days of buying parts, measuring, cutting, gluing, clamping, drying, aligning, and finishing. Any business with any sense should have paid $100 to just buy a complete crosscut sled made of aluminum with a good design that will last forever. But they are too dumb to notice they're spending an inordinate amount of time and money on craftspeople making jigs. I wish the ghost of W. Edwards Deming would rise from the grave and call us what we are: bullshit artists.
  - angry_octet 7y ago
    If I could buy the software equivalent of spending "$100 to just buy a complete crosscut sled made of aluminum with a good design that will last forever", I would have done that. That is arguably what P/S/SaaS is, instead of building bespoke or Chef'd instances. But I'm not one to reimplement something in F77 in Julia just to have something to blog about. Regardless, sometimes a DSL is just what you need, and you'd better have someone who likes creating compilers do it. Otherwise it's like when builders do wood things without talking to a carpenter first.
  - ivix 7y ago
    I think you're saying that "creating home made tooling is a waste of time, and you should just use professional tools"? In which case I agree, for almost all cases. A carpenter trying to build their own saw or chisel would be laughed out of the workshop, and rightly so. However, the mark of a master craftsman is one who can identify when custom tooling are necessary and knows something about how to build them.
    - _carl_jung 7y ago
      In my opinion, this is simply an over-extended metaphor. Programming ultimately is not carpentry, and custom tooling is justifiable in many more cases.
  - forgottenpass 7y ago
    >Mostly what we have are jigs. [...] Of course, it's not a shitty jig like in the bad old days of shell scripts[.] Instead of making it out of scrap wood, we now make it out of scrap steel with a MIG welder. We're advanced now. Early contender for Best Analogy 2020.
  - iamEAP 7y ago
    My wife is a woodworker by trade and this metaphor is on-point. I return to my original point: if your company is working on something where "production" is novel/unique/a differentiator, then you probably need to invest a little time in how you manage and deploy to production (e.g. you need something that's more than just a jig, and you can't go down to the store and buy it because it literally doesn't exist). There is probably a certain point in scaling an engineering org (maybe 50+ devs) where you inevitably have to devote some engineering time to this anyway (e.g. you adopted/bought a tool that requires non-trivial maintenance and customization). If, on the other hand, you're working on something where production and deployment are a well-understood--maybe even commoditized domain--then you should direct your precious engineering time elsewhere. Marketing website infrastructure has its nuances, but it's well-understood. CRUD apps that talk to databases are a similarly well-understood area.
kortilla 7y ago
Sounded like you traded one incompetence for another. Why in the world would you gatekeep your deployment on an external service?

by iamEAP 7y ago

angry_octet 7y ago

I really disagree, a small amount of customisation of tools can reap significant productivity gains. I think your anecdote is really just an example of bad management, not bad tooling. Could easily be that some management doofus had prohibited git from being installed on the 'production' system.

peterwwillis 7y ago
I think the problem is the idea of 'tooling'. A table saw by itself is mostly useless. With a fence and a miter gauge, it becomes useful. With a push block, stop block, subfence, outfeed table, infeed table, featherboard, crosscut sled, tenon jig, and dado set, it is the single most useful tool in a woodshop. Keep in mind it is still one tool and all those accessories are not "tooling", they are accessories to a single tool that increase what you can do with it. The tool always works the same way, and anyone can use it with any of those accessories in any woodshop in the world. In effect it becomes a new, larger solution, made up of many features that extend the utility of the tool. That's not really what we have. Mostly what we have are jigs. A jig isn't an outfeed table or a crosscut sled. It's a hack for a particular job. If you need to make one specific cut 300 times, you nail together some scrap wood, dial in the miter gauge, angle the saw blade, and make your cuts. And the jig is scrap once again. But in the heady new world of "DevOps engineering", the jig is now "tooling", and we pat ourselves on the back that we were able to nail some scrap wood together and claim it created business value. Of course, it's not a shitty jig like in the bad old days of shell scripts ("ha ha! remember when we were productive with this simple code that was portable and not gigantic or complicated? how foolish!"), because instead of making it out of scrap wood, we now make it out of scrap steel with a MIG welder. We're advanced now. And I'll go further. The fact that most woodworkers make their own tablesaw extensions is illustrative of the problem: craftspeople like having fun with their toys. Is there value and experience and dollar savings you get out of making your own crosscut sled? Sure! But it'll also take you 1-2 days of buying parts, measuring, cutting, gluing, clamping, drying, aligning, and finishing. Any business with any sense should have paid $100 to just buy a complete crosscut sled made of aluminum with a good design that will last forever. But they are too dumb to notice they're spending an inordinate amount of time and money on craftspeople making jigs. I wish the ghost of W. Edwards Deming would rise from the grave and call us what we are: bullshit artists.
- angry_octet 7y ago
  If I could buy the software equivalent of spending "$100 to just buy a complete crosscut sled made of aluminum with a good design that will last forever", I would have done that. That is arguably what P/S/SaaS is, instead of building bespoke or Chef'd instances. But I'm not one to reimplement something in F77 in Julia just to have something to blog about. Regardless, sometimes a DSL is just what you need, and you'd better have someone who likes creating compilers do it. Otherwise it's like when builders do wood things without talking to a carpenter first.
- ivix 7y ago
  I think you're saying that "creating home made tooling is a waste of time, and you should just use professional tools"? In which case I agree, for almost all cases. A carpenter trying to build their own saw or chisel would be laughed out of the workshop, and rightly so. However, the mark of a master craftsman is one who can identify when custom tooling are necessary and knows something about how to build them.
  - _carl_jung 7y ago
    In my opinion, this is simply an over-extended metaphor. Programming ultimately is not carpentry, and custom tooling is justifiable in many more cases.
- forgottenpass 7y ago
  >Mostly what we have are jigs. [...] Of course, it's not a shitty jig like in the bad old days of shell scripts[.] Instead of making it out of scrap wood, we now make it out of scrap steel with a MIG welder. We're advanced now. Early contender for Best Analogy 2020.
- iamEAP 7y ago
  My wife is a woodworker by trade and this metaphor is on-point. I return to my original point: if your company is working on something where "production" is novel/unique/a differentiator, then you probably need to invest a little time in how you manage and deploy to production (e.g. you need something that's more than just a jig, and you can't go down to the store and buy it because it literally doesn't exist). There is probably a certain point in scaling an engineering org (maybe 50+ devs) where you inevitably have to devote some engineering time to this anyway (e.g. you adopted/bought a tool that requires non-trivial maintenance and customization). If, on the other hand, you're working on something where production and deployment are a well-understood--maybe even commoditized domain--then you should direct your precious engineering time elsewhere. Marketing website infrastructure has its nuances, but it's well-understood. CRUD apps that talk to databases are a similarly well-understood area.

kortilla 7y ago

Sounded like you traded one incompetence for another. Why in the world would you gatekeep your deployment on an external service?