

"How hard can it be to implement?" - adamhowell
http://answers.37signals.com/basecamp/52-how-can-i-move-or-copy-to-do-lists-between-projects#reply_6986

======
thisisnotmyname
Is there really no simpler way to solve this problem?

"Moving a message needs to move all of the message's comments, and all of the
comments' files, and all of the comments' files' versions."

Why can't you just change some top level reference in the database? I'm
imagining a Projects table and a TodoLists table. Each TodoList has something
like a projectID foreign key right? Why can't you just change that and
automatically have all of the messages, etc, come along with the TodoList?

"But I hope you will see that sometimes even the simplest feature can be much
more complicated than it looks from the outside."

I agree there, just wondering why the simple solution doesn't work in this
case.

~~~
dasil003
You're falling into the same trap all programmers do when they perpetually
underestimate the time to accomplish any task. The main difficulty in
estimating time is that you don't know what you don't know, so you have to
actually get into the nitty gritty of implementing it, and if you're smart
enough you'll hopefully catch all the requirements before you actually launch
it.

I'm going to take Sam's word on this that there is _not_ a simpler way,
because he's the one working on it, and I trust the competence of the 37s dev
team. That's not to say that some armchair analysis here on HN might not have
valuable insight, but without actually seeing the code, and in light of the
full list of points Sam mentioned, I doubt very much that there is a much
simpler solution of any form.

~~~
DougWebb
_> The main difficulty in estimating time is that you don't know what you
don't know, so you have to actually get into the nitty gritty of implementing
it, and if you're smart enough you'll hopefully catch all the requirements
before you actually launch it._

That's certainly true for a low-level, high-precision estimate, which you can
only make when you've got detailed requirements. Prior to that you still need
to be able to deliver an estimate, and the best approach to take is to provide
an estimate with Quantified Uncertainty. The phrase is important, because the
estimate is for managers and managers are all about quantifying risks, and
uncertainty in a development estimate is definitely a risk.

When you say "I don't know how long this will take, because I don't know how
much I don't know about the solution" you're giving an estimate with
uncertainty, but you're not quantifying the uncertainty. It's got no bounds,
it's limitless. Managers can't make any decisions with that, so it's useless
information. But if you say "This will take 4 to 8 effort weeks, and I'll be
able to give a more precise estimate after 2 effort weeks of investigation"
that gives your manager something to work with. You're still uncertain, but
you've quantified the bounds on the uncertainty, and decisions can be made.
For example, solving the problem might not be worthwhile unless it happens
within the next two weeks (eg: to meet a release deadline) so the manager can
just delay the work until later.

The trick with this approach is setting the bounds. The man who taught me this
style of estimating called it a Surprise Range. The lower bound should be an
estimate such that you'd be surprised if it took less effort than that, and
the upper bound should be an estimate such that you'd be surprised if it took
more effort than that. Given whatever information you have about the
requirements, you just keep pushing your bounds until you can honestly say "I
really don't think it would take less/more effort than that."

As you get more experienced, you'll naturally start accounting for the unknown
unknowns, because your past experiences with them will be nagging in the back
of your mind while you're trying to come up with an estimate for some new
task. This is especially true if you're estimating work on a project you've
worked on before; you'll have a feel for where the trouble spots are and
whether or not the task in question is going to get into those spots.

The other trick with this approach is the "more precise estimate after some
investigation" bit of the statement. You need to provide some estimate now,
buy some investigation time, and commit to another estimate later. Most of the
time the second estimate will fall somewhere within the bounds of the first
one, but not always, and your manager should be aware of that possibility. But
with experience, you'll usually wind up within the original bounds and
narrower than the original bounds too, which is quantifiably less uncertainty
than before so you can show progress.

~~~
JoeAltmaier
Company wanted to port an OS to 32-bit (yes I know that dates me). I spent a
day, reviewed the code (500 modules), wrote a report - two manyears. Project
deferred (ashcanned).

A month later my peer, a senior Engineer with the Company, thought "We should
run 32-bit! How long can it take?", checked out the source and started
changing files. Gradually people noticed what he was doing, resources got
added under the table, finally a year later he had something working. Lots of
kudos, smiles, what a hero!

I showed him the report I filed a year ago - and he said "yeah, that's about
what I had to do. I'm glad I didn't see that to begin with, I would never have
started".

~~~
DougWebb
Two man-years can easily become one calendar year, if 2-3 people are working
fulltime on the project.

Also, "two man-years" isn't a complete estimate using my approach. "One to two
man-years" would be a complete estimate, providing a range. Sometimes you
really do come in near the bottom of the range, and maybe a month into it if
you re-estimated you would have come up with a lower range.

------
tomafro
The comments here remind me of an old Irish joke where a hopelessly lost
tourist asks an old man by the side of the road "Can you tell me how to get to
Dublin?". After a few minutes thinking, the man replies "Well, you don't want
to start from here".

I doubt 37signals wanted to be in a place where an apparently simple change
would involve so much work, but that's where they found themselves. They did
what they had to do. There's no point snarking about their starting place
without knowing how and why they got there.

~~~
bambax
Is this an old Irish joke? I thought I knew for a fact that it was French!

\- "Pouvez-vous me dire comment aller à Paris"? \- "Ben si j'étais vous je ne
partirais pas d'ici!"

Very French in its non-helpful but matter-of-fact way... but maybe the Irish
are the same!

~~~
tomafro
Your French version feels authentic to me, but then so does the Irish one. I
doubt one can say where jokes like these originate. All cultures and languages
probably have versions of them.

~~~
smithbits
The way I heard the joke in Vermont always involved a tourist asking an old
farmer for directions and getting the answer "Well, you can't get there from
here."

------
fleaflicker
I frequently quote the way Joel phrased this:

 _If you've spent more than 20 minutes of your life writing code, you've
probably discovered a good rule of thumb by now: nothing is as simple as it
seems._

<http://www.joelonsoftware.com/articles/NothingIsSimple.html>

------
Groxx
Sounds like they're in need of some hefty normalization. This is the sort of
thing that _should_ be handled by changing a single foreign key on each todo /
on a single todo list entry; everything else should be pointing to each
individual entity, and need no modification.

Unless they're denormalized for optimization purposes? Threaded comments can
result in some massively deep queries.

~~~
richardhenry
> Unless they're denormalized for optimization purposes?

Bingo?

------
mpk
Though not directly related to this post, the sentence 'well ... how hard can
it be?' is a signature quote from the lead Top Gear presenter.

This almost invariably leads into a challenge that seems easy in theory but
the practical execution is always plagued with unforeseen hurdles, crap,
unexpected mishaps and other random elements.

It's not that hard to draw parallels between software development and the
crazy Top Gear challenges, which is probably a reason that many coders who've
never been behind a wheel enjoy watching them.

------
mkramlich
if I were to sum up the counter-reaction to a lot of folks here who think that
the claimed difficulty is too high:

You're right, under the right conditions. Namely: small site, early in
lifecycle, and a perfectly normalized and non-sharded/non-partitioned
database.

But I suspect it's more complicated because:

1\. they have a ton of traffic

2\. they want to maintain a seamlessly perfect UX everywhere

3\. their database is denormalized, sharded and/or partitioned

plus possibly:

4\. it's gotten at least a little crufty with age ( _shrug_ , it happens)

------
mkramlich
Great post but note that the total complexity/LOE of adding that feature would
be significantly reduced if (1) it was delivered earlier in the app's
lifecycle (less users, simpler code, lower expectations, less/no customers,
etc), and/or (2) quality/UX standards were relaxed somewhat.

I agree that even a seemingly simple feature can be hard to deliver, but on
the flip side there are dials a developer can turn to adjust his LOE up or
down as desired. Tradeoffs as always.

~~~
josephholsten
> quality/UX standards were relaxed somewhat

Yow.

~~~
mkramlich
why "yow"?

~~~
wmf
Quality and UX appear to be what 37s is selling; if they skimped on that
there'd be nothing left.

------
richcollins
This would be easy in a graph db. Just move the node and its children come
along for the ride.

~~~
josephholsten
Not exactly. If you look a bit closer, you'll see that this isn't just a
strict child, otherwise they might have managed by swapping a foreign key or
something. In a graph db, you'd still have to reconnect dangling edges that no
longer make sense, like for comments and users. Also, the transaction rollback
issue. Which is to say: tanstaafl.

~~~
nawroth
Doesn't need to be a strict child when using a _graph_ (not to confuse with
hierarchical) database. Not sure what you mean by dangling edges, at least the
Neo4j graphdb guarantees that edges are always connected at both ends. It's
also ACID compliant so rollbacks are supported. Sure, tanstaafl, but when
dealing with data in a graph structure there's much better tools than RDBMS
nowadays!

------
eterps
<http://www.w3.org/DesignIssues/Axioms#opaque>

------
edanm
In the same vein, I highly recommend the article "How many Microsoft employees
does it take to change a lightbulb?". This was features in Joel Spolsky's "The
Best Software Writing 1"
([http://www.amazon.com/gp/product/1590595009?ie=UTF8&tag=...](http://www.amazon.com/gp/product/1590595009?ie=UTF8&tag=thtaofco0a-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1590595009)).

Link to article:
[http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298...](http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx)

~~~
nostromo
Nice affiliate link. ;-)

