

Outsourcing and Limiting to Core Competencies are Essential - joeemison
https://medium.com/on-management/4578569760e8

======
jamieb
I've witnessed first-hand three start-ups slowed or stopped by "ninja"
developers using the start-up as an excuse to try some cool new technology
that will look good on a resume. In two of them, they were paid the going
rate. If you're not getting paid, or getting paid a stipend, then it may be
fair to use the start-up as a sort of experiment - the cool experience may be
all you get out of it - but this should at least be agreed upon. However, if
you're getting paid the going rate, then this is a job, not a party, and your
job is to get the job done.

Lets be honest, this sort of thing goes on at large companies too for two
reasons: resume stuffing, and job security code. My favorite is when someone
builds some really "cool" tech that only they understand, uses it to get a new
job, and then quits. If a manager lets this happen, they ought to be fired
too, in my opinion.

------
applecustard
From my experience anyone who doesn't do proper research into viable options,
is always the person who wants to build "cool" amazing bleeding edge things
are junior developers.

There's nothing wrong with this mentality when developing fresh new code for
small projects but once you work in an established company you need to stop
and think. Is this a new language, technology? What kind of support is
available, how hard will it be to hire someone that knows this or train them
up? Do we already have something pre-existing that objectively is just as
good?

Without such conservatism, you end up with undocumented frameworks that are no
longer officially supported, no one knows it and there are hundreds of these
things that just replicate each other, just because it was something "cool" at
the time.

This applies to frameworks, languages, libraries so on. Someone has to support
these things 2, 5, 10 years even down the track.

------
quanticle
_85% of all developer time must be spent on business specific logic_

Yeah. Come back in two or three years when your application's code has
degenerated into an unmaintainable mess, and adding new business logic is
taking four times as long as it needs to because no one sat down are
rearchitected the software to meet new needs.

I've experienced two jobs where this, in effect, was exactly what happened. In
both firms, previous management used short term contractors to get a "lean"
proof-of-concept out the door. In both cases customers loved the product and
started asking for more features. And, finally, in both cases by the time I
was hired (at +3 years in one company and at +5 years at another) the product
had grown so bloated and so unwieldy, management had brought development in-
house and was embarking on a multi-year project to clean up and rearchitect
the code so that it would accommodate new feature requests from customers. If
these two companies had paid more attention to the architecture of their code,
then a lot of pain could have been avoided farther down the line.

This strategy is great if you're building a pump-and-dump startup (like
Instagram, or Tumblr). But for an ongoing sustainable business? It's a recipe
for disaster.

~~~
thyrsus
The article implicitly urges one to keep "core competencies" in house. It
sounds as if in these instances, the core competency - development of the
software product - was outsourced.

------
joeldidit
I agree with the idea of not wasting time, but if you follow the advice given
here, you'll come across much like a narrow-minded idiot middle/product
manager with an extremely short-term focus. Your choice.

Programmers need to grow, so it's important for there to be opportunities to
try new technology. Obviously this can't frequently get in the way of the main
thing, but it matters; you don't want to fall behind.

~~~
joeemison
Nothing in the piece argues that one shouldn't try new technology. Under this
85%-rule-of-thumb, we went with Amazon Web Services for 100% of our
infrastructure in 2008. It was clearly the right choice, and worth learning.
My point was more that developers have a gravitational pull toward new and
interesting that needs to be tempered by a focus on what's best for the
business--and too often, it is not.

~~~
joeldidit
I agree with what the article says about outsourcing things that aren't core
to the business. I was responding to and disagreeing with another point the
article tries to make about the use of employee time (which prioritizes the
short-term over the long-term).

------
jared314
The concept is sound. You increase "velocity" by strategically decreasing your
development effort, but this leaves out the idea of technical debt completely.
I've start to believe there are things that will kill you in the short term
(bugs), medium term (missing features), and long term (architectural issues).
You can play with the percentage of effort put towards each area in every
version/release, but neglecting any one for too long can kill the product. It
seems easier to explain the balancing act to people that way.

------
thyrsus
Does this apply to non-startups? Once one becomes an incumbent, is it not wise
to minimize external access (inherent in outsourcing)? E.g., the core
competency of the NSA might not be system administration, but perhaps they
would now prefer that someone more imbued with their culture had performed
those duties.

~~~
joeemison
I think it does apply to non-startups as well, because the "outsourcing" I'm
talking about with software development is really just using existing tools
and frameworks, not bringing new developers into the fold.

For example, I think it makes more sense for the NSA to use existing databases
than writing their own...

------
ArekDymalski
This one is must-read for all (not only non-technical) managers. And actually
it sheds light not only on management but recruitment as well. Simply you need
people who are passionate about the result (shipped feature that adds business
value) not the process (exploring, tinkering, learning etc.).

------
dschiptsov
Is all that pathetic flow of long-words about the old idea of having a
secretary?)

btw, is it possible somehow to reduce the amount of nonsense^W links from
medium.com? We have enough narcissism here from patio11 and likes.)

~~~
ArekDymalski
No, it isn't about secretary. It's about huge problem with the way many
developers approach their work.

~~~
twic
Indeed. It's not unique to startups, either; i've seen it in ordinary
companies too.

There's something deep and interesting to be unpicked here. On the one hand,
the desire to dive into with new technology and make your own things is rather
positive and joyful. On the other, doing that rather than pursuing goals with
real value is sad.

Many would object that the former enables the latter, but this is nonsense.
We're not talking about prudently investigating potentially useful new
technologies or inventing transformatively useful new tools. We're talking
about using the latest hot NoSQL database without worrying about its
appropriateness, or writing your own web framework just because.

Choosing the former over the latter seems, more than anything, childish. It's
choosing eternal inconsequential play over taking effective control of the
world.

I note that there are other elements of modern programmer culture which can be
seen as childlike. The lust for table football tables in the office, the
excitement about workplaces that have free food. Garann Means's 'Bacon is bad
for you' talk advances a theory that's vaguely related; it really struck a
chord with me.

I find this angle of programmer culture to be deeply frustrating, because it
means the discourse is dominated by the shiny and superficial, rather than the
genuinely difficult and important.

But then, Bucky Fuller wrote that "children are born true scientists", and the
dramatist Keith Johnstone said "Most people lose their talent at puberty. I
lost mine in my early twenties. I began to think of children not as immature
adults, but of adults as atrophied children.". Maybe i'm overlooking the
positive aspects of hacker neoteny.

