4 ms·

Extremely important corollary: Build pipelines, autoscaling, CI, unit test, et al are not a real problem customers want you to solve. Not a single penny is goin

by nikanj 6y ago

Extremely important corollary: Build pipelines, autoscaling, CI, unit test, et al are not a real problem customers want you to solve. Not a single penny is going to roll into your coffers because you have tremendous infrastructure in place. NB: I'm not talking about selling a product for build pipelines, I'm talking about allocating excessive resources into internal tooling pre-traction.

closeparen 6y ago
You can get testing on pull request + deploy to Heroku on master going with GitHub in less than an hour.
- bebop 6y ago
  Or use Gitlab and have a CI/CD (to Kubernetes) for the cost of a Dockerfile.
  - matt42 6y ago
    or just run npm test / make test locally without setting up anything. But I feel like writting the tests takes usually more time than setting up CI/CD.
dcolkitt 6y ago
I pretty much agree with you, but the stronger counter-argument would be that having those things makes recruiting a lot easier. Top-talent engineers are going to be a lot more reticent to join a startup where the systems are constantly on-fire and held together by duct tape. The first few hires set the standards and corporate culture, so this can have a real impact on the company's long-term viability.
- deleted 6y ago
  [deleted]
- timr 6y ago
  You're talking about two different scales: if you're at the stage where you're choosing between selling and building on a daily basis, worrying about your recruiting pipeline is a second-order problem (if not a third-order problem). Once you, as a founder, have the luxury of hiring (presumably because you've done step one correctly), your time is then a choice between selling and recruiting, and in the early stages of that, recruiting isn't going to be much more than trying to convince good people you already know to join your team. These people aren't going to say no based on your CI system. Having made the mistake myself (multiple times), OP is 100% correct, and it's one of those messages that can't have any nuance, or people won't do it right. It's a treacherous vortex of failure for programmers-turned-founders: coding is much easier and more familiar than selling, so you find all sorts of reasons to write code when you should be talking to customers.
- wolco2 6y ago
  Or could attract those who like to find fault / rip apart your processes and impose order. That person might be what you need..
NationalPark 6y ago
Ignoring the "eat your vegetables" part of software engineering isn't a savvy startup hack, it's a deliberate taking on of tech debt for short term product velocity boost. It's also pretty dangerous for you engineering culture - most engineers don't like to work in this environment and good ones don't have to.
- daotoad 6y ago
  It's really all about making principled choices when it comes to how much jankiness you can tolerate for a short term velocity boost. Doing awful things to rapidly try out an idea and see if it warrants further investment is good, as long as you kill the ugly as soon as you understand that your POC is good and you are going to invest further or you know it's not a wise place to invest further. But there are definitely places where you know you're going to need sanity no matter what. This is anything you know you're going to do a lot, especially under a time crunch. For SaaS work, deployment is one example. In these cases, it's worth investing in building a low friction solution that meets your needs.
stickfigure 6y ago
I applaud this attitude, but I think you are wrong about the specifics. If you are serious about this craft, you should have a stock build/test/ci harness you can spin up without effort. Even if it's just "copy some boilerplate from a previous project". This is just basic software literacy, like using git. If you are using something like Google app engine or heroku, all that autoscaling and other devops stuff is taken care of for you. There is no reason to go without.
- musingsole 6y ago
  I think there is a core truth you're point to that when you're working on the initial months of a start-up, knowledge and time to acquire it are massive weaknesses. If you're using that time to learn how to build your CI pipeline, that's probably not the best allocation of that critical time. An entrepreneur would be best served by CI practices they can employ off their own shelf and focus their attentions on the billable problem solving.
  - endymi0n 6y ago
    This. It took us three months to market back then, mostly because we skipped everything nonessential. Like, really everything. Sure, these days we have CI/CD with static checking, ChatOps, full observability, all the nice stuff that attracts good developers. But all of that is completely irrelevant to customers. It's just relevant to scaling a dev team. The very first version we launched publically, we checked out, compiled and deployed through SSH directly on the servers. My first monitoring tool was htop in 3 screens plus some CloudWatch dashboards. A lot of credentials and endpoints were hardcoded. Not because we didn't know better, just to save time. The number one thing pure techies completely get wrong is opportunity cost. Especially in the beginning, almost nothing beats time to market to validate product/market fit.
staysaasy 6y ago
100% and I see this kill startups from time to time. Particularly ones with very technically sharp but unwise founders. That said I think that investing in a minimal, quick and dirty CD system can be valuable for very early startups that need to move very fast on the road to product/market fit.
raverbashing 6y ago
This this this Ship it I don't care if you're installing it by retyping the code into your server (hyperbolic example, sure), but ship it. Can you get payed? Can the customer use the product, even if it's a basic version? Ship it The rest is fluff. Of course do worry about them, after you start having money go into your bank account.
- xupybd 6y ago
  I've had to clean up from this once the product matures into maintenance mode. It's fine to start this way but people have to realise they will need to put some structure in place. At some point you'll struggle to get new features out on time without a ton of bugs.
  - raverbashing 6y ago
    Yes, I agree. But it's easier doing the structure while you're getting money in the bank.
hinkley 6y ago
Customers pay for velocity. You can get velocity by installing a freight elevator, or by jumping off the side of the building every time. Tooling is tooling, not a religion. But if you've ever looked at the regimen of an elite professional athlete, you'd be hard pressed to discern it from a religion. It is necessary, but insufficient, and I don't think most people get that.
- nikanj 6y ago
  I was more talking "We don't have a single customer yet, but we have an industry standard set of redundant freight elevators, with automatic load balancing and travel optimization" versus "We have 120 paying customers, and still take the stairs".

by nikanj 6y ago

closeparen 6y ago

You can get testing on pull request + deploy to Heroku on master going with GitHub in less than an hour.

bebop 6y ago
Or use Gitlab and have a CI/CD (to Kubernetes) for the cost of a Dockerfile.
- matt42 6y ago
  or just run npm test / make test locally without setting up anything. But I feel like writting the tests takes usually more time than setting up CI/CD.

dcolkitt 6y ago

I pretty much agree with you, but the stronger counter-argument would be that having those things makes recruiting a lot easier. Top-talent engineers are going to be a lot more reticent to join a startup where the systems are constantly on-fire and held together by duct tape. The first few hires set the standards and corporate culture, so this can have a real impact on the company's long-term viability.

deleted 6y ago
[deleted]
timr 6y ago
You're talking about two different scales: if you're at the stage where you're choosing between selling and building on a daily basis, worrying about your recruiting pipeline is a second-order problem (if not a third-order problem). Once you, as a founder, have the luxury of hiring (presumably because you've done step one correctly), your time is then a choice between selling and recruiting, and in the early stages of that, recruiting isn't going to be much more than trying to convince good people you already know to join your team. These people aren't going to say no based on your CI system. Having made the mistake myself (multiple times), OP is 100% correct, and it's one of those messages that can't have any nuance, or people won't do it right. It's a treacherous vortex of failure for programmers-turned-founders: coding is much easier and more familiar than selling, so you find all sorts of reasons to write code when you should be talking to customers.
wolco2 6y ago
Or could attract those who like to find fault / rip apart your processes and impose order. That person might be what you need..

NationalPark 6y ago

Ignoring the "eat your vegetables" part of software engineering isn't a savvy startup hack, it's a deliberate taking on of tech debt for short term product velocity boost. It's also pretty dangerous for you engineering culture - most engineers don't like to work in this environment and good ones don't have to.

daotoad 6y ago
It's really all about making principled choices when it comes to how much jankiness you can tolerate for a short term velocity boost. Doing awful things to rapidly try out an idea and see if it warrants further investment is good, as long as you kill the ugly as soon as you understand that your POC is good and you are going to invest further or you know it's not a wise place to invest further. But there are definitely places where you know you're going to need sanity no matter what. This is anything you know you're going to do a lot, especially under a time crunch. For SaaS work, deployment is one example. In these cases, it's worth investing in building a low friction solution that meets your needs.

stickfigure 6y ago

I applaud this attitude, but I think you are wrong about the specifics. If you are serious about this craft, you should have a stock build/test/ci harness you can spin up without effort. Even if it's just "copy some boilerplate from a previous project". This is just basic software literacy, like using git. If you are using something like Google app engine or heroku, all that autoscaling and other devops stuff is taken care of for you. There is no reason to go without.

musingsole 6y ago
I think there is a core truth you're point to that when you're working on the initial months of a start-up, knowledge and time to acquire it are massive weaknesses. If you're using that time to learn how to build your CI pipeline, that's probably not the best allocation of that critical time. An entrepreneur would be best served by CI practices they can employ off their own shelf and focus their attentions on the billable problem solving.
- endymi0n 6y ago
  This. It took us three months to market back then, mostly because we skipped everything nonessential. Like, really everything. Sure, these days we have CI/CD with static checking, ChatOps, full observability, all the nice stuff that attracts good developers. But all of that is completely irrelevant to customers. It's just relevant to scaling a dev team. The very first version we launched publically, we checked out, compiled and deployed through SSH directly on the servers. My first monitoring tool was htop in 3 screens plus some CloudWatch dashboards. A lot of credentials and endpoints were hardcoded. Not because we didn't know better, just to save time. The number one thing pure techies completely get wrong is opportunity cost. Especially in the beginning, almost nothing beats time to market to validate product/market fit.

staysaasy 6y ago

100% and I see this kill startups from time to time. Particularly ones with very technically sharp but unwise founders. That said I think that investing in a minimal, quick and dirty CD system can be valuable for very early startups that need to move very fast on the road to product/market fit.

raverbashing 6y ago

This this this Ship it I don't care if you're installing it by retyping the code into your server (hyperbolic example, sure), but ship it. Can you get payed? Can the customer use the product, even if it's a basic version? Ship it The rest is fluff. Of course do worry about them, after you start having money go into your bank account.

xupybd 6y ago
I've had to clean up from this once the product matures into maintenance mode. It's fine to start this way but people have to realise they will need to put some structure in place. At some point you'll struggle to get new features out on time without a ton of bugs.
- raverbashing 6y ago
  Yes, I agree. But it's easier doing the structure while you're getting money in the bank.

hinkley 6y ago

Customers pay for velocity. You can get velocity by installing a freight elevator, or by jumping off the side of the building every time. Tooling is tooling, not a religion. But if you've ever looked at the regimen of an elite professional athlete, you'd be hard pressed to discern it from a religion. It is necessary, but insufficient, and I don't think most people get that.

nikanj 6y ago
I was more talking "We don't have a single customer yet, but we have an industry standard set of redundant freight elevators, with automatic load balancing and travel optimization" versus "We have 120 paying customers, and still take the stairs".