
The Two Week Problem - mattpardee
https://openshift.redhat.com/community/blogs/solving-the-two-week-problem-by-developing-in-the-cloud
======
lubutu
I've wondered about the "two week problem" in the context of large open source
projects. It would be great if a developer could spin up, say, a temporary VPS
for Chromium development, the toolchain all set up and source ready to modify.
I can't be the only one with a pet bug that must be trivial to fix, but the
overhead of setting up a whole new toolchain to do so is just not worth it.

~~~
saurik
I was able to get Chromium compiling on my laptop (2010 MacBook Air) in a few
hours using one of the tutorials on their Wiki. Most of my time was spent
waiting for things to download and compile. Why would you need a VPS setup? If
you want to do it in the cloud, isn't AWS enough?

------
sp4rki
I 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.

~~~
rdw
If you're an experienced developer, but the project you join requires a
different toolset and/or set of executables than a previous one, then it'll
take you a good while to get up to speed on it.

E.g. you've got Visual Studio the way you like it, but the new project has
different code organization and code conventions and requires a different
version of C++. You were developing for Android on Juno and now you're using
GWT on Indigo. The libraries aren't checked in, and also Bob built them
himself because he wanted to patch the logging library. The build system
depends on ActiveState Python 2.5, it breaks in subtle ways if you use another
distribution or version, but no one can tell you because they just all happen
to have installed their copy when that was the latest.

[Remembered another one: we're using a library, but it's broken, and the
workaround involves setting up absolute paths to a number of files in your
user directory, and no one has a complete set of the necessary because we're
all working on a different subset than you.]

A repo with dotfiles ain't gonna help you with any of that. I suspect that
these scenarios describe the vast majority of development environments by
quantity. It's a luxury to have your build environment be describable by a few
text files whose location are known rather than bundled up in binaries,
Windows Registry entries, and cargo-culted tribal knowledge. Yes, that's a
horrible state of affairs, but to point the finger at "new developers" is to
miss the point.

~~~
sp4rki
I agree that sometimes a new job might bring into light a toolset you;ve never
used. I've never taken more than a day or two to get everything up to speed
though. Interestingly enough, after being a unix guy for more than 10 years,
my latest job required me to use visual studio. My first commit was three days
after I started. This days I even have a file with all my VS configuration.

You also gave a perfect example of the only case I explicitly said you
shouldn't point the finger to "new developers", which is when IT - or even the
senior developers - are at fault for having a crappy development environment.

------
msurel
It 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.

~~~
boomzilla
You never worked with a service oriented environment, right? When you need to
override dozens of services your build/local instance depends on, it could
easily take a couple of weeks, especially for fresh graduates who used to
"./configure && make && sudo make".

~~~
Evbn
Why don't your configuration files have service client configs on them?

Does it take two weeks to deploy a build to a production machine or the
integration test farm? No. Then why would it take two weeks to pushh the code
to a dev machine?

------
cmwelsh
If 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.

~~~
mattpardee
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.

------
peterwwillis
So 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>

~~~
ConstantineXVI
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.

------
ecopoesis
The problem is actually that most software projects are too complicated to
setup. This is a kind of technical debt created by bad developers who think
their job only involves coding, not maintaining the entire lifecycle of code.
I bet these shops also have hard to reproduce builds and deploys that require
dozens of human steps.

If your new dev process isn't some close variation of:

1) Install IDE 2) Checkout code from repo 3) Run dev environment setup script
4) Open project in IDE

then you're doing it wrong.

~~~
MattRogish
Absolutely. Development projects should have a repeatable, automated-where-it-
makes-sense setup.

A few things I do at my company to make sure:

* give developers a new machine every 12-18 mos (depends on Apple refresh cycles). Forces everyone to install it fresh, and fix any dependency/install bugs to be fixed

* all new dev hires must have it running and have deployed a change on their first day.

* encourage graphic designers, QA, and other folk to get it running locally for testing and the like. The install script and docs must be super clear so it allows them to install it with minimal hassle

I was using Vagrant for this, but ultimately it didn't provide enough value to
outweigh the overhead and hassle. A shame, but I think they are on the right
track with their approach. Just needs a lot more polish in my opinion.

~~~
cglace
Just curious, how was using vagrant a hassle for you? I've always found it
really simple to use.

------
neilk
Misko Hevery (author of AngularJS) wrote a good blog post about how if you
pair with a new hire for a day, you can bring them up to speed almost
instantly. I tried it and it works - my new hires were committing real fixes
by the end of day one.

[http://misko.hevery.com/2009/06/12/what-pair-programing-
is-n...](http://misko.hevery.com/2009/06/12/what-pair-programing-is-not/)

An additional benefit is that the experienced and more senior developer will
also have to endure the pain of setting up, and the undocumented parts, and
may even fix them.

However, if I was looking for a technical fix, I think using Vagrant is far
better than anything cloudy. The cloud is a tradeoff - you get the benefits of
virtualization, if you accept the downsides of it being all remote. The OP's
solution doesn't even allow you to choose your editor! Vagrant gives you all
the upside and none of the downside.

~~~
JamesLeonis
I love your linked article because it addresses the intangibles of imparting
the mental model of the code. Many times this is the delay when a new
developer comes into an existing code base. While scripts and cloud tools can
reduce or eliminate the configuration overhead, the programmer still needs to
understand what the actual code is doing.

The last company I worked for had this problem initially. There were multiple
layers of software that needed to be built and configured just so. If there
was a problem with your build, it would take an hour to get and build
everything from scratch if things went without a hitch. They often didn't.

This changed once we started using a build server and automated builds. This
made a complete build script necessary. The benefit was that script could be
used to both spin up a new dev environment (except for installing IDE and
local database servers), and syncing the dev machine. Every morning I would
run this script and let it chug along while I went to my standup and/or read
my morning email.

I think an automatic configuration script combined with the pair programming
idea, even if the programmers are paired for a day, would greatly speed up the
new dev up the learning curve and allow them to be productive faster.

------
hoffmanc
What if someone prefers a different editor?

~~~
agpen
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.

~~~
Evbn
Or provide the five or so editors all. In a Unix shop, emacs, vim, eclipse,
acme, and sam, with the popular plugins the current team members use, should
satisfy almost everyone to get started.

------
zaphar
Maybe it's just me but I find the two week problem to be less about
configuring my dev environment. Give me a sufficiently unix like box hg and
I'm configured in less than 5 minutes.

It's more about getting up to speed the system I'm developing on and I have
difficulty seeing how that can be properly abstracted out into a general
solution.

Oh and of course the obligatory "You can have my emacs running evil-mode when
you pry it from my cold dead hands".

