
If You Build It, They Will Complain - ohjeez
http://www.techvibes.com/blog/if-you-build-it-they-will-complain-2015-12-28
======
RyanZAG
_> Just like the IT departments at large companies, I had created a scenario
where I was building internal tools that I wasn't prepared to support and
service. The excitement clouded my foresight - and I didn’t consider that each
new project would require regular maintenance and ongoing support. I would get
asked to add functionality or work on bug fixes, which amounted to several
hours of additional work each week. Worse yet, I was on the hook when
something stopped working at the worst possible moment._

Woah, he actually writes this off as a bad thing. The only real issue here is
that he just created himself a new essential department with himself as the
head. Most people would be thrilled - he needs to go approach executive
leadership with a simple report on how much he is helping the company and how
he needs to hire on additional help. It doesn't really matter that there are
possible 3rd party solutions that would work - his solutions are already
working and creating obvious value.

This is the opposite of a bad thing - he's probably just created himself a new
position and massive raise. I think people talk a lot about all sorts of
things missing from CS education, but clearly the best thing a school could do
is shove in a bunch of business classes into the CS curriculum to prevent
people thinking this is somehow a bad thing.

~~~
pjc50
_he 's probably just created himself a new position and massive raise_

This is not how the real business world works. It's just as likely to get a
negative performance review for insubordination, not following procedure, and
neglecting assigned duties.

~~~
hibikir
It's a gamble, but one that makes a lot of sense, in a very selfish way:
Building a career in one place without trying to take shots upwards is not
good: Programmers get more pay by changing jobs, not by being very patient and
hoping they'll get noticed eventually. So once you are in a place that isn't a
tiny startup (which is in itself a risk), you should take risks for big
internal payoffs. If those risks pay out, great. If they don't, then just go
somewhere else and try again.

Few things are sadder to me than seeing to talent that is mildly disgruntled,
being a key part of their organization, underpaid, not taking risks, just
hoping that someone would notice them and pay them appropriately: Providing
value without immediate recognition is just asking people to find ways to make
you provide more value without reward, as you've already proven that you are
too afraid to demand fair pay. I've worked with people that had spent 10 years
at a company, working on my team, as pillars of the company, getting paid
60k/yr, sitting next to a contractor billing 125/hr

~~~
toomuchtodo
> Building a career in one place without trying to take shots upwards is not
> good: Programmers get more pay by changing jobs, not by being very patient
> and hoping they'll get noticed eventually. So once you are in a place that
> isn't a tiny startup (which is in itself a risk), you should take risks for
> big internal payoffs. If those risks pay out, great. If they don't, then
> just go somewhere else and try again.

> I've worked with people that had spent 10 years at a company, working on my
> team, as pillars of the company, getting paid 60k/yr, sitting next to a
> contractor billing 125/hr

The lesson isn't to take big internal risks. The lesson is to engineer your
finances to allow you to weather the volatility of being a contractor, and
then be the contractor.

Everyone shits on the idea of the contractor, when they're doing exactly what
they're incentivized to do: maximize the value they extract in the shortest
period of time possible, while providing value to the organization they're
working for.

Screw your equity, your business culture/hierarchy, and paying your dues
(colloquially known as "F*ck you, pay me").

------
jacquesm
If you write it they will complain too.

The article isn't so much about end-users who will complain as much as it is
about properly designed software systems as much as it is about in-house and
ad-hoc created solutions that are not much more than cobbled together glue.

> Considering that it can take a SaaS company several years just to build an
> MVP

That's a pretty bad MVP then. Usually it takes a lot shorter than that, even
for a fairly complex MVP.

And why limit the comparison to SAAS, there are pretty good reasons why
companies may decide _not_ to hop on the SAAS bandwagon that have nothing to
do with not-invented-here, it may simply be that they are concerned with the
privacy of their users, with the degree of integration that they can provide
and with the dependency on an outside party for a (possibly) critical part of
their business. They also may not like to leak information that is sensitive
to the company or the end-users to third parties only covered by an SLA and
not much insight into the design parameters and the degree of care for detail.

A better comparison would be between a piece of closed source off-the-shelf
software or a piece of bespoke software created by outsiders but hosted by the
company, preferably one for a fixed price to create and a monthly fee to
maintain.

Ad-hoc glue stuff is usually extremely fragile (because any changes in the
underlying software will break it), uses all kinds of interfaces intended for
humans rather than proper APIs and is hard to maintain because of that.

TL;DR; Stuff I build is fragile, therefore you should use SAAS.

~~~
vinceguidry
> That's a pretty bad MVP then. Usually it takes a lot shorter than that, even
> for a fairly complex MVP.

I don't think most SaaS companies follow Lean Startup principles. Most of the
ones I've had to integrate with have had horrid infrastructures and extremely
brittle interfaces. It's a delight for me to actually have properly-maintained
documentation available on the web and not an out of date Word document that I
have to go back and forth with one of their engineers to understand. Non-
standard format implementations are the norm and not the exception.

The general gist I got is that sales guys pluck mediocre, but hard-working
engineers from the corporate ranks and build businesses around them. The whole
thing is kept together with long hours and elbow grease when it frequently and
inevitably breaks.

~~~
jacquesm
In my practice I see both. In the SAAS domain I see companies with successful
models and crappy execution (but they still remain afloat and sometimes even
win the race) and I see companies that are textbook examples of how one should
implement a business and scale it. And everything in between as well for that
matter.

------
pacap
Good article, confusing title. I was expecting something else.

Anyway, it's strange to hear authoritative statements about programmers from
someone who says "Ever since building my first VBA script in 2012"

~~~
jschwartzi
Actually my first professional experience was in fixing bugs in and adding new
features to an in-house application written in VBA using Access. It's really
bone-headed to dismiss someone based solely on the language they choose for a
project, especially if what they're saying otherwise makes sense. There are
lots of good developers using all kinds of languages, and they all get stuff
done.

~~~
benplumley
I'd guess that it was more the relatively short amount of time the author has
been programming than their choice of language. I skimmed the article and
assumed the author had been programming professionally for 10+ years, just
from their tone.

~~~
pacap
exactly, that's what I meant

------
pjc50
Teach a man to fish, and you've got to put up with his fishing complaints for
the rest of your life.

------
sgt101
"n McKinsey & Company’s 2012 report entitled Delivering large-scale IT
projects on time, on budget, and on value, the report describes one example of
a large bank that wanted to create a central data warehouse to overcome
inconsistencies in their data. In this particular example, the end goal was
never properly defined and the IT department embarked on building a solution
that never considered the actual business objectives, resulting in ‘huge
amounts of unnecessary complexity’ and significant cost overruns. After 18
months of missed deadlines, nearly $10 million in sunk costs, and no working
solution, the bank decided to stop the bleeding and cancel the project
altogether."

I don't see how the bank could have got a solution to this from a SAAS
vendor... they would still have had to pipe the data to the warehouse, build
the reports and management scripts and so on - setting up the data store is a
task, true, but so is initialising your store on a cloud provider.

~~~
zebra
The SAAS vendor will be used for its build expertise only. After the build the
bank will deploy inner cloud. And the provider will be payed well for the
build and for support.

~~~
sgt101
I don't think you are using the same definition of software as a service as
me! Salesforce.com is a SaaS vendor, it creates a solution that is shared by
many users on a cloud...

------
tahssa
This is like phase 1 in the IT cycle. There's a second phase where because
nothing gets done due to cost/value conclusions the IT management gets ousted.
New management then goes back to letting these things happen in a effort to
become more client considerate. It's a decade long cycle that regularly
happens.

------
onetimePete
If you think you build it, it is actually half finished, and left to everyone
to finish- who is able to just use git clone on your mind. Cause there is no
documentation.

And no- its not snappy to remark upon this after investing a day on fixing
your broken code-garbage can, just because its "free" \- cause it was not.
Time is money, and if you ask people to work for you for free, you are
expensive. Solution: Just do not claim with your project to be what you are
not. You're software is not free. You're software is not easy to use. You're
software is not plug and play in any way. Do not claim that. Say, that it is a
bolted together prototype and warn people who don't have experience with this,
that they might be in for a investment of weeks. Everyone stays happy.

~~~
collyw
I thought it was well known that prototypes almost always end up in
production.

------
kpil
OK.

I almost stopped reading when I got to "VBA, 2012" and presumably a few more
years of work experience before that.

But OK. If you are actually saying: "Hey - it seems to be a bit complex, maybe
we should ask a professional before writing our own excel-based maintenance
hell for our internal processes." Then I'm with you.

But don't outsource important stuff! m'kay?

------
skyhatch1
I remember a popular unicorn founder (can we just call it that) once referred
to himself as "opportunistically lazy". That certainly fits with the technical
persona since something within makes us averse to repetitive work.

But now it seems that we've automated pretty much everything we could, so
where to now for the technically minded lazy opportunist?

------
hibikir
There's many reasons to want to avoid writing custom software, but for those
that aren't actively living in it, it's easy to forget the dismal results of
buying enterprise software.

People buying it start with the impression that 3rd party software is good: We
don't write our own mail program, we don't write our own word processors, so
of course we shouldn't write anything a third party offers, they say. But that
shows a total misunderstanding of what makes software hard: specifications.

It's not difficult to build an application for a good price when we expect
tens of thousands of sales, and it's a task that will occupy mind-space, so we
expect users to be motivated to learn whatever idiosyncrasies our application
has. But when the application should interact with other applications, or
there are relatively few users, it's very hard to build it economically: Most
of those 3rd party disasters are in those areas.

For instance, we've had a bunch of very pointy haired people decide that our
org needed some kind of REST API + authentication management combo, and went
out there to purchase something, because building is bad. But it is exactly
the kind of system that will does not work well: It's built for big
enterprises, so it is seven figures, with recurring costs. It does not
interact well with the specific quirks of how the internal authentication
works, so hacks are needed. The UI is not really built for you, or anyone, so
it makes the AWS dashboard look like a UX miracle. And then there's the bugs:
There's still bugs (A lot of them), but now, instead of your own people fix
your bugs, now you have another company dealing with them, and since you
already paid them, adding new features is more important than fixing your
bugs. So now we are out a bunch of money, everyone that isn't pointy haired
hates interacting with the thing, and we've needed a bunch of custom code
anyway.

The decision between buy and build is not necessarily easy, but there are a
very valuable rule of thumb I love:

If you are going to custom build, and it's not key to your secret sauce,
expect to spend a bunch, and build it as an open source project.

Having other companies use whatever you are writing makes quality improve
faster, as there's more people to find problems in your specification and your
implementation. Sometimes you get people to help you with free labor. Others
they don't. But either way, you've lost almost nothing by making your code
public.

If you are unwilling to commit to making it open source, because it sounds
expensive, then you really were not going to commit to it as custom internal
software anyway. It would have ended up as a piece of crap everyone hates. So
then go and buy, as you weren't going to get any gains from building it custom
anyway.

------
saeeda
They will always say something.

