We just launched a new feature in Basecamp that allows you to move messages, to-do lists, milestones and files from one Basecamp project to another. You can read the full announcement on our product blog.
The UI we designed makes it simple to do. Just edit any message, milestone, to-do list or file in Basecamp, select the project you want to move it to, and click a button. Done.
It’s so simple that it’s easy to assume that adding the feature would be simple, too. Customers make this assumption and so do developers.
To put things in perspective here’s what you see after you click Move…
…and here’s what is happening behind the scenes:
- Is the item being moved a message? We’ll need to move any attached files with it. Does it have any comments? Move those, too.
- Do any of the comments being moved have their own attachments? Better move those as well.
- Are any of the files images? If so, we’ll need to move the image’s thumbnail, too.
- Are there multiple versions of the file? Bring those along.
- Does the message or any of the files have a category? Create the category if it doesn’t exist in the destination project.
- Is the moved file backed up on S3? We need to rename it there. If it’s not, we need to make sure it doesn’t get backed up with its old filename.
- Is the item being moved a milestone? Moving a milestone needs to move any associated to-do lists and messages. And of course those to-do lists can have to-do items with comments, and attached files, and multiple versions of those files. Move all of that.
- Is it a to-do list? It may contain to-do items that have associated time tracking entries. Move those time entries to the destination project too.
- Was anyone subscribed to email notification for the message? We’ll need to make sure they still get them on the new project.
- Similarly we need to make sure that when you follow a URL in an email notification for a moved message, comment or files, you are redirected to its new location.
- Ok, we gathered everything up and it’s moving. Is it done yet? Did it fail? We’ll need to roll it back if somthing goes wrong.
Oh and we need to show the user what’s going on…
Greg
on 08 Sep 10Yeah, real software companies deal with lists of complications like this all the time but usually they are much longer. Go back to your little pretend toy apps.
Matt
on 08 Sep 10Is that all? I thought there’d be more to it than that really
James
on 08 Sep 10Was this feature based on user demand or an internal one? I’m having a hard time seeing it used a ton but I know people use basecamp in many different ways. It would be interesting to know why this feature was put above others.
Evan
on 08 Sep 10Until this post I had no idea software was more complicated than it appeared to be. Thank you, 37Signals!
Jonas Schneider
on 08 Sep 10Huh? There is work to do when moving records with comments or other has_many or habtm associations?
Wait. No.
Jonas Schneider
on 08 Sep 10By the way, the preview button posts the comment.
chriskalani
on 08 Sep 10What happens if that project doesn’t have the same users. How are the comments handled then??
Scott
on 08 Sep 10I’m not sure that developers think it’s simple as much as they think that what you consider unusually and notably complex is similar (or smaller) in complexity to the work that many or most software developers address and solve every day.
Jason Clark
on 08 Sep 10I’d love to hear how many hours this specific update took.
JZ
on 08 Sep 10@James – Both.
@chriskalani – It handles it pretty much like it does with a deleted user. They still appear as the author of the comment, but they don’t have access anymore.
@Scott – It’s not that developers think it’s simple, but more that it’s simpler than it is. We couldn’t have (and didn’t) anticipate all these scenarios at the start. It was only after we were working on the project that they revealed themselves. You can’t fully understand the project until you’re working on it.
MMAS
on 08 Sep 10People complain about their easy jobs way too much, methinks.
Tyler
on 08 Sep 10Ah, comment trolls. You’d be surprised how many people have no idea how complex “simple” features are. Even this bulleted list is hugely summarized (I’d expect another 50 sub-bullets of logistics, testing, and support/system admin concerns behind each summary bullet)
Looks like a useful feature well executed. Bravo.
Evan
on 08 Sep 10@Tyler I’d guess that many readers of this blog are developers themselves and would likely not be surprised by that perception. I guess the 37s guys were surprised because they don’t believe in planning. The rest of us expect that adding features to an existing product is more complicated behind the scenes than what is apparent in the UI.
Mark
on 08 Sep 10Any of you developers ever think that maybe this was posted as a marketing piece for those who aren’t?
Jeffrey R.
on 08 Sep 10Thanks for this little vignette into the complexity of a seemingly simple task. I noticed that the majority of comments have been somewhat…jaded so far.
I for one appreciate the care it took to compile this list and how well it illustrates that even with the basic tenants of 37s (keep it simple, choices mean complexity, just do it) that a simple feature still takes a lot of care. It also shows that linking to a file (like linking to Milestone) may be pretty useful. As I know that I often post pointers to files I have posted to a project (which will now need to be redirected).
I am curious if you even attempted to move references to files that are stored by the customer…?
Jake
on 09 Sep 10Wow, I’m really gobsmacked at the comments here. Do those posters talk like that in real life? I’d punch anyone like Greg up there.
Stacy
on 09 Sep 10This is what happens when you “release early, release often” without any, or little, upfront planning – with the goal of getting quick customer feedback. Your app grows into a big ball of mud – making it very difficult, if not impossible, to change things down the road.
john
on 09 Sep 10Greg: Based on your comment - “Yeah, real software companies deal with lists of complications like this all the time but usually they are much longer. Go back to your little pretend toy apps.” - You might want to get your meds readjusted.
Mike Gorski
on 09 Sep 10I’d have to agree with Greg and other developers who poke fun at this wow-our-app-is-complex-now post.
Just as an example, the tax code dependencies that are managed from year-to-year in something like TurboTax put this little list to shame. And I can get TurboTax for a fraction of the cost I’d pay for Basecamp for a year.
This type of “and don’t forget this” list is so common to most software projects that it isn’t worth mentioning.
RF
on 09 Sep 10One of the few bits of Rework I really disagreed with is “forget long to-do lists.” Crazy details you’re certain to forget are a core part of software development, and that mile-long hyper-detailed list of stuff to do (always subject to change, of course) helps you straighten your expectations out or figure out if there’s a better way or whatever. Used right, anyway.
It’s silly for commenters to be mocking 37s because their list isn’t long enough. Some people hack TurboTax or the Linux kernel or microcode or database servers or safety-critical avionics software and their “don’t forget this” lists pwn us all. 37s have never been about being the best bit-slingers in the world; they’re about doing a lot of things well at every level with a small team, and that’s enough to make them successful in their domain—it’s a good gig and worth trying to imitate.
(And they also talk a really good game about how awesome they are, which I think makes it hard not to want to talk smack about them sometimes even if you’re a fan like I am.)
Felix Pleșoianu
on 09 Sep 10That instantly reminded me of this blog post describing how a “15 minute job” turned into several hours of serious work. The hard part is making clients understand that such things happen. Any developer with some experience knows it all too well.
Jeff Putz
on 09 Sep 10Wow, what’s with the haters? I didn’t view this as some masturbatory inappropriate touching, but rather as a view into what many might consider a simple feature. As a developer, I certainly get that this sort of thing comes up every day, but so what? Some of you stop just short of bragging that your own code base is more complex, which hardly sounds like something to brag about.
Pawel
on 09 Sep 10@JZ ” You can’t fully understand the project until you’re working on it.” – another example showing that planning is guessing.
Michael
on 09 Sep 10Hey, Greg, real software companies put out ugly, bloated products that are painful to use and always late to market. Fake software companies are the only ones kicking ass right now.
Scott
on 09 Sep 10+1 for @Michael
Jaymie
on 09 Sep 10My initial reaction to this post was well what do you want, a medal?, but on reflection I guess it perhaps isn’t aimed at developers per se.
An explanation of the functionality required behind a seemingly-simple, on-screen function benefits us all – if only to the extent that those requesting changes and upgrades to systems now might appreciate a little more about what goes on behind-the-scenes.
We all know those who think seeing a prototype means it’s nearly done. This post helps rally against that thinking… I hope.
Acatl
on 09 Sep 10Been waiting for this feature! thanks!
James
on 09 Sep 10Really, you thought that was complex? Why?
Rob Cameron
on 09 Sep 10I’m sending this around internally for all the product/general managers who are so fond of saying “that should be an easy change…”
Americo Savinon
on 09 Sep 10Guys, let’s keep focus on the main idea of the post (which I think is great) I believe its porpuse is to show a glympse on how a simple thing can involve multiple and more difficult tasks in the background. That’s it.
37s is just sharing with us their experience on implementing this new feature. Of course they don’t want a medal, duh! They want us to give us a gift while sharing their experiences. Thanks for that.
Ryan
on 09 Sep 10Firstly, I don’t know how you could get so pissed off over a post explaining what happens behind the scenes. People amaze me.
Secondly, I have a quick question. When you say “We need to move the comments with a message”. It seems like the comments would be tied to a message rather than a project, in which case it wouldn’t matter what project the message belonged to, the comments would inherently go along with the message no matter what. But I’m assuming since that was indeed a concern, that the comments are tied to a project AND a message? Maybe for query speeds, perhaps? (go from a comment straight to a project, without having to go through the message first)
On the surface it seems like there wouldn’t be much needed for things like message comments and maybe to-do lists on a milestone, so I’m just curious as to why there is.
The feature looks great, btw!
Adi
on 09 Sep 10If each item(todo, milestone etc.) has a reference to the unique project id, then you just need to change the project id reference.
That’s a single line of code.
Manuel
on 09 Sep 10Hi, Amazing work and even better the explanation. Just one thing: I know very little about all this but, it’s not too much workload to move all the thumbs? Is not better to let them where they are? Observation from a total Lego…
Rudiger
on 09 Sep 10I think this is symptomatic of a poorly-designed database (typical of most Ruby developers, if you ask me). Something like moving messages, to-do lists, milestones and files from one project to another shouldn’t be that complicated.
Kyle
on 10 Sep 10Very cool. It’s always interesting when you guys post stuff about your app internals.
I’m curious what your schema looks like if moving a message necessitates updating its file attachments, comments, etc. In most scenarios I’ve seen this would’ve been done automatically by following foreign keys. Obviously you guys have some sort of requirement to make it more complex; care to elaborate?
Jordan
on 13 Sep 10Is there any plan to implement a feature like this in Backpack (moving pages from one backpack account to another)? I’ve been dying for this feature for ages having created lots of pages on a personal account that now needs to be moved to a work one….
Matt
on 13 Sep 10Yeah, I’m pretty surprised at the negative responses. The post seemed like a pretty tame one around here. It was a helpful reminder to me, and even more to my customer, to remember that even when something seems like no big deal there are often a bunch of hidden dependencies. Thanks for the post.
Fredrik
on 13 Sep 10Easy hu?:) At first it may look like it’s just a change of a foreign key, but of course there’s lots of dependencies that needs to taken care of! I guess you wrote a lot of tests for this new feature.
Adam Fitzgerald
on 15 Sep 10Rob Cameron hit the nail on the head.
It’s about the word “easy”. A customer assumes an “easy” change task takes 5 minutes.
This discussion is closed.