
Look for the duct tape - fanf2
http://rachelbythebay.com/w/2018/03/23/ducttape/
======
aytekin
For non-programmers, usually the duct tape is a spreadsheet. I have seen
people who invent a CRM on a spreadsheet while not knowing what CRM means.

Looking for a SaaS idea? Ask random people in a target industry what kinds of
things they do with Excel.

~~~
beejiu
You don't need a domain-specific tool for every problem your business has. If
a spreadsheet works, great. If it ain't broke, don't fix it.

In a similar vein, there are plenty of small software teams that use nothing
more than a whiteboard for project management. Yet there are teams tooled up
with Jira/Trello/Slack with much less productivity.

~~~
nulagrithom
I have to argue against this, because spreadsheets are a real pet peeve of
mine. It can be hard sometimes to see _why_ a spreadsheet is broken.
Spreadsheets simply don't scale (and I don't mean lolwebscale or whatever.)

If two business processes interact through a spreadsheet, or more than two
people edit, you're going to immediately run up against the rough edges.
Multiple people editing the same sheet inevitably ends in error. It can take a
really gross amount of time to update the data when you're pulling/pushing
from two sources. It may seem small on the surface, but even 2 hours a week
adds up to nearly 3 weeks of work over a year. Can you replace this
spreadsheet in 3 weeks?

I've seen this play out many times at large and small scale. The first example
that comes to mind is a 10-hour day trip my wife took to go out of town and
manually update a whiteboard because somebody messed up the shared
spreadsheet. She was very unhappy, and this wasted a precious day during a
_very_ busy period. Initially, the whiteboard and spreadsheet worked great, so
they didn't "fix" it. It didn't scale to the busy times and really screwed
them over.

At a much smaller scale, I wrote a quick SQL query to get some business
metrics for the CEO. He asked if I could run it for him every week. Since I
didn't have a good place to put this query, I just ran it manually and emailed
it to him at first. Then he wanted to share it with someone on the opposite
coast outside our network, so he asked if I could start putting it in a shared
spreadsheet. My initial thought was to bang out a page they could pull up
instead, but I figured it wasn't worth it. Then he wanted another metric. And
another that required a bit of logic that couldn't be done in SQL. Pretty soon
I was spending an hour a week manually running SQL and copying the results in
to a spreadsheet. (We're a Google Drive shop. No way to connect Sheets to
DB2.) That's simply not worth my time. I should've listened to my first
instinct.

The initial investment in a spreadsheet isn't large, but the ongoing
maintenance can really rack up hours. I think it's very often worth
investigating any spreadsheet that users have been maintaining/recreating for
more than a quarter.

~~~
thaumaturgy
> _We 're a Google Drive shop. No way to connect Sheets to DB2._

FWIW, Google has an API that can be used to get data into and out of things
like Sheets. The documentation for it is abysmal and there are only a few
libraries out there, most of which aren't complete. But, I've done it, and
have some rough (but easy-to-understand) code that can "import" Sheets into
MySQL. Going the other way should be a matter of tweaking the Google account
permissions and calling a couple of different functions.

It's in PHP, but it's not gross PHP, so you can probably translate it into
whatever you're familiar with.

~~~
chrsstrm
Here's a freebie that I wrote in like 15 minutes and use in multiple prod
situations. Treat any Google Sheet like a JSON data source.
[https://gist.github.com/chrsstrm/3fb0ce6820acecf62c5490d220d...](https://gist.github.com/chrsstrm/3fb0ce6820acecf62c5490d220d4ec5f)

Yes, the App Script API is kind of limited, but also extremely powerful for
simple services or to glue services together.

------
ChuckMcM
This is an excellent tenet in general. A landscape designer at school was re-
doing the engineering quad and there was a lot of debate about where to put
foot paths, and the designer said, "We will put down grass everywhere, then
after a year come back and see where the paths are, then we will add stones
for the foot paths." It was pretty effective.

I think if you were a product designer you would do well to have users send
you their customization files to extract things that were common to all of
them to put into the product.

And of course Windows was pretty famous (infamous?) for taking what ever
shareware thing people were giving out to make Windows work better and then
incorporating it into the base OS. I read a review of Windows '95 that called
it "Windows 3.1 with Norton Desktop pre-installed."

~~~
drawkbox
> _We will put down grass everywhere, then after a year come back and see
> where the paths are, then we will add stones for the foot paths._

The old desire path that is based on user experience not design [1][2]. Never
fight the desire path, it is a losing battle.

[1] [https://i.imgur.com/fAmGY2A.jpg](https://i.imgur.com/fAmGY2A.jpg)

[2]
[https://www.reddit.com/r/DesirePath/](https://www.reddit.com/r/DesirePath/)

~~~
greenleafjacob
[https://www.imgur.com/r/desirepath](https://www.imgur.com/r/desirepath) (I
used to work at Imgur...)

------
TheRealDunkirk
As an engineer-turned-programmer/sysadmin, working with other engineers, I've
built a career out of doing this. Unfortunately, as a person with only-
marginally-better-emotional-quotient than other engineers, I've expected my
solutions to be widely regarded, based purely on merit. After 25 years of
this, I'm once again hitting roadblock after roadblock because I didn't "kiss
the ring" of the people in charge.

I've made them look stupid by building something pretty good where they have
been failing for 10 years with an entire team. Then I went and wrote another
application in a strange new framework that had been invented in the past 15
years, and this startled and frightened them.

Don't be like me, kids. Play the political game. If you don't want your
managers being told to dismantle the things you build, simply because you
didn't kiss enough butt, learn how to raise your "EQ" and ensure the success
of what you build. Otherwise, like me, you will have just written a bunch of
stuff users loved, but management hated, and forced them to stop using.

It's too late for me; save yourselves.

~~~
unixrefugee
I agree with this as I currently find myself in this very situation. I was a
Unix admin for a decade and then found myself having to embrace Linux and then
Windows Server to have a job. I've been a sysadmin for 20 years and one is who
quite happy to work as a "coder" when needed.

I took a new job about a year ago, one that found me in a group of people who
were struggling to do "simple" things, but doing them the "hard way". I came
into this job, and because the core infrastructure is Windows Server, I
learned PowerShell in about 6 months and started "solving" their problems by
automating this and that. Things got easier, but the existing people thought
me strange that I would resort to the "mere command line" for a solution
rather than go about things using a GUI. My rule of thumb has always been "if
I have to do it more than twice, script it."

These people have poo-pooed my every effort along the way and the boss has
even called me out on it, despite me showing him that we are making strides
where the team once did not. Sorry, I'm a command line guy at heart, and this
will never change. I'm not a method man by any stretch. PowerShell is the
orthodox way of handling Windows Server issues and that these people I work
with don't want to embrace it is not going to slow me down.

We engage in useless meetings to have meetings. We talk about senseless things
to jabber. I want to write scripts to automate certain tasks, but no. "What
happens if you get hit by a bus, bro? No one knows how to code in PowerShell."
My response to them was "I came here not knowing PowerShell, but I took the
time to learn it and I'm productive in areas where you could be, too. I'll be
happy to show you everything I've learned and coach you when you have time."
They look at me like the proverbial deer in the headlights. I'm toying with
leaving this year, as I want to work around like-minded, always-curious
people, not people stuck in yesteryear.

~~~
z3t4
When upper management see you are 10 times more effective, doing the same job
as 10 other people, they might become interested. But if there's not enough
job and you get paid for just sitting there, then use that free time to
contribute on open source or something. Or maybe there's someone else there
who has a pet project you can work on. If this is the case you should consider
yourself lucky. At most jobs there's never a shortage of work. Eg. there are
always more tasks that you can possible do and pressure from management that
it needs to be done today, if not yesterday.

Also if you are that much more effective you could start your own business,
hire people and train them, then have 10x bigger margins then your old
employer.

~~~
unixrefugee
Thank you for your comments. I have toyed with the idea for years of going
into business for myself, but have no ideas. I'm a sysadmin who knows *nix,
macOS, Linux, and Windows very well. I can only write in "scripting"
languages, as my jobs all the years required only those. I never really
branched out into Python (I can read it), or C++, etc.

I have no idea what to do, what to offer, etc. It's funny, because when I'm at
work, I don't really have to think too hard about solving a task. I'm
generally the "smooth over" guy who fixes the things other people don't really
see as issues, but having been in IT for so long, I can see the problems in
the distance for a given job, as I've encountered them before. Most people
just fly by the seat of their pants, but I love doing things once and well.

~~~
z3t4
Maybe you can be one of those solo entrepreneurs where everything is
automated. Pick a niche that is very boring and are currently done by mundane
manual work. For example accounting. Kick start by taking an existing product
and sell the patchwork/scripts as a module/plugin. Maybe something like SAP.
Don't quit your job until you are profitable though, and can just kill the
project if it doesn't work out. It usually takes a few tries and a lot of
learning until you figure out what works and what doesn't as an entrepreneur.
eg. selling something people want (a faster horse) vs trying to sell something
_you_ think they desperately need (a car). Eg. pick the low hanging fruit, and
don't be tempted to solve the hard problems until you have enough resources.

------
klenwell
> What bugged me about the (X) environment when I was there? What would I
> change?

I recently started as lead dev at a small company experiencing some real
growing pains. The CEO wisely had me spend a couple days my first week going
around talking to team leads. It was very productive.

I started with almost the exact same question Rachel suggests here. My
version:

> What's currently frustrating you?

I deliberately left it open-ended and found many of the non-technical answers
worth passing along to management. "Let the fools have their tartar sauce!":

[https://www.youtube.com/watch?v=X25rP4rTw3A](https://www.youtube.com/watch?v=X25rP4rTw3A)

The other question I came up after my first couple meetings. I called it the
Magic Lamp question:

> If, as the magic genie of this company I could grant you three wishes, what
> would they be?

By day two, these were the only questions I needed to ask. Following up with
the CEO, we came away with a very clear vision of what our development
priorities needed to be. Most of it aligned with what I already sensed coming
in, but there were still some useful surprises for us both.

(And, yes, found a few clever spreadsheets functioning as de-facto business
applications.)

~~~
pg_bot
That Simpsons clip leaves out the punch line, where Smithers attributes the
decrease in the accident rate to the promotion of Homer.

~~~
klenwell
True. I noticed that, too. And I think that lesson is as important as the
"listen to your grunts" message: beware false metrics.

It's a dense passage to be sure.

------
kaycebasques
Moment of appreciation for the title of this post. This is a rather “sticky”
way to share this idea (in the spirit of Made To Stick by Chip & Dan Heath). I
get the gist of Rachel’s idea without even needing to read the article.

------
erikb
Really hard to read blog, because the context is often missing. But through
reading a few articles it gets more clear.

(probably from another article than the one linked above)

> First thing, do not stick your neck out.

This advise always frustrates me. I know it's true, but feel it's really,
really hard to implement.

a) What do you do if you don't get any direct command from your manager? If
you then choose to do nothing you get the negative feedback that you didn't do
enough. If you go left, you get the feedback that you should go right. If you
go right, you get the feedback that you should go left. If you go straight,
you get the feedback that you are too direct. With everything you do, there's
automatically, intrinsically something you don't do, and that will be used as
negative feedback.

b) I don't know about other people, but becoming more successful is really a
necessity for me. If you always get negative feedback, how could you progress?
So I start hinting at the left and when the negative feedback to go right is
incoming I show that I actually moved right. You can believe me, I speak from
expeirence, that's when the real shit starts to hit you. Suddenly you are not
just a stupid employee, you are also disloyal and an intriguing schemer. You
are dangerous and need to get rid off. So apparently that's sticking the neck
out.

But then, what else to do? If (a) and (b) both is not acceptable, then what is
(c)?

PS: Also this article. Feels so much like my current situation:
[http://rachelbythebay.com/w/2012/01/09/rigor/](http://rachelbythebay.com/w/2012/01/09/rigor/)

~~~
qznc
First step is try to have an honest conversation with your manager. You cannot
really win if your manager is your opponent. If you cannot have a positive
relationship with your manager, you should look for a position elsewhere.

If your manager continues to be ambiguous and you haven't managed to leave,
then I would try to go orthogonal. Achieve something unrelated. It is hard to
blame someone who succeeds even if that success is unrelated to the main
quest.

~~~
wccrawford
We had someone do that, then brag about it during end-of-the-year reviews. The
managers were quite upset that the person had spent valuable time working on
things that not only hadn't been assigned to them, but also hadn't been
brought into the process for scheduling them or even brought to the attention
of anyone else in IT.

So no, it's not hard to blame someone for working on the wrong things when
they should have been working on something else.

------
jcims
Absolutely nothing to do with the topic at hand, but Rachel had a really cool
scanner project online for a while that paired well with my temporary
obsession with all things RF -
[http://scanner.rachelbythebay.com/](http://scanner.rachelbythebay.com/)

Back then your options were basically Ettus transceivers for >$1K or the
little RTL dongles for $20 that didn't have sufficent bandwidth to do much
good. Since then a whole crop of SDRs have hit the market in the <$500 range
that could do this kind of thing.

~~~
wglb
I really like this project. Not only did the radio audio have great quality,
the way that the snippets are arranged makes a very good gui.

~~~
rachelbythebay
Thanks! We were really lucky in that the Santa Clara city system was still
using analog voice channels with lots of bandwidth (20K0F3E). If you check out
the SVRCS system that replaced it (and I also logged for a few years), the
audio quality is a lot worse. Super-compressed audio which then gets crammed
through /another/ codec (MP3) isn't great.

I will admit that I actually listened to the original system a lot with
headphones, so I had every reason to fine-tune it until it sounded as awesome
as possible. If you go back far enough into 2011, you can find a bunch of
calls with terrible audio before I figured out the finer points of squelch,
tuning errors, and 48 vs. 44.1 kHz :-)

I haven't decided whether it's worth building another system now that I have
time to actually listen again. Hmm...

~~~
xvf22
When I lived near the airport I made an ACARS monitoring box with the B200 and
GR. Had a bunch of fun analyzing engine performance data and the funny
messages going back and forth. Travelling with my rtlsdr has saved my butt a
few times. Always nice being the first to know that a flight has been
cancelled.

------
bogomipz
I enjoyed reading this as well as some the other blog posts on her site. I was
curious about the following:

>"I've been having some wonderful conversations in the real world since
resigning and jumping off the merry-go-round."

What merry-go-around or where did she resign from?

~~~
saagarjha
I’m pretty sure she used to work at Facebook, but she’s never explicitly
mentioned it on her blog. Previously, she worked at Google, where she also
resigned.

~~~
bogomipz
Yeah I gathered she has spent some significant time in the valley. I hope she
might consider writing a post on her question of:

>"... and how to succeed in the "2018 version" of the culture which now
exists"

~~~
victorvation
She wrote briefly about it in "How to look out for yourself inside a
particular company".
[http://rachelbythebay.com/w/2018/03/21/next/](http://rachelbythebay.com/w/2018/03/21/next/)

~~~
bogomipz
Thanks for pointing this out. Cheers.

------
zython
Agree, but you have to be willing to invest your time and effort into a task
when you look for it that way.

Sometimes you can be better off doing things the simple aka duct tape way,
when it just works.

Anyone who's not read tacobell programming should take the 2 minutes to do so
now because it underlines my point very good.

[http://widgetsandshit.com/teddziuba/2010/10/taco-bell-
progra...](http://widgetsandshit.com/teddziuba/2010/10/taco-bell-
programming.html)

Incase my point is not clear: you have to differentiate, the concept of work
with the concept of problem solving.

~~~
apo
Taco Bell Programming can lead to duct tape.

You start with a simple script to do a simple job. It works - well. People
want more features. You keep going until nobody can understand what you've
created.

Then you leave the company.

Any software that works will be extended given enough time. To adapt the Peter
Principle, every piece of software rises to its own level of incompetence.

~~~
rhizome
_every piece of software rises to its own level of incompetence._

Which, from a simple review of the contemporary software landscape, is
obviously false.

~~~
convolvatron
i think the landscape has changed quite a bit in the last 10 years, but its
not clear we're in a golden age of simple, robust and composable software
either.

maybe you can paint a more detailed picture?

~~~
rhizome
The thing about Taco Bell programming is that sometimes Taco Bell increases
the number of available ingredients. What was 8 in the 1970s is at least a few
more now. Gorditas, for example. And once upon a time they sold zero varieties
of nachos. Don't forget to set up a Red Hot Cheeto cobranding partnership if
you want some more variety.

Almost the entire Unix software ecosystem is simple, robust, and composable. I
don't know where "golden age" comes from, though the list of existing software
that has not risen to their own levels of incompetence stretches back decades.

------
plusbryan
Fantastic article! This is precisely why founders that are novices in their
industry sometimes come up with the really big ideas. As counter-intuitive as
it is, it’s easier to see the duct tape when you’re looking with fresh eyes.

~~~
jeremy_wiebe
I wonder if fresh eyes don’t see the “stigma” of a duct tape approach; rather
seeing a good-enough solution for now that’ll work. Instead of agonizing over
a better way to do it, they implement and get on with it.

I think more senior engineers fall into the trap of seeing the maintenance
burdens ahead and not wanting to, or not being able to, make the call to use
the duct tape.

~~~
rhizome
IME, Jugaard is a rare skill.

[https://en.wikipedia.org/wiki/Jugaad](https://en.wikipedia.org/wiki/Jugaad)

------
Bizarro
One tool that I would like (and is probably) out there is tool that would
easily let me compare and merge directories. I think this goes beyond Beyond
Compare. But here's my use case:

I have videos, images of our children in various places (my phone, one drive,
dropbox, maybe usb sticks) that I want to go into the target directory
(probably one drive). the tool would go through all the other directories,
checksum them against all the other directories, and then present them as
"these are the files that should be merge into your target directory".

Can regular diffing tools do something like that in an easy manner?

~~~
incidentnormal
Maybe off-topic to your original need. But I've always wanted / needed a
utility that can de-duplicate media (images, music, videos) that I have
scattered around which are the same thing just at different
qualities/resolutions.

I get that for music and video this is actually quite challenging but images -
- I would've thought quite easy? I've tried a few tools which claim to do this
over the years but they all fail rather miserably / require a paid upgrade to
do it better (although what is demonstrated in the free version is never
impressive enough to consider paying).

Might be a good project for myself in my spare time, but wondered if anyone
knew of anything obvious I was missing? FSLint and stuff is great for general
filesystem de-duping, this is a slightly more complex case.

~~~
ryanfox
I work a lot with image and video processing - this sounds like the kind of
thing I'm interested in. Would you want to chat some time? Email is in my
profile.

------
tacostakohashi
A related observation I would offer is that not every environment / system can
be fixed with a layer of duct tape like this.

Unintuitive defaults, annoying long command-line options, needing to take many
separate steps to complete one task are all problems that can be trivially and
permanently solved with shell macros and wrapper scripts.

Performance problems, using the wrong data structures, random crashes, on the
other hand _cannot_ be solved this way.

------
greysteil
This is exactly what led me to build Dependabot - dependency management was a
minor pain at my old job that we'd written some scripts to handle better.

Another group of friends started Personably from exactly the same strategy -
we had a script to create dozens of calendar invites for new joiners with all
their onboarding details, so things didn't get missed.

~~~
fiatjaf
And is it going well?

~~~
greysteil
A qualified "yes".

Dependabot has ~100 paying customers, and makes just over $2,000 a month. It's
still quite a lot of work adding new features, but if I wasn't extending it's
functionality it would be passive income.

Personably have raised money and landed some big paying customers - I think
there's scope for them to be solving a relatively large problem, having
started from a duct-tape fix.

The only proviso I'd add to the article is that sometimes the problems you
find like this are small. Dependabot will never be a full-blown startup - it's
scope is too small. That's not necessarily a bad thing, though - I think the
problem has still been well worth solving thoroughly.

[https://dependabot.com](https://dependabot.com)
[https://personably.co](https://personably.co)

~~~
biarity
Don't any of the langauges you support have options to keep all dependencies
up to date? Eg. By putting wildcards in version numbers

~~~
greysteil
That’s normally an option for your manifest file (e.g., a Gemfile or
package.json), but most production applications also (sensibly) use a
lockfile. Updating the versions in that lockfile is what Dependabot is great
for.

------
maxander
This is why open source software works so well- layers of duct tape transition
seamlessly into the thing itself.

------
heurist
Always a good approach, but also recognize that not every duct tape solution
is worth productizing.

------
jsherwani
I took the scripts concept as a metaphor for the broken aspects of a company’s
culture, and how people work around these broken aspects with “scripts” of
behavior that they’ve learnt over the years.

Curious to hear about people’s duct tape fixes for team/company culture
issues.

~~~
hodl
I once has to log time on everything. It was a tempting workaound to log time
to the wrong ticket (still one of mine though) so that none of the tickets go
over estimate, so I wouldn't be taken to task. I even thought of writing a
tool to keep the mapping of real ticket to fake ticket.

Also better to try and get more nebulous work that can carry a higher
estimate/ buffer in the first place. And never refactor in the same ticket.
Create a new one. But that won't get done so just let it go.

------
vinchuco
\- A nuance: Consider a hammer with a cracked handle.

What's key is not the hammer crack (bad enough?) or the duct tape repair (good
enough?).

Instead it's the generality (portable, abstract concepts behind it like
'gluing' 'joining') and availability (common, cheap, simple) of the duct tape
that enables the (w)hack.

People don't buy duct tape to fix cracked hammers.

\- Afterthought : A Stack Exchange user answers: "why use duct tape when you
could just use super glue" (or rubber bands, zip ties...).

~~~
mirimir
Me, I tend to use super glue, some duct tape to reinforce, and finally heat-
shrink tubing for neatness and durability.

------
chris_st
This is why I was so frustrated with a co-worker a few years back -- he set up
his home directory to be unreadable, so I couldn't go look at his ~/bin
directory!

------
tkjef
this post helped me realize I had a whole open source project in my collection
of shell scripts. great post to help you look right in front of you to find
something good to work on.

------
feelin_googley
"a whole bunch of dumb little shell scripts"

This is definitely my duct tape. I am neither a developer nor a sysadmin, just
a dumb end user. When something cannot be written using only shell builtins, I
use a relatively small set of external programs in my dumb scripts, utilities
that would be found on most UNIX install media.

If I had the skills I would write many of these in a compiled language, i.e. C
or in assembler. As a non-programmer, I have found fasm to be the most useful
e.g. its ability to easily call C libs, but I also keep coming back to inline
asm as I like the extra bit of control over registers that if offers. I use a
small, old assembly level debugger that I prefer over gdb.

History suggests more than a few well-regarded projects originally began
life/were prototyped as shell scripts. (I would bet most readers are using at
least one today.)

Even though I lack the knowledge and experience of a career programmer, I do
not feel ashamed for using Almquists shell to test ideas. Though I certainly
understand the use of the word "dumb". However the truth, no matter how
"dumb", is that shell builtins are faster than most of the other scripting
languages I have tried, and not just in theory.

For some of these dumb little shell scripts, I have managed to replace them
with compiled programs (often with the help of flex/yacc), but most are beyond
my C/asm "implementation skills".

The point is that if a C programmer came to me, an end user, asking for ideas
of what "new" or "missing" utilities they could write (not sure if thats what
the author is describing), I could supply a lengthy list. Double digits, maybe
even triple.

As I understand it, programmers want people to use their software. Given that
I use many of these dumb little shell scripts every day, I could guarantee at
least one loyal end user.

~~~
elliotec
Care to share your top 5-10 missing utilities? Maybe I’m that programmer

~~~
feelin_googley
Examples of your work?

~~~
yorwba
Does it matter? Just post your list. Worst case, none of them get implemented.

