6 ms·

What I like most about some experienced engineers who have been at companies from the beginning is that they realize the needs of a small-team, cash-constrained

by amgreg 6y ago

What I like most about some experienced engineers who have been at companies from the beginning is that they realize the needs of a small-team, cash-constrained, rapidly growing company are different from that of a dozens-of-teams, complex, but also rapidly scaling enterprise. The devil is in understanding when and how to transition your tooling, architecture, and — dare I say it — attitudes, from the one to the other. I am curious to hear more from these engineers; how decisions were made about transitioning/scaling; and what decisions were made.

jacquesm 6y ago
This comment is gold. Yes, that's exactly it. Trying to use the tooling and processes that are a bad match for your situation is the way to waste a fortune or to end up being overtaken on the right by a competitor that made smarter choices.
thdrdt 6y ago
There are things that could (should?) be done from the start. Most has to do with automation. For example automated build tools. Maybe you don't want automated unit tests in the beginning but those parts can be added later without changing the company's culture and stucture too much. Or automated invoices. It is much easier to change this than changing a co-worker who manually created all the invoices.
- outworlder 6y ago
  > Most has to do with automation. This. Don't ever put anything into production that's not automated. Ever. "Oh it's a simple HTTP server that's going to be used by 5 people". Cool. Automate it. "Oh but it's going to take time!". I thought you said it was simple... When things are not automated, we treat them differently. If a server is not automated, now it becomes time-consuming to setup another, which means it's now a pet, not cattle. But if it is automated and is misbehaving, we can easily replace it (and save the current for troubleshooting later if necessary). Or we can spin up 100 of them. Same goes for development. If builds are not automated, they become more difficult to do, more error prone, which means people will avoid making contributions unless they are forced to do so (by some ticket). When contributing to a code base that has no guardrails becomes a lose/neutral proposition, people won't want to. And now it's been 5 years and it's difficult to automate things because there's a 100 different workflows that people use and you are going to break them.
  - deleted 6y ago
    [deleted]
  - tangjurine 6y ago
    What exactly do you mean by automate? Like the http server for example?
    - chromatin 6y ago
      Image building (eg packer, docker) and/or deployment (eg, terraform, ansible)
    - rudasn 6y ago
      Not OP, but I think s/he means automating the processes of provisioning servers (settings, common software), and deploying changes to your infra/code/apps.
    - deleted 6y ago
      [deleted]
    - jagtesh 6y ago
      Other examples: linting code, configuration, documentation, etc. Or updating a registry, release version somewhere, even sending an email/message to someone when something happens (a new client signs up, emails with a certain keywords). So many processes beyond development can be automated. SalesOps is very simply doing that for Sales teams (managing sales pipelines, distributing leads, generating reports). Marketing Automation has become its own field (targetted drip campaigns, now add another layer: account based targeting based on rules).
  - jagtesh 6y ago
    Yes, yes, yes. Just CI/CD alone has been a huge productivity boost for one of the teams I lead. The thing is, as you scale (50 people to 200+), people adapt to depend on processes rather than individuals. If the process is automated and well documented, you'll be have even more power to tweak the inner workings without retraining anyone. Like someone else said, even if it doesn't save you time, adding automation simplifies your processes and creates a powerful abstraction, which will come in handy when you do start hitting scaling challenges.
- spinningslate 6y ago
  > Maybe you don't want automated unit tests Interested why you'd say this, can you elaborate? Do you mean tests in general or unit tests specifically? I can't imagine automating a CD pipeline without having some automated testing as an integral step. If you don't have automated tests, how do you remain confident that you haven't introduced bugs/regressions? Even in a small codebase that's easy to do - especially when you're evolving quickly. Like I say: not tacit criticism, genuinely interested.
  - jayd16 6y ago
    You can have automated builds and manual testing and deploy. It goes a long long way, especially in a small team that's still prototyping rapidly.
  - kulig 6y ago
    You'd be surprised at the stuff thats out there. I work in a 200kloc code base that has maybe 5% test coverage. Critical bugs are very rare.
  - ralston3 6y ago
    I think the key point in the OP’s statement is “early on” I think unit tests (or just more generally a test suite) is invaluable. But when you’re starting out small (1-3 person dev team) and the API is changing so rapidly (we learned something this week we didn’t know last week so that new service now only does 1 thing instead of 5 things), tests can _really_ slow down development. And as mentioned by the OP as well, adding unit tests (or a test suite in general) shouldn’t be too hard once you get a stable API I might be preaching to the choir so to speak, but that’s just my $0.02
  - deepGem 6y ago
    As someone who has mostly written early stage software with 1 to 3 developers, the single most reason to skip tests is the rapidly changing APIs. Also it is ok to ship somewhat buggy code. Use case validation and speed trumps accuracy. Also invariably a lot of early stage code is in the front end and FE testing is very time consuming. What has been immensely helpful is an automated build and deploy system, which quite honestly is very expensive to build in the iOS world. I just want a one click deploy to a clean machine every time I decide to deploy. This is kinda trivial in the backend world using containers but not so in the iOS world.
ConradKilroy 6y ago
@amgreg, fantastic observation! "scalable attitudes"

by amgreg 6y ago

jacquesm 6y ago

This comment is gold. Yes, that's exactly it. Trying to use the tooling and processes that are a bad match for your situation is the way to waste a fortune or to end up being overtaken on the right by a competitor that made smarter choices.

thdrdt 6y ago

There are things that could (should?) be done from the start. Most has to do with automation. For example automated build tools. Maybe you don't want automated unit tests in the beginning but those parts can be added later without changing the company's culture and stucture too much. Or automated invoices. It is much easier to change this than changing a co-worker who manually created all the invoices.

outworlder 6y ago
> Most has to do with automation. This. Don't ever put anything into production that's not automated. Ever. "Oh it's a simple HTTP server that's going to be used by 5 people". Cool. Automate it. "Oh but it's going to take time!". I thought you said it was simple... When things are not automated, we treat them differently. If a server is not automated, now it becomes time-consuming to setup another, which means it's now a pet, not cattle. But if it is automated and is misbehaving, we can easily replace it (and save the current for troubleshooting later if necessary). Or we can spin up 100 of them. Same goes for development. If builds are not automated, they become more difficult to do, more error prone, which means people will avoid making contributions unless they are forced to do so (by some ticket). When contributing to a code base that has no guardrails becomes a lose/neutral proposition, people won't want to. And now it's been 5 years and it's difficult to automate things because there's a 100 different workflows that people use and you are going to break them.
- deleted 6y ago
  [deleted]
- tangjurine 6y ago
  What exactly do you mean by automate? Like the http server for example?
  - chromatin 6y ago
    Image building (eg packer, docker) and/or deployment (eg, terraform, ansible)
  - rudasn 6y ago
    Not OP, but I think s/he means automating the processes of provisioning servers (settings, common software), and deploying changes to your infra/code/apps.
  - deleted 6y ago
    [deleted]
  - jagtesh 6y ago
    Other examples: linting code, configuration, documentation, etc. Or updating a registry, release version somewhere, even sending an email/message to someone when something happens (a new client signs up, emails with a certain keywords). So many processes beyond development can be automated. SalesOps is very simply doing that for Sales teams (managing sales pipelines, distributing leads, generating reports). Marketing Automation has become its own field (targetted drip campaigns, now add another layer: account based targeting based on rules).
- jagtesh 6y ago
  Yes, yes, yes. Just CI/CD alone has been a huge productivity boost for one of the teams I lead. The thing is, as you scale (50 people to 200+), people adapt to depend on processes rather than individuals. If the process is automated and well documented, you'll be have even more power to tweak the inner workings without retraining anyone. Like someone else said, even if it doesn't save you time, adding automation simplifies your processes and creates a powerful abstraction, which will come in handy when you do start hitting scaling challenges.
spinningslate 6y ago
> Maybe you don't want automated unit tests Interested why you'd say this, can you elaborate? Do you mean tests in general or unit tests specifically? I can't imagine automating a CD pipeline without having some automated testing as an integral step. If you don't have automated tests, how do you remain confident that you haven't introduced bugs/regressions? Even in a small codebase that's easy to do - especially when you're evolving quickly. Like I say: not tacit criticism, genuinely interested.
- jayd16 6y ago
  You can have automated builds and manual testing and deploy. It goes a long long way, especially in a small team that's still prototyping rapidly.
- kulig 6y ago
  You'd be surprised at the stuff thats out there. I work in a 200kloc code base that has maybe 5% test coverage. Critical bugs are very rare.
- ralston3 6y ago
  I think the key point in the OP’s statement is “early on” I think unit tests (or just more generally a test suite) is invaluable. But when you’re starting out small (1-3 person dev team) and the API is changing so rapidly (we learned something this week we didn’t know last week so that new service now only does 1 thing instead of 5 things), tests can _really_ slow down development. And as mentioned by the OP as well, adding unit tests (or a test suite in general) shouldn’t be too hard once you get a stable API I might be preaching to the choir so to speak, but that’s just my $0.02
- deepGem 6y ago
  As someone who has mostly written early stage software with 1 to 3 developers, the single most reason to skip tests is the rapidly changing APIs. Also it is ok to ship somewhat buggy code. Use case validation and speed trumps accuracy. Also invariably a lot of early stage code is in the front end and FE testing is very time consuming. What has been immensely helpful is an automated build and deploy system, which quite honestly is very expensive to build in the iOS world. I just want a one click deploy to a clean machine every time I decide to deploy. This is kinda trivial in the backend world using containers but not so in the iOS world.

ConradKilroy 6y ago

@amgreg, fantastic observation! "scalable attitudes"