The Two Week Problem
openshift.redhat.com
The Two Week Problem
1–10 of 30 posts
Re: The Two Week Problem
#2If your software really takes two weeks for an individual to configure and install, then perhaps you should look into providing a script or even a virtual machine image to automate the process. The strawman argument weakens the overall message that the author is trying to convey.
Re: The Two Week Problem
#3So we should develop software on a development server. What a crazy new idea.
There's these new things called "remote X11 displays" that might revolutionize the way we work on remote servers from local computers. If only it ran in a browser[1], though!
[1] http://lifehacker.com/287085/control-tightvnc-from-the-web
Re: The Two Week Problem
#4If your software really takes two weeks for an individual to configure and install, then perhaps you should look into providing a script or even a virtual machine image to automate the process. The strawman argument weakens the overall message that the author is trying to convey.
The other possibility is developers are given a computer that's in a locked down jail cell state. But pointing this out (and other configuration scenarios) distracts from the central idea: developers battle configuration hell because our processes are disconnected from each other. It's more than a configuration script, this is about solving a bigger problem. Think of remote development too and collaboration, this is something we can solve with cloud tooling.
Re: The Two Week Problem
#5What if someone prefers a different editor?
Re: The Two Week Problem
#6So we should develop software on a development server. What a crazy new idea. There's these new things called "remote X11 displays" that might revolutionize the way we work on remote servers from local computers. If only it ran in a browser[1], though! [1] http://lifehacker.com/287085/control-tightvnc-from-the-web
Cloud9 does at least have an offline mode; so one isn't totally hosed if you're not connected or they go down. Granted, you can't actually run much, but it's still better than your entire display locking up if the network flakes out.
Re: The Two Week Problem
#7It was hard for me to get past the 'two week' problem being the opening argument for this. It has never taken me 2 weeks to get any machine configured and ready to go. I agree with cmwalsh in that this drastically weakens the overall message. The only reason I continued past the 2nd paragraph is because this was linked from HN. My initial response would normally be "Who really takes 2 weeks to configure a machine??" and then move on to something else worth reading.
Re: The Two Week Problem
#8It was hard for me to get past the 'two week' problem being the opening argument for this. It has never taken me 2 weeks to get any machine configured and ready to go. I agree with cmwalsh in that this drastically weakens the overall message. The only reason I continued past the 2nd paragraph is because this was linked from HN. My initial response would normally be "Who really takes 2 weeks to configure a machine??"…
I've seen that happen, but only due to some exceedingly bad environmental and architectural issues. Poor SVN management was the chief problem - there were around 100 interdependent repositories that had to have certain versions built and linked in as libraries depending on what you'd actually be working on.
Hiring a new person and finding that literally nobody could get them set up to develop in a reasonable time frame led directly to cleaning those issues up.
Re: The Two Week Problem
#9What if someone prefers a different editor?
This is the weak link imo. The entire premise is that variance in developer preferences of environments is what leads to problems, but editors are where preferences tend to vary the most. If you're an open enough shop to not standardize systems, your devs sure aren't all going to want to be locked into the same editor.
In fact I'd guess most devs would be willing to sacrifice environment choice for editor choice if it came to that.
Re: The Two Week Problem
#10I think this is probably a problem more with new developers vs seasoned developers. I've noticed that configurations woes plague people who haven't got to a point where they have already configured their environments to their liking tens of times. i can get a machine configured for development use in a few hours and be productive the next day. Why? Because I have a repo of all my latest dotfiles including my vim plugins and configs. I also have a list of software I need to download the moment I use a new machine in my 1Password notes. Lastly I have another note with all the stuff I usually change in OSX and Linux. I've even been thinking lately about make it even more streamlined by having scripts actually do all my work.
To get up to speed with my developing environment, I just need to sync a couple of dropbox folders on my dev machine, checkout my repos, or bring a usb (if not allowed to dropbox sync my stuff, in which case I'd really consider getting a job where I'm not limited by stupid policies that make little sense for developers) with my latest configs. Lastly I might spend a day configuring the companies environment architecture (svn I'm looking at you), but even in the worst situations this things are generally trivial.
For a developer, his machine should be free to configure to his liking as long as security constraints are taken into account. If the developer can't be up and running with his environment in a few days, he's either not experienced enough or the IT department utterly sucks. Generally, it's the first option.