Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Maybe throw in a rule that devices are recycled (to be wiped) frequently, say every 6 months.

That would be doable if setting up devtools at most places didn't take an entire day.



An entire day?

I’ve seen it where it was EXPECTED that it normally took THREE WEEKS or so for a developer to have the set up correct to be able to develop the application they were hired for.

It was a Java web app. Not some weird special embedded hardware or something.

The app was just that (pointlessly) complicated to set up. Even in production it took quite a while despite being automated buy and installer and people having lots of experience installing it.

Edit: sorry about the duplicated text. I’ve fixed it.

I’m not a Java hater, I am in Java developer. I actually like the language. But the way this particular app is designed and configured, along with the Extertal systems that had to be reconfigured to be able to run at (which could have been eliminated) meant that setting up the system for developmental just took a ton of trial and error.


In a previous job I was asked to use a configuration management tool to automate setup and installation of a development environment. (Never did it though.)

This would have been easy on a Linux desktop: installing Java, Maven, an IDE, and changing some settings files for the corporate proxy and artifact repository etc is very basic for Ansible, Puppet or Chef. It's probably achievable on Windows or OS X, although I'm not sufficiently familiar with them.

Heavy customization of the IDE could be trickier; the configuration system doesn't necessarily stay very stable between releases. Maybe something that's part of a larger, well-designed system, like KDevelop, would be easiest.


The first choice strategy obviously would be to automate this stuff.

Because it's hard to mandate a flag day where everything must be automated, a transitional strategy might be: document each dev setup so well stepwise that you can outsource it to the IT dept or other internal support org. Maybe the dev team can provide a screencast of it, for example. The support org would then have an incentive to automate it to replace manual work, along with a measurable payoff for it.


NO! now the automation has to be maintained and set up. The first choice strategy is to simplify the tools and application!

Always with software people there is this tendency to add more abstraction and machinery when encountering complex abstractions and machinery. You only exacerbate the problem by doing this!


Containers help solve this, no?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: