Comment by luu | Hacker News Reader

Comment by luu | Hacker News Reader

This is timely, as I’ve just gone through the worst onboarding I've ever experienced. It took two very long days to install an OS on a machine and get it to boot (I had to assembly my computer and then use the corporate installer, which failed multiple times with errors like “an unknown error occurred”). It then took me about a week to run the local project’s “hello world” (I was initially pointed to documentation that had been deprecated for months, and then when I found the right documentation it was incomplete and out of date). The actual process to get there was hilariously baroque; for example (if my email records are correct and I didn’t get duplicate emails from the system), I must have clicked through 18 EULAs to get a subset of the permissions I need. I promise, that’s worse than it sounds since the form to do so took more time to click through than you can imagine. It was a month before I could effectively do any work at all.

I originally thought that I was just unlucky, but when I asked around I found that I had an above average experience, at least among people near me who started recently. Unlike many other folks, I was actually able to get a username/alias, a computer, and an office. I don’t know what folks without a username do since they can’t even start clicking through the necessary EULAs to get permissions to do stuff, let alone do any actual work.

I’m not sure how it is in other parts of the company, but if you imagine that it’s similar and do some back of the envelope math on how many people get onboarded and how much losing a month (or more) of time costs, it comes out to N million dollars for a non-trivial N. And that’s just the direct cost of the really trivial stuff. It’s hard to calculate the cost of the higher level stuff that’s mentioned in the article, but I suspect that’s even more expensive.

So your all individualy developing locally on your machine instead of on a server that you all use? - I think that's your problem right there

I'm curious, what subset of the software development world are you working in? "Developing locally on your machine" is and has always been standard practice in every part of the industry I have encountered.

Every project I worked on at BT (15 years) and all the webdev work it makes no sense to have 20 different pcs all developing and trying to merge the code at the end.

You remove the risk of subtle differences between developers pc's

if your only developing standalone apps I could see it but Microsoft doesn't develop windows or office that way.

Perhaps I just don't understand what you're describing, because in my experience it is completely normal to have developers working on 20 different PCs and all merging code as they go - that's what version control systems are for! I can't really imagine how else you would do it. Do all the devs really mount a shared filesystem with a single copy of the code!?

Or do you mean that the devs all still have individual copies of the source tree, but they do all their work by remoting in to some big monster server and building/testing there? That sounds.... um.... ungodly slow. Though I suppose if you are talking about webdev, perhaps there is no build step, so it might not suck quite as much...?

It sounds like a very different world, and I'm struggling to understand what you mean.

I never worked on Windows or Office, but I did work in devdiv for a while, and at that time Microsoft certainly did develop Visual Studio in the traditional way. There were build farms, to be sure, but they were used for occasional checkpoint builds and for testing. For daily work, we ran the ol' edit/compile/link/run/crash cycle locally, on our own dev machines.

You can have your own source control at the server level and every one logs into that server just run an X Server on your PC. And yes you should be developing on exactly the same hardware its going to run on.

All you need to set up a new user is a bog standard pc and a new account set up on the server.

Its a lot easier to keep dev test and live identical than 20 or so developers pc's

And even when we did local development (oracle forms) all the code was checked in to a central server which was used to produce a daily build.

How do you think IBM mainframe development is done?

Thanks for explaining. That's certainly a very different way of working from anything I've ever encountered. I don't know enough about mainframes to even wonder how things are done, it simply isn't part of my world at all.

I come from a personal computing background, where it really doesn't make sense to talk about "developing on exactly the same hardware it's going to run on" because you cannot know in advance what that is going to be. The kind of thing you are talking about makes even less sense in the embedded world, where cross-compilation is the rule and the target machines are likely not capable of self-hosting a toolchain at all.

I actually think those subtle differences are more likely to bring problems to the front earlier. If you have code that works on 20 slightly different setups, then it is likely to be more robust than code that has only ever seen one setup.

Obviously this is quite subjective, and depends a lot on what type of development you are doing.

What do you mean when you say develop on a server? Do you actually remote in and do development via commandline? Do you edit the files locally and upload it back? Do you run a remote desktop with gui?

If one person accidentally saves a file that has a syntax error or something, does it crash the server for everyone?

What tools do you use for development?

sccs or pvcs normaly

Reply on news.ycombinator.com