What Can We Learn From Ranchers?
Some of my youth was spent around farms and ranches, which has left me with interesting perspectives. I could talk/write about these perspectives for a while. I will focus on one area in this post: reusing old tools to build new ones.
Not Developed Here
Many software engineers are keen to borrow others' ideas or snippets of code. They are often on board with using an
entire library or program that does everything they need. Getting them to use something they didn't create can often be challenging, as it may not directly
meet their needs. Or sometimes, they think they can build a better mouse trap
so every other one out there won't suffice.
We hear things like, "That's not how it
should be done.” “What they did doesn't make sense,” and “I can build what we
need faster than integrating that system." These are all forms of saying,
I didn't make this, and I know I can do a better job, so I won't use it. I've personally done this many times. It’s
easy to believe that we have the better answer.
One of the most prominent examples of this I've
seen in my work was related to building a deployment system. We had a clear, reliable system of continuous
builds but didn't have an excellent way to deploy those builds to target
hardware for demos and testing. After investigating, we believed that creating
a deployment system seemed straightforward, and my team started planning. One
day, we learned that someone else was working on something similar. It could deploy but didn't support
notifications and scheduling. Then we realized
that another team was working on the same thing but required someone to choose
what was deployed to each piece of hardware manually.
Did we work together and find a standard solution
each of us could build to meet our requirements? Of course not; we built three solutions to
essentially the same problem.
The Scrap Pile
There has always been one very common thing on every farm or ranch I've seen: a big scrap pile. This is a pile of things that have been broken through use or replaced with newer equipment. They keep these because they are a valuable source of parts and future tools.
What does a random pile of parts have to do with software
development? Sometimes, we build or replace software that doesn't meet our
needs. Does that mean it isn't
useful? Sometimes, we write useless
code, but sometimes, there is another use.
One time, I was working on a project to create a
more efficient library for one specific area of our product. I built a lightweight, fast event
system that I thought was neat. However, it didn't work or make sense when I
applied it to my problem. Instead of
deleting the library and moving on, I stashed it in a folder on my PC and
forgot about it. Sometime later, a
co-worker tried to solve a different problem and casually mentioned needing a fast
event system. I pulled this library out
of my random folder, and we saw a 5x speed improvement in the feature they were
working on.
This useless pile of code was a huge improvement
to our system.
The Hyster Hay Squeeze
When I think about reuse, I always remember this
one hay farm I worked with. They had this interesting piece of equipment called
squeeze to move and load stacks of hay. These are expensive, specialized pieces
of equipment. As of this writing, a 10-year-old used model sells for well
over $100,000.
The farmer I was working with couldn't afford/justify
the purchase of a hay squeeze for their needs.
He found a used 5-ton forklift, turned the forks on their side, and
added a hydraulic ram to build his version.
For around $10,000, he had a fully functioning hay squeeze that he built
out of a tool that didn't quite do what he needed and a scrap pile. It doesn't look as good, but it does the same
job.
A Head Start == Money in the Bank
Starting with a library, project, tool, or
feature that isn't quite what you need should be considered a head start on
meeting your goals. Even if that library
has an associated cost, the savings are probably worth it. In my story above, the farmer saved at least
$90,000 by starting with an existing tool and modifying it.
Considering salaries and operating costs in
the market, it is hard to imagine that we can justify spending weeks or months
rebuilding something that mostly exists today in another form. Putting our pride and egos aside and putting our energy into extending or adapting the existing tools to meet our needs makes more sense. It will usually be
at least as good and cheaper in the end.
Solving the Right Problems
It is important to stop and reflect on what we are working on. We should always focus on building software directly related to our problem domain. If you are building a SAAS service for Veterinarians, will you spend your time implementing a scalable web server? No, buy a scalable web server and make the parts that are specifically needed by your veterinarian customers.
Take the parts and pieces that can be used from
other areas and adapt them to meet your needs, just like our local farmers do.
Comments
Post a Comment