Hacker News Reader

Comment by emblem21 | Hacker News Reader

How to run a startup in 2016:

* No homebrewed tech allowed. It's too "complex"

* We should only use off-the-shelf libraries and SDKs because bar-to-entry isn't a real investor risk ("Just trust me, I'm a charismatic CEO who played golf a few times with the best friend of the college roommate of the guy who helped the guy close Series A for Baidu")

* Soft skills, soft skills, soft skills! Smiling > coding

* I don't know what technical debt is, but I'm sure we can safely rewrite our core product from scratch in between Series B and Series C. Product owners, customer support teams, and quality assurance re-on-boarding is a money problem, not a leadership problem.

* Security audits? I have no idea what those are, but lets incorporate IoT into our product suite somehow. That seems hot right now to VCs.

Bubbles. Bubbles everywhere.

View on HN

Re: No homebrewed tech

Yeah the gig I had got taken over by some guys who said "Why are you doing all that yourself? You can get off-the-shelf stuff for free!" Literally the first words out of my mouth were "We didn't write our own code because we were not smart enough to use open solutions. We had product and performance requirements that could not be met." They gave lip-service to me for some months before letting me go. A year later they still are an order of magnitude below our previous performance/quality/feature levels.

"Can that corner be cut?"

"Well technically yes, but..."

"Good, cut it"

.. 2 years later ..

"How could we possibly have been hacked! We had security right?!"

.. points behind at ten miles of cut corners ..

The problem was that the corner could not actually be cut. If the answer is, "yes, but we won't hit our performance targets," then the answer should have been "no, we won't hit our performance targets." Your management can't help it that you said it was possible.

In my case, every meeting I had consisted of me saying "We need to know which features and performance goals we can sacrifice." Never got any answer. They wanted it all; they didn't want to pay for it.

Is it possible this was a communication failure not a technical one? I'm guessing your bosses couldn't tell the difference between the old performance level of your code and the new performance level of the off the shelf code. But, I'm betting they could tell the difference in communication styles. I'm guessing you said 'no' a lot and your replacements said 'yes' a lot?

>"They wanted it all; they didn't want to pay for it."

The above happened on almost every project I have worked for over the years.

Q: "Can we take feature x out of the plan?"

A: "We can't release the product/project without it"

Q: "Can we then add 2 more months to the release?"

A: "Absolutely impossible, the client will not accept it"

You are correct, the reason is severe (and systemic) lack of communication:

Product-roadmap planning either does not involve technical personnel at all, or at least not until the very last minute, when you are brought in to essentially rubber-stamp the plan. Saying "no" takes a lot of courage at this stage, you are seen as incapable/negative.

The underlying problem here is that we are seen as mere technicians/workers, not planners or strategists (we are partially to be blamed for this, but that's a separate topic).

I've also had exchanges very similar to the above. What I think happens is that managers think that we're negotiating. Negotiating for what? I have no idea, but for many managers, it's their default assumption.

In fact, we're not negotiating. We're describing the situation to the best of our understanding. Indeed, when often these situations have started to feel like negotiations, I've stopped and emphasized that this is not a negotiation, this is my very best estimate as to what I need to get the job done, nothing more, nothing less. Sometimes this gets through to them.

Oh I communicated the failings and expected drawbacks. The lag, the failures to connect, the features now missing. The whole different architecture that prevented doing anything like what we were already doing.

But, its magical open-source! Which means anything can be fixed. Wave that wand and objections disappear.

The new bosses made the mistake of thinking our app was the product. But it was the behaviors it facilitated that was the product. They dummied up a web app that looked like what we'd been doing. But it didn't perform or scale anything like what we'd had. Which will probably kill them in the end.

As another commenter mentioned, this does sound like a communication (of priorities) problem.

Mgr: "Joe, we need to get this new FrobNoz done. This week instead of next."

You: "Sure Mgr, no worries."

You: "Hey Frank, you're working overtime to make this happen. Or else you're fired."

Frank tries, then quits. FrobNoz doesn't get done in time. You get fired. Your Mgr gets fired. Your company implodes. ;)

Or alternatively:

Mgr: "Joe, we need to get this new FrobNoz done. This week instead of next."

You (gives cool, direct look to Mgr)

You: "We can do that. But we need to pull resources from Alpha, Beta, or Gamma to make that happen. Which of these three is least important to you?"

Mgr: "Beta can wait, get this done."

Result: You have the people who can do it, (ideally) without excessive overtime. Hopefully the lack of Beta doesn't cause company implosion.

Anyone who says their Mgr demands all of it and won't make resource decisions, has not developed their "cold, direct look" (thousand yard stare?) enough.

This is a common point of miscommunication between engineers and management. To an engineer, anything not strictly ruled out by the laws of physics is possible. The answer shouldn't be whether something is possible, but whether it's advisable, prudent, likely to continue being successful, within budget, etc, etc.

Just about anything is possible if you're willing to throw enough money and time at it.

...which would be true, if there weren't an obvious and palpable power distance between management and engineering in 99% of cases. It may be in vogue to pretend that this power distance doesn't exist, but it does, and it means in practice that engineers often don't feel at liberty to be candid in these situations.

This problem is compounded when managers don't meet the minimum technical skill bar to rationally assess the tradeoffs presented to them by engineers.

If anything, good managers help ensure that this communication channel remains as bullshit-free as possible. Excellent managers actively elicit honest feedback, listen to it carefully, evaluate the risk / benefit tradeoffs, and insulate their reports from political consequences. Unfortunately, very few managers are excellent, which is a big part of why many engineers imagine management as this useless floppy vestigial apparatus.

(I say this from personal experience as a consultant: I learned really, really quickly exactly what managers do for you once I no longer had any.)

It's hard to stress how accurate this is, once you've had a manager who's good at this it's very obvious what separates the wheat from the chaff.

Same is true in the Program Manager/Tech Program Manager/Producer roles.

Developers should definitely write their own code when there isn't an open solution that they can leverage to solve the problem, but those situations are quite uncommon for the majority of startups. Most founders aren't doing the sort of cutting-edge development that no one has seen before; they're making a SaaS app that boils down to a few CRUD forms in a browser and some nice design[1]. Building a business around that is much, much easier and cheaper if you write less of your own code.

Use open solutions where you can, and don't use them where you can't.

[1] That is in no way denigrating startups that do that. If you can solve people's problems by making a better form then that is a Good Thing.

The way I like to put this — or a related concept, at least — is that no business should waste time building the aspect of its product that isn't the differentiator.

> Most founders aren't doing the sort of cutting-edge development that no one has seen before; they're making a SaaS app that boils down to a few CRUD forms in a browser and some nice design

They should probably ask themselves what sort of defensible competitive advantage they're building, though.

With many founders I know, the answer is "none". This is probably necessary in the very early seed stage - it's hard to build something unique and difficult and still get to market - but it's disturbing how many companies end up with $50M in funding and the answer is still "none". Probably a good indicator of a shake-out in the SaaS world in the near future.

Network effects are a good example of something that is both non-technical and defensible.

You can't build the next Facebook anymore because everybody's friends are already on Facebook.

The competitive advantage those companies have is typically two-fold: knowledge and brand.

Knowledge is the very detailed and insightful understanding of what their industry needs at the moment, and where it needs to move to in the longer term. Founders who build those businesses are typically experienced in their industry and are solving a pain they've seen firsthand. That is exceptionally hard to compete with if they're good. Just because that knowledge can be codified in a 'simple' CRUD app doesn't make it any less valuable.

The brand advantage is comes from being the first mover. If the industry knows your company, trusts that you've proven to have an impact on their bottom line (or their competitors bottom line), then you're probably in a good position to retain customers and build a market. Competition is not a problem for a business that's intent on making a market $100m bigger rather than trying to take $100m of business from someone else.

Neither of those advantages require any code.

It is a pretty delicate balance and requires good engineers.

If you're a religious language defender (bleh, why are you using Java, Perl, etc.), you're not going to be objective. Different languages are useful for different problem spaces. Somethings are starting to show their maturity.

For example, I use to write software that ran on OpenWRT based tiny/embedded systems in Python, because python-mini was present and I could install it, my dependencies and everything I needed in less that 16MB of space. There weren't many options for that footprint other than C, but that was 2011. If I wrote it again today, I'd have to seriously consider using Rust instead.

Being a good engineer/architect requires a lot objectivity. It involves working at different shops with different frameworks, languages and design decisions and filtering through all of that. It involves constantly searching for "I really hate <x>" and "<x> is a piece of shit" every time you find something you really like and have pushed towards your production release, just to see what issues other people have and if their problems are things you may run into. By the same token, when you use something you hate, you want to do the opposite searches as well (e.g "I really love Powershell").

This article is really written from a business perspective. There are a lot of businesses that survive their startup incubation period with terrible design. Some even become profitable. Good luck keeping your developers though.

You hate PowerShell??? Say it ain't so!

The real kicker here is development at scale. Anyone that comes in has to learn how all that custom code works, and chances are if you're like any startup I've interviewed/worked at (20+), you don't have any documentation on the code, or it's so out of date it's useless.

Meanwhile if you use that "off the shelf" thing and introduce a few hacks to make it work for your use cases, all I have to learn is those hacks and why they're there. The rest is already documented and maintained by another company who built this dev tool.

> The rest is already documented and maintained by another company who built this dev tool.

Or more likely it is someone's open source project on GitHub, and is just as poorly documented as something in-house would be.

This is something that should be taken care of when vetting the project on whether or not the company should use it. Anyone whos been around that block a few times knows to look for:

- current dev status (hasnt been updated in 6 months? probably shouldnt touch it)

- community review (is anyone else using it, hows it working for them?)

- limitations (this one is pretty obvious, technical limitations/benchmarks/etc)

- code quality (unless its a third party service you pay for you should be able to see if the code is worth a crap pretty easily).

- vendor lock (if we need to change, how easily can we change? do they use open source protocols/standards that other tools understand?)

But this is the point. There is no good rule for when you should use a library, and when you should build your own stuff in-house. It always depends on the specifics of your situation.

You need to think about things like the quality of existing third-party solutions, and how well they will fit into your codebase. You might find a third-party library that is 90% of what you need, but there just isn't a good way to get to the other 10%, and so sometimes even in those cases it makes sense to roll your own.

Other times I see people rolling their own versions of stuff, and it's clearly much worse than readily available libraries. You just have to look at the specific situation to determine the right thing to do.

It's worth remembering that their is also cost involved in using someone else's code. Use it when the benefits outweigh the costs.

I actually agree with most of these - at least for early-stage startups. Using off-the-shelf tools has nothing to do with barriers to entry; if you're reinventing the wheel for things that aren't at the core of what differentiates your product, you are just wasting time. As important as they are, reducing technical debt and improving security are not the highest priority items - especially when you have limited resources and a yet-to-be-proven product. And yes, soft skills often do influence a startup's success more than code.

You know that actual wheel has been, and continues to be, reinvented constantly.

I would claim using an existing programming language on a commodity platform is good for the wheel analogue. Beyond that searching religiously for ready made solutions with decision not to make it inhouse is just asking for trouble (one needs to approach technological problems with an open mind).

King: Here's some land for you to work on.

Serf: But we don't own it.

King: You need to improve your soft skills.

Serf: Sir, we don't own it.

King: You need to realize that you're going to starve if you don't start farming now.

Serf: Sir, how much of the food will you take for working on your land?

King: Don't worry about the agrarian debt or vendor lock. Think of me as a land-as-a-service provider.

Serf: But...

King: I already have deals with farm tools to offer you at a discount! $40 a month with $0.01 per pound of food created! Also, friendly reminder of soft skills..

Serf: Well, sir... I... I guess my farm has yet-to-be-proven...

You can't differentiate your product if you are the product. Tech service startups are just renters of digital property they can never own. They're the street shops of the internet.

Poor analogy. Virtual land is unlimited. You can get your servers quite fast if you need to. Plus being a commodity, prices race to the bottom, and if designed right, you can swap you "landlord" rather easily - move your dockers elsewhere.

Agreed. This king/serf analogy works for any supplier/buyer relationship.

King: here's some steel for you to use. ...

Land is, technically, unlimited in the real world as well.

Not all of it is accessible (other planets) or fertile (desert)

Not all virtual land is the same, either. Some virtual land is a vendor doing streaming-as-a-service. Some is payment processing-as-a-service. Containers cannot help you regarding the leased farming equipment. No matter what land you move you, you'll still need those third-party services.

>You can't differentiate your product if you are the product.

This is it, totally agree with that.

Flip side - people (read non-technical execs) deciding to build stuff themselves - and hiring a ton of developers just because they've raised money & can.

One startup I consulted with - was able to replace a broken e-commerce platform ($M+ in 18 months) in one week with a shopify platform and some custom development.

That sounds like this one guy who is trying to get me to work for free for his "company".

"What kind of cyber security does your server have?"

Speaking to me in buzz words is a huge red flag.

It is a perfectly good question to ask for the VC-type about to write a check to the one-guy you mentioned.

The fact that you do not speak their dialect does not make their communication any less meaningful. If anything, it means you will always be working for some one-guy or another, instead of being the one-guy.

I understood his communication. He isn't a VC. If a VC asked me that I would know how to make an appropriate response. I'm also not fully aware of what you mean here.

Bonus:

* Product must scale. You are not allowed to write code that will scale before we actually need to scale.

BS - A lot of good stuff started as homebrew tech. GoPro for example.

Reply on news.ycombinator.com