Outsourcing and Limiting to Core Competencies are Essential | Hacker News Reader

Outsourcing and Limiting to Core Competencies are Essential

medium.com

33 pointsjoeemison19 comments

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.

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.

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.

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.

You miss the point--you're talking about outsourcing development. The point of the article is to use libraries whereever you can, not to oursource all development to non-in-house developers. (The other reply to this gets it).

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.

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.

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).

Couldn't agree more with this. The notion of an "85% rule" seems unnecessary as long as business features are being implemented regularly and by their target milestones.

The idea of the 85% rule is more a rule of thumb than some kind of rigid metric--I mean, I'm not sure how you would even quantify that.

But I would argue that "as long as business features are being implemented regularly" is too vague to be useful. You could be regularly implementing business features and still have half of development time building some framework that is unnecessary.

I think learning is what keeps devs happy and interested in their job and that's a good thing. In my opinion, having a restricting mentality in the workplace will lower morale and lead to shitty code.

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.

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.

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...

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.).

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.)

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

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.

As for being distracted by so-called "new technology" nothing could protect one from choosing over hyped crap like MongoDB but knowledge of underlying concepts.

Recognizing and avoiding crap and a fraud is up to end-user. Otherwise one will end up running Java under Windows under VMware on Amazon AWS, as the best industry standard practice.) Or NodeJS as a "VM" with MongoDB as a "database".

Reply on news.ycombinator.com