Live data from Hacker News

The importance of local development

fastpaced.com

61–70 of 94 posts

Re: The importance of local development

#62
Imho this is a problem with many DevOps pipelines - we use Azure DevOps and the inability to run the Azure pipeline yaml files locally means I end up just writing all our deployment as PowerShell scripts and the DO pipeline just calls them.

Local deployment is not negotiable.

And I still come back to Spolsky's "Joel Test": there must be 1 command with no extra steps that you run to get running version of the software on your local developer machine.

Re: The importance of local development

#63
post #50

At my work senior leads and architects always shoot down being able to develop locally, especially when devs bring up wanting the capability. The critique is some variation of “it would be impossible to run all services locally” or “it would be too expensive.” So we develop the code and deploy into QA, often breaking things. Cycle times are measured in hours to days. Breaking QA is sometimes a fireable offense. Lol.…

Wow that sounds like the absolute worst. My condolences. In projects I manage I even try not to use containers for the service being developed. (Only for its dependencies.) Everything that affects cycle times must go. That being said, you should also have a dev environment. QA isn't for development. It'll certainly be cheaper than firing people.

Right? I do the DevOps/architect stuff at my org and one game changer for testing was configuring it to spin up a separate instance per pull-request. Occasionally things get wonky because all the PR instances share an authentication/authorization server, but by and large it is excellent for being able to quickly demo.

But it does mean that you have to be religious about building links and connection-strings in your code.

Re: The importance of local development

#64
post #9

Earlier quoted context omitted.

What about local development precludes having a consistent, repeatable development environment? At worst you can distribute an environment the same way you would on the cloud.

In practice, the number one way to bungle a previously-working local environment at many of my past roles has been "brew upgrade". The number two way was to have MacOS and at least one Linux distribution used for local dev on the same team, but one vastly outnumber the other. While I am very pro-containers as a deployment target I am also very resistant to containers in the critical feedback loop of local dev, chiefl…

I firmly believe MacOS and linux should be considered as different as windows and linux from the point of view of platform support. If the only time your software runs on MacOS is during development, you're probably wasting your time supporting another platform, and your developers are never developing against the target. "It's POSIX so it's the same" is a lie in basically all the ways that matter, you'll have a much easier time with a VM (by which I mean developing in the VM, not building a whole new VM/container in your development loop)

(And I don't think I've ever seen a dev macOS setup that could be called clean, but it's been a long time since I've interacted with that, so maybe the situation has gotten better since then)

Re: The importance of local development

#65

There are lots of reasons to want a robust local development environment, but a paved path or sometimes even the possibility of "consistency between environments" is not one of them dear sir or madame. The JankStack in which one piles Python environment jank on top of Ubuntu/Darwin jank, and piles Docker jank on top of the previous, and piles Docker Compose jank on the previous, until you finally arrive at Jank-As-A-…

I get the "stacking jank but then it's different in thr cloud", okay, but what's the remedy? Are you talking about Nix, since you mention DLLs?

Simplicity.

Re: The importance of local development

#66
post #37
post #23

Earlier quoted context omitted.

I find it irritating when a program's compile time is perceptible. In compiled languages, TCC (Tiny C Compiler) was the only one that came close, though it doesn't seem to be great for production use. This made me switch back to JS and Python. The frictionlessness of "I made this change and I see the result in the same breath" is very compelling to me. Fortunately there are fast TypeScript compilers now, which make t…

I view JS as necessary because of the Web but honestly I don't like doing Python for anything serious because it's a dynamic language and I don't want to write unit tests for spelling mistakes. I realize it's the tool of choice for AI/ML/DS (for good reasons). But I'm with you on fast compilation and at Google this was the case, even with C++. There was a ton of infrastructure made around this that wouldn't be easy t…

You don't need to write Python unit tests for spelling mistakes. A good IDE will highlight them on the fly, and static analysis tools such as pyflakes or pylint will flag them on demand.

Re: The importance of local development

#67

At my work senior leads and architects always shoot down being able to develop locally, especially when devs bring up wanting the capability. The critique is some variation of “it would be impossible to run all services locally” or “it would be too expensive.” So we develop the code and deploy into QA, often breaking things. Cycle times are measured in hours to days. Breaking QA is sometimes a fireable offense. Lol.…

I have also seen a prohibition to have a local copy of the code coming from cybersecurity guys worried about laptops being compromised, for example, through an email with a malicious link. "Here is a web-based editor; please develop everything there, and at the bottom, there is a terminal to run your application," they say.

Re: The importance of local development

#68
post #59
post #15

Earlier quoted context omitted.

Two thoughts: * in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production. * building a cloud-based development…

If you've never seen good developers bork their local environments then you clearly haven't worked on a large enough and complex enough project. I worked on a large project that needed to support development on many platforms. The amount of scripting for the git hooks and build hooks alone required its own development team. When subtly incompatible changes in git hooks rolled out, you would see a few people that ran…

Note that I’m specifically referring to breaking it in a way which is significantly harder to recover from than rerunning a known setup process (Simon’s comparison to a cloud environment where you could reset it on-demand). It’s not about never making mistakes, it’s about having a good conceptual understanding and habits around configuration management.

Re: The importance of local development

#69
post #63
post #50

Earlier quoted context omitted.

Wow that sounds like the absolute worst. My condolences. In projects I manage I even try not to use containers for the service being developed. (Only for its dependencies.) Everything that affects cycle times must go. That being said, you should also have a dev environment. QA isn't for development. It'll certainly be cheaper than firing people.

Right? I do the DevOps/architect stuff at my org and one game changer for testing was configuring it to spin up a separate instance per pull-request. Occasionally things get wonky because all the PR instances share an authentication/authorization server, but by and large it is excellent for being able to quickly demo. But it does mean that you have to be religious about building links and connection-strings in your c…

Once you have 3 environments (which IMHO is the minimum viable number: dev, staging, prod), it tends to be much easier to generalise that to N, at least from the application side (spinning up the extra infra is a separate beast). It tends to weed out many of the "if (prod)"s because there should now be differences between dev & staging that you need to take care of, and sprinkling elaborate switch statements gets tedious really fast - most devs tend to be happier actually simplifying code.

I've seen some really nasty offenders though, e.g. actual business logic hidden behind an "if (window.location.hostname == ...)". Sometimes it takes a lot of patience to explain that this is how you get production-only bugs that QA will never have a chance to find or reproduce.

Re: The importance of local development

#70
post #19

I'm fighting with a variant of this right now - Attempting to build a multiplayer game with dedicated servers & master server authority. I've got 4 computers involved to run the full dev iteration (2 for 1v1 clients, 1 for master server and 1 for dedicated server host). The clients I am running in my local LAN with both servers in AWS. Attempting to do all of this on the local machine will mostly work, but it fails t…

Have you seen https://github.com/Shopify/toxiproxy ? Maybe you could use this / similar setup to test with more realistic network behaviour.

I am using UDP transport so options are fairly limited.
Post reply on HN