May 19, 0:41 | Comments (2)
The first Building of Basecamp to leave the States is heading for its second home of Copenhagen. While that's a great thing in itself, it's even better that we're running in pairs with Reboot. The Copenhagen BoB is on the 9th on June. Reboot starts on the 10th. So the city will already be filled with interesting people. You really have no excuse not to come.
We even have a spiffy new site for the workshop in honor of taking it to Europe after much and heavy demand. The last workshop sold out in just one week. I wouldn't be putting off my registration, if I were you ;)
May 06, 18:13 | Comments (22)
When car companies produce faulty vehicles that cause horrible accidents or aggravated injuries on regular mishaps, they do a recall. Google's Web Accelerator is causing death and destruction on an admitted much lower level of criticality, but it too is in need of an immediate recall.
Google screwed up on this one. Really bad. But that's not what's important. Or at least not the most important thing. No, the trial of "do no evil" is how quickly and effectively Google can react to their screw-up and set things right. How fast will they make the calculation:
Take the number of accelerators in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court outrage over loss of data, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one.
Google needs to acknowledge the size of X immediately and act on it yesterday.
May 03, 1:40 | Comments (7)
With the coming launch of Backpack (our third application) just around the corner, it was a fitting occasion to revisit 37signals.com. The relaunch reflects the company transition from world-class web design shop to application maker striving for the same accolades. I admired the former for years before getting on board to help create the latter.
And just like we try to do with the apps, we've said goodbye to bloat on the presentation too. So its just that single page you see. Instead of static praising that invariably grow out of date (and fashion), the focus is on the conversation instead. Through Signals vs Noise and the personal blogs of our people, like this.
It's been a fun ride. From we first started thinking about Basecamp a year and a half ago to today where we're steering a whole suite of applications forward. It's a testament to the flexibility of small companies. A reinvention of the self in a short time span and incurring none of "restructuring costs" of the giants.
Having been through a number of such re-inventions now, I've been growing ever more confident in saying the words: you can do it too! Whether its you as a company owner, employee, or independent consultant. We've never had better opportunities to break out and make it on our own, make it differently, and making it with passion.
The barriers of old are crumbling. Seize the excitement. Break out.
March 23, 0:27 | Comments (9)
It's time to drop the code name. Honey is Backpack. The next big thing we've been working on at 37signals. It's an application we've been trying to narrow down in our heads for the better part of six months, but only recently acquired a focus sharp enough to start Getting Real.
And getting real we have. Backpack has once again provided me a fresh slate to experience the Rails anew, which always gives rise to a wealth of new ideas. I couldn't build a better framework any other way even if I wanted to. Frameworks Are Extractions and all that.
We've already extracted a big chunk of the technology already, actually. Remember those shiny new Ajax helpers in Rails 0.11.0? That's a Backpack extraction. Since the scope of this application is significantly larger than that of Ta-da, there was simply no way I was turned every Ajax opportunity into a mini-project of its own.
Those constraints again. If we had allowed ourselves to allocate an abundance of resources, we would perhaps just had followed what we knew from Ta-da. Did the mini-projects. Poured sweat and tears into hard work of hand-held Javascript. But we couldn't, so we didn't, and there you have it: A need to innovate.
Actually, that script/runner we also added this release. Backpack extraction. Oh, the incoming email support for Action Mailer? Backpack extraction.
No wonder the lines of code is currently a mere 585 despite having an application that does a ton more than Ta-da. I'm extracting every infrastructure breath I take. Luckily, I haven't drawn a kitchen sink yet.
But what do you care about technology. Do you want to know what it is, Neo? Yeah, I'd love to tell you, but what fun would that be. We're still 30-45 days from a release so why don't we leave it at what the trailer says:
Backpack helps you bring life's loose ends together
It's true too. My loose ends are being tied together awfully well. We've been eating the dog food since the application was a mere 100 lines.
Intrigued? How about signing up for our announcement list. We'll be picking beta testers off that list too.
Backpack is coming soon — it'll be better, not beta.
March 13, 16:07 | Comments (9)
Jason took down SXSW yesterday with How to make big things happen with small teams — an hour's worth of insight extracted from the Building of Basecamp workshop. And boy, did that have an interest at SXSW. Around 180 people were trying to fit in the obviously way to small room:
Terry Storch was in the room and writes:
Jason was by far the best speaker that I heard today. Jason is a very charismatic communicator that also knows what he is talking about. Jason is the president of 37 signals, a web design and software development company. 37 signals would best be know for Basecamp, a web-based project management tool.
What a shame that we've pretty much already sold out the upcoming Building of Basecamp in Chicago. I bet Jason could have sold out another workshop by the engrossed audience.
March 11, 2:11 | Comments (20)
My partner in excellence, Jason Fried, has been interviewed by O'Reilly's Marc Hedlund under the title The Builders of Basecamp. It shall be no secret that I was a huge fan of 37signals and Jason's work and ton long before I actually got involved with the company some three years ago. This interview does a fine job of highlighting a lot of the reasons why.
Jason has an incredible passion and drive for keeping it simple, telling it straight, and delivering. I'm frequently counting my lucky stars that he decided to attempt to learn PHP back in '01, that he couldn't make it work and asked for help, and that my help got the relationship going.
Asked about why we went with Ruby and subsequently extracted Rails, Jason speaks straight to my ideal on management and cooperation:
If you don't trust your developer to choose the right environment, then how can you trust him to build the best application? Trust is critical here. And, further, why would you dare impact your developer's morale by throwing him or her into a language where he can't be as productive or as satisfied? You only get good work from people who enjoy doing the work. I'll take a happy average programmer over a disgruntled, frustrated master programmer any day.
From that, it's not hard to see how we were drawn to the vision for Basecamp:
Our baseline approach is this: project management is communication. Projects don't fail from a lack of charts, graphs, tables, reports, stats, spreadsheets, and so on. Projects fail from a lack of simple two-way communication.
I wouldn't want to run a business with any other partner in the world. I wouldn't want to run any other business than 37signals in the world. And I wouldn't want to work on any other products than the family we're building with Basecamp, Ta-da List, Writeboard, and Honey. I'm having the time of my life in the best possible company.
So that's my round merry, happy back padding for today :)
March 09, 13:27 | Comments (21)
While there wasn't much hesitation before sharing our troubles with the latest upgrade, I did pause for just a second. Will people think less of us because we didn't do this or that? How will the story reflect in the light of calm analysis and perfect hindsight? Luke offered just that view in the comments:
...building solid web applications is your THING. And that's not just about development. You need to take some of your developer brilliance & insight, and invest I tiny bit into the operations side of what you do too.
Which is a fair stance. But it's of course also what makes a lot of companies terrified of sharing stories of trouble. And what gave me pause. In the end, though, I believe that the net benefit of transparency far outshines the small bruises you'll inevitably in return.
As an example, we're currently conducting an open-ended questionnaire with our customers asking what they like, don't like, and would love see changed. I took especial comfort in this comment on what to like about Basecamp:
The clean interface, ease of use, basic tasks are easy to execute. All features aside, I greatly appreciate the transparency of the operation. Not only has david released Rails to the world, but you guys (or David) had the balls to discuss the hardships felt during your recent upgrades. Most companies would leave it at "we apologize for the failures".. but letting/having a partner discuss the issues in detail is something you just don't get every day. It's extremely refreshing, and something more companies should emulate.
I believe this is part of the competitive advantage that small companies can enjoy if they dare. The freedom to say that you made mistakes. How you made them and why. The freedom as a partner of the company to say fuck, if that's how you feel.
P.S.: It definitely seems like the transparency is infectious. Jamis just shared another story on what can happen when you go to the keyboard ill. Hopefully we'll soon return to the stories about how we're conquering the world instead of how we're failing to ;)
March 08, 19:36 | Comments (14)
When we did the first Building of Basecamp, the last seats were sold just a few days before the workshop. The pace of registrations have steadily accelerated with each time we put on a new show. But this is getting pretty insane. We just opened for registrations five days ago and we've already sold more than half the seats!
Can't wait to get back to Chicago (the last two were in Seattle and San Francisco). I got my favorite flight (SAS SK0943, 9 hours direct) booked already. I hear they have wifi on the planes now, so that's going to be pretty cool.
Hopefully we'll be able to run a show just as good as the one Jason Hummel attended:
I attended a previous conference in Chicago, and I can tell you it's worth every penny. If for nothing else, just to see people speak who are passionate about what they do, and more importantly how they do it. Of course, if your like me, be prepared for lots of conflict at your job on your return, since you'll immediately recognize how wrong your coworkers/supervisors have it. You'll also wish a job opening would open up at 37signals. ;)
March 05, 15:12 | Comments (32)
Jamis Buck came on with 37signals as a full-time employee on Wednesday 3rd. On Thuesday the 4th at 7 AM (my time), we embarked on what would become a forty-four hour struggle to keep Basecamp alive during the worst server ills in the history of the application.
Continued...
March 04, 18:37 | Comments (5)
Building of Basecamp is happening for the fifth time on April 22nd where we'll return to Chicago for a full day's workshop. We'll be covering our approach to teams, vision, programming, designing, marketing — everything involved in launching a successful online venture, like Basecamp. This time we'll also be talking about Ta-da List and our upcoming application code-named "Honey".
All our previous plays have sold out in just a few weeks and received 4.5+ out 5 averages from the participants. So please, do join us in Chicago on the 22nd.
February 15, 23:50 | Comments (24)
Simen Brekken writes in comments for The false promise of template languages:
Our designers never deliver anything but Photoshop comps or at best slices, and I wouldn't want it any other way. It's all about delivering a quality product and the graphic designers should focus on the design, and you as a programmer on the implementation.
Simen, surely photoshop comps is the right thing to deliver is all you have is "graphic designers". Thankfully, there are many other forms of designers. The ones running 37signals are first and foremost application designers — focusing on visual priority, interaction flow, etc. The closer to real they are, the closer to the elements they can operate, the better designs they do.
The constraints of HTML/CSS and web interfaces should be available to the designers all the time. It's the feedback that causes good designs. Constraints don't inhibit creativity, they foster it.
When you're just photoshop comping, you're merely painting pretty pictures. Those pretty pictures may or may not translate well into designs. My experience has been that they are way more "pretty" than useful. They also tend to make you focus way to much on looks and way to little on interaction. You can't interact with a photoshop comp, but you can easily interact and get a feel for a flow of five HTML screens linked together.
Additionally, it's a big waste. Doing the whole thing in photoshop, then redoing everything in HTML is wasteful. It certainly depends on your organization, but getting real faster, going HTML sooner, is a way to do big things with small teams.
I believe photoshop comp'ers are great for making the next Nike commercial site with spinning wheels, flashing shoes, and pretty photos zapping back and forth. They're terribly inefficient and inadequate for designing applications, though.
February 14, 17:12 | Comments (22)
This is a repost from an exchange on the Rails mailing list. I got a recommendation to give it a more permanent home and share it with the world. We had a long running thread on whether Rails would benefit from some form of Amrita-style template language that "doesn't contain any code". Steve Longdo wrote about that:
The designers that a lot of the rest of the world works with aren't
the same caliber as 37 signals by a long shot. Dreamweaver expert
does not likely yield a decent ruby/rhtml coder...
Florian Weber followed up:
i think it's better to get the designer work as close to the real thing
as possible. that also avoids wasting time.
And I wrote about how we work at 37signals...
I concur that its a false dichotomy. The designers at 37signals are not Ruby programmers. What they are capable of is reading english-like code fragments and move them around accordingly.
This is how we work:
- Designer cooks up static HTML template.
- Programmer sprinkle it with rhtml tags to make the dynamic elements
dynamic.
- Designer and programmer can both revisit the template to make
changes.
The reason step 3 is possible is exactly what forces good programmer behavior in the templates:
<% if @user.is_administrator? %>
# show stuff that's only for administrators
<% end %>
...or
<% for comment in @post.comments %>
<h2><%= comment.headline %></h2>
<% end %>
No matter how "easy" you make your template language, new dynamic templates are not going to originate from the designers. What you can make possible is cooperation around the same templates once they're alive.
I remain utterly unconvinced that Amrita-style templates are going to do much anything than please the aesthetics that have fallen in love with <li oid="people">Loop</li>. It's not going to put designers in the driver's seat for new templates. And even the one promise of being able to edit in Dreamweaver falls to the wayside when you introduce layouts, partials, or other productivity techniques for dealing with templates.
The pursuit of "no code"-templates reminds me of the search for the holy grail of the MDA camp with "no code"-programs. It's mirage, but its also a play on words of the "a rose by any other name..." variety.
Code is just another word for decisions about instructions. Whether those decisions are made through indirection and tag decoration, they are still decisions about instructions. That is, its still code.
With all that said, I shall not stand in the way for the pursuit of another man's aesthetic dreams. Many will know that I guide many decisions about Rails from my own sense of aesthetics all the time. I'd feel a lot more at ease about it if the proponents of Amrita-style templates would just confess, or realize (as the true motive may still lie in the subconcious ;)), that the pursuit is one of aesthetics.
So. If you want to try this out, feel free. Should a truly non-intrusive solution emerge, I shall even give it serious thought as whether to include it.
UPDATE: The reason why I think the whole notion of code-less templates have taken hold is because people have been used to languages that were utterly unsuited for template logic. The template languages presented a less painful way to add logic and due to the lower pain associated with their use, it grew too tempting to fit in inappropriate code to them.
That's totally different with Ruby on Rails. First of all, Ruby is an excellent language for view logic (succinct, readable) and Rails is also made out of all Ruby. So there's no longing for a better suited template language and there's no pain relief in misappropriating business logic into the view.
February 02, 17:01 | Comments (38)
Everything Basecamp has a short blurb about FIXED: Temporary database glitch. Jason called me up at 7 AM this morning (three hours after I went to bed) to tell me about it. Nothing unusual in that, programmers and system administrators are woken up in the middle of the night all the time.
Only Jason was calling from his Powerbook at 2 cents a minute. To my cell phone. In crystal crisp quality. In other words, Skype 1.0 is out for the Mac and SkypeOut freaking rocks. The quality was so good, I didn't even realize he was skyping me until long after the call.
Once more, that's lower-than-local rates for calling across the atlantic to normal phones. I'd start to worry if I was a telco living large off overpriced international calls. They're going to be 1, 2, 3, gone in no time at all.
While iChat AV is pretty darn cool and getting even cooler in Tiger, I can easily see Skype growing big and large in no time. Or, actually it is big and large at 54 million downloads. But bigger and larger then.
I especially like their voicemail feature. I'm not sure if its available to the general public yet, but my man on the inside of Skype hooked me up and it's super cool. It's just one more step to get push-to-talk and then it'll all get even more interesting.
I'd love to see recording of calls straight to MP3 as well. It would be a great way to record design conversations and then upload them to Basecamp for the team to share.
P.S.: Jason is just as psyched about it on SvN.
January 30, 22:27 | Comments (28)
The ceremony took place at the glamourous Holiday Inn. We had prepared the precious 33-paged contract from the finest 50 cent a paper FedEx/Kinko's could offer. Four signatures was all it took and the deal was done.
I'm now officially a partner at 37signals. Or member, as the legal term for LLCs define it. Boy, does that feel good. It's been long coming, too. I've worked with Jason and company for more than three years. We started talking about the possibilities of making the connection formal mid last year. And now it's finally a done deal.
I can't believe that its just been three years since I started writing my first commercial PHP for Jason. Back then, I was merely a huge fan of 37signals. I'm so very glad that Jason tried to learn PHP, which initiated our contact, and I'm equally glad that he dropped the idea again after we hooked up.
I've never worked with such intensely talented achievers as the 37signals crew. It's really a dream come true to be part of the it. I can't wait to take our soon-to-be suite of products even higher in their companionship.
Jason announced the deal on Signal vs Noise too.
January 28, 16:30 | Comments (23)
Our fourth Building of Basecamp went really well yesterday. We didn't make as many radical changes to the presentation this time as we've done before, so the material was more intimate to us and we are able to deliver it in a more convincing and timely manner.
Especially the timeliness was helped along by Apple's great new Keynote 2, which has a presenter view that's different from what's being shown on the projector. This view has a clock, a timer, notes, and — most importantly — a preview of the upcoming slide.
We also had significantly more push-back from the audience on our views on functional specs and contract-driven development, which gave a more varied discussion. Speaking of discussion, Dave Thomas of the Pragmatic Programmers was in the crowd asking lots of questions. Thanks, Dave!
All in all, it was really fun doing it again. I look forward to our next one, which might be in New York in a couple of months. The plan is to do the workshop every two-three months.
Today the plan is to hang with Jamis Buck and Dave Thomas before they head back around noon, visit the Robots to talk about the 43 Things experience on Rails, and finally pay a visit to the Seattle.rb (the user group for Ruby in Seattle) at the Omnigroup's offices.
Oh, and of course pick up my Mac Mini and iPod Shuffle also at the Robots office. Can't wait to fondle the both of them!
January 26, 13:05 | Comments (22)
I'm leaving for the Building of Basecamp workshop in Seattle tomorrow. A grueling 10-hour flight. Uargh. At least its direct and with SAS. And the iPod is loaded up with podcasts and audio books. We'll make it through. See you on the other side.
January 19, 23:46 | Comments (16)
Todo lists have long been one of the favorite features in Basecamp, so we thought it would be a nice experiment to share that particular feature with the world at large. Free of charge. And Ta-da List was born!
A few user-oriented highlights of Ta-da:
- Extensive use of XMLHttpRequest: Adding new items and checking them on and off are done with remote calls that change their state in the database while simultaneously updating the view using Javascript. This makes it really, really fast to add new items to a list — and you're not restricted by the 10 predefined fields that most apps like this does.
- Loose sharing with unique URLs: Sharing a list with a single or group of buddies is easier than ever as there is no password to remember. Instead, everyone just gets a unique URL that they can bookmark right away. At 32 characters and as a MD5 hash, it's plenty of security for this type of application and much easier to use.
- Collecting all the shares: By allowing you to share any list with any email address, we already got the viral thing going. The barrier of signing up has been postponed until you're hooked, and once you are, you automatically collect all the shares as you signup. This means that they're all available from your dashboard and you can reduce the bookmarked lists down to one URL.
And for the technically inclined:
- Three levels of caching: I implemented page, action, and fragment caching for the Action Pack in Rails so I could be able to use it in Ta-da. And it's working exceedingly well. Lots of pages went from 50-70 req/sec to 400-1100 req/sec due to caching.
- 579 lines of code: That's including models, controllers, and helpers. It's really lean and really readable too. It was great to see just how small you can make an application with a recent version of Rails (especially the 0.9.x series) on a fresh code base. In Basecamp, I'm often working on code that predates the release of Rails, so it's a nice change of scenery.
- Finally FastCGI: Basecamp is still running mod_ruby for various reasons, but Ta-da is fresh out the gate on FastCGI. And what a difference it makes in memory consumption! We're currently running five FCGI processes (which is more than plenty) that come in at about 15MB a piece. On top of that, we got 50 Apache processes at just around 3.5MB a piece. That's just 250MB for the entire setup. Much unlike the situation on Basecamp where we have 40-60 Apache processes of 40MB a piece.
In addition, it seems we're off to a flying start as we blew through 1,000 people signed up in just a matter of hours! And it's getting blogged all over the place. Justin French has a really nice post about how he switched his workflow over. And Tobias Luetke already whipped up a script to integrate Ta-da into your site using Ruby.
January 18, 11:25 | Comments (1)
Considering we just underwent a similar situation with Basecamp — when we raised prices to coincide with the release of a bunch of new features and adjusting for the year gone by — it's funny to read how others tackle it:
Irina: OK. Can we talk about the eBay members who are frustrated with the fees? The ones that were increased, not the ones that were decreased.
Durzy: I think most ebay users are evaluating the price changes to see how they will impact their businesses.
Irina: Um, OK. Um. [debating if I should follow up on that "answer"] How did eBay decide on the increase.
Durzy: We carefully valuate our pricing structure from time to time. We believe these price changes are the right thing to do for the vibrancy of the market place.
It's no wonder that spokespeople like Hani Durzy has such a bad reputation. When you can't even acknowledge that you're raising prices in a civil manner, there's obviously a disconnect with reality and reporters and customers smell that in a second. And it's not at all about the actual price raise. It's about not having the balls to stand up for it.
eBay would do well by replacing the archetypical PR drone with something resembling a human being.
January 07, 13:47 | Comments (1)
We just launched a major upgrade to Basecamp to coincide with the plan revisions for 2005. It includes a big push for security with SSL being available to both Premium and Plus plans and SFTP being available to all paying plans. It also makes it easier to use Basecamp if you're not in Central Time as its now possible to specify time zones on a per-company basis. Oh, and we finally added "Remember me for 2 weeks" back.
So launching a big upgrade is good, but getting the feedback from happy customers is even better. The thread on the launch is already filled with congratulations, like:
Thank you for kicking tremendous amounts of ass... My God, I love you guys. I think I'm going to cry... I seriously treasure the day I discovered Basecamp!!! So many amazing updates! Basecamp Forever!
The outburst of joy is even more welcome after we've been battling with a couple of extremely rude and totally unreasonable customers the last couple of days. One guy wanted to "DESTROY YOUR COMPANY" if we didn't refund his six months of usage. Yikes! So a huge thanks to the vast majority of our customers that are liking what we offer and are not afraid to say so.
This release is significant in another way too. It includes, for the first time, the work of another programmer in the core Basecamp code base. We've brought on Ruby master Jamis Buck as a moonlighting consultant and both the SFTP and timezone support are to his credit.
I've been impressed with Jamis work on sqlite-ruby, Needle, and Net::SSH for a long time, so when we had the opportunity to engage a working relationship with him, it was obvious that this would be a great fit. And it has been. I can't believe that a Ruby programmer of Jamis' caliber isn't doing it full-time, so we'll see what are in the cards to change that.
UPDATE: Jamis shares a few more details.
December 29, 2:42 | Comments (13)
We're tinkering with the Basecamp rates for the first time since the service launched soon-to-be a year ago. Doing so is always incredibly risky. No matter what you initially set your prices at, you've created a baseline and a set of expectations that are very hard to work against. In short, you've created a pricing reality and the increases needs to play within that logic.
So we deliberated long and hard over how we could make the adjustments as fair and evenly balanced as possible. The result is readable in Pricing and plan structure changes at the Everything Basecamp site.
Now we're eagerly awaiting judgment from the constituency and how they will let their valets vote. Hopefully, we'll not alienate the bulk of them and hence be able to enter a brave new 2005 with a structure that'll allow us to reach above and beyond. It's going to be an awfully exciting year.
December 14, 16:10 | Comments (6)
The Basecamp manifesto is a series of beliefs we hold to be true as guidance for developing and running the application. It explains many of the decisions visible in the structure, features, and constraints of Basecamp. It's about why we started to develop Basecamp and why we continue to push on. It's a behind the scenes of our minds.
Being a student of informatics, I'm particularly proud to see so many Scandinavian values reflected. The high priests of participatory design would be proud to read statements such as:
- "Basecamp democratizes project management and makes it a team effort"
- "More participation should not result in higher fees"
- "...all support emails are answered personally by the people who actually built the product".
Would you like to know more about these beliefs and how you can recast and practice them for your own projects? Sign up for our Building of Basecamp workshop. We're doing the fourth of them in Seattle on the 27th of January. All previous workshops sold out well in advance, so be quick.
October 08, 23:06 | Comments (2)
We've just launched a major update to Basecamp that introduces responsibility assignment for todo items and new responsibility screens for both todos and milestones. This was an interesting feature introduction.
At first glance, I thought it conflicted with one of our dear mantras that Project Management is Communication. I saw this initiative pulling us towards the Control and away from Communication. As in managers would use the new overview screens to assign blame (you still haven't done X, Y, and Z) and spread general mischief.
But as we talked more about the feature, I realized how that fear of misuse was dwarfed by the communication potential. First of all, we made it so that every employee could see what any other employee had on their plate — not just the administrators (who are often managers).
Using it as such, it's a great tool to enable employee-to-employee collaboration. You have an idea of whether now is a good time to disturb or talk about that feature you've been working on (because Pam is working on something similar). Or if Paul has a light load, you can arrange for a swap on some items.
At the same time, it's a really useful tool to communicate upwards that "there's just not enough hours in the day". If your todo list is already full, it's pretty hard as a manager to be oblivious to that fact and assign an even heavier load with your head in the sand. Same goes for the milestones: "If we need to get this done by Friday, maybe I shouldn't also be in charge of sending out 100 envelopes".
So despite the potentials for misuse, I'm generally pretty happy about how this turned out. Especially the new todo list where you can see everything that you need to do across all projects.
September 19, 15:03 | Comments (14)
The idea of replaying a speak you've done once never really had me comfortable. How can you deliver it with the same spontaneity and energy of the original airing?
Thankfully, I had forgotten to factor in the most important part of any speak: the audience! Hence, my concerns were quickly rendered irrelevant as Jason, Ryan, Matt, and I engaged a crowd of about 45 people for the second Building of Basecamp last Friday.
The split between designers and developers were nearly fifty-fifty, so that certainly helped us to do involve the many angles that the presentation shined through. This resulted in lots of great questions and new perspectives coming from the many varied backgrounds and really brought the room alive from the get-go.
So many thanks to all attendees. You made it really easy for us to get excited and left us glowing with your over-positive feedback to the workshop survey. I'm looking forward to the third offering in San Francisco even more now!
September 14, 2:31 | Comments (10)
Jason has just announced the third Building of Basecamp workshop, which we'll be doing in San Francisco on November 9th. We're teaming up with Adaptive Path who'll be doing a "Building Blogger" workshop on the 8th — you can get both days for $745 (or either for $395) at the signup page.
I'll probably be in town already on the 5th or the 6th, so if there's any SF natives interested in meeting up to talk about Ruby on Rails, Instiki, or anything else, I'm around.
September 11, 11:09 | Comments (6)
I'll be leaving for Chicago a little later today as the second Building of Basecamp workshop is drawing close. Unfortunately, I sold my PowerBook yesterday, so there will be no in-flight programmnig for the eight hour ride by SAS. Hopefully, Jason will have my new machine ready for unpacking when I land, though.
Thanks to Carbon Copy Cloner, I also won't have to waste a couple of days setting up the environment once again. With CCC, you can create a complete image of your harddrive, place it on an iPod, and load it on the new machine in no time at all. Pretty much no matter what piece of Apple hardware you're switching between. Awesome application.
So talk to you all later and I'll be seeing the workshopers on Friday. Looking forward to another enganging day of talks and debates on the nature of web-applications.
August 28, 17:52 | Comments (13)
Just like the first workshop, Building of Basecamp II has sold out weeks in advance. It's very pleasing to see that there's still a lot of interest in hearing about the lessons we learned and are learning from Basecamp. The entire team is certainly psyched to provide another full day of informative, fun, and challenging discussions on how to build successful web applications based on our experience with Basecamp.
Since Rails is now out in time for the workshop, I'm sure we'll also touch on that a bit deeper than we did last time. And it's certainly ripe for discussion during the many breaks.
Also, we're contemplating doing the third run of Building of Basecamp in San Francisco in November. Interested in attending? Please do send an email to workshop at 37signals.com, so we can gauge the interest.
See you all in Chicago on September 17th!
August 19, 11:59 | Comments (21)
In a response Stop being clever about it, Rasmus launches into a condemnation of shock and loss of respect:
I am bordering on being shocked that the "active/finished" status has been decided by a algorithm instead of user input... the fact that this feature has only been added post-launch has led to me losing some respect for 37 Signals. It's the kind of feature that I consider so blatantly obvious that I'd expect it from any given amateur software solution.
Rasmus, you're over-dramatizing what happens to be a natural evolution of understanding. Like Jason said, this design came from an intent to make Basecamp the simplest way to manage your projects.
When you're trying to archive such a goal, it's the same as placing a number of bets with varying odds. There's no way we can (or could afford to) asses or even contemplate how every single feature is going to play out in advance. So some of the bets are bound to turn out bad.
Does that mean we shouldn't bet? Does it mean we should be struck by analysis paralysis in order to archive complete information about every bet? What an extremely boring and slow company 37signals would be then.
Continued...
August 18, 16:14 | Comments (10)
The latest update to Basecamp doesn't talk about the technical developments that went into it. It's about features because customers rarely care about what you had to do to get there. But I'm going to assume you do.
While readying Rails for release, I uncoupled Basecamp from the main trunk a few months. I simply didn't have the time or nerve to keep Basecamp in synch while I was adding and restructuring the framework at a hectic pace.
That's both a sensible, but also dangerous thing to do. As Rails matured, I kept wanting to use the latest features to do Basecamp work, but couldn't. That lead to a nasty mental overhead of remembering how the API looked in the old version and which pitfalls I hadn't yet closed.
So hinging Basecamp back on track with the current version of Rails with the latest release brought great satisfaction. Not only because I would be able to use the new features in the coming releases, but also because I was able to refactor a ton of cruft out of the system on the same occurrence.
Hence the code base lost about 10% of it's weight while I was adding a bunch of new features. So were going higher in terms of functionality and going down in terms of KLOC. That's what's supposed to happen when you maintain your maintainability, but it's probably one of the first times I've really felt that to be true for a system that had been in production for almost six months.
It's a great feeling, though. With the control-flow and model logic hovering at just above 4 KLOC, it's going to feel even greater as I'm able to simplify further and push that number below the 4 KLOCs. There's still a bunch of new Rails features I haven't really implemented widely in Basecamp yet, so I'm pretty confident that's going to be a doable goal.
August 18, 15:53 | Comments (18)
Basecamp started out with a somewhat elaborate scheme for deciding whether a given project was active or not. It looked at the activity in the project, such as whether any post had been made within the last 30 days or whether there was uncompleted milestones in the future.
The problems with this policy was plentiful:
- What do you do when a project is done? With the old system, you had to carefully wait 30 days (and make sure not to make any additional posts as the counter would then be reset). A project ready for the archives would thus still show up on the dashboard and in the lists, cluttering the activity of the projects that actually were active.
- What do you do with a project that's just on hold? It's not unreasonable for active projects to lay dormant for a month or more even though they're still important and you still need access to the information contained within them. With the old system, you had to poke to the system every once in a while to keep it active.
These problems were made worse by the fact that Basecamp is tiered on the number of active projects you have. So with a Basic subscription capable of 10 active projects, you would have to wait around for a done project to go inactive when bordering the limit before you could start the next active project. While that might have triggered a few premature upgrades, I don't believe that customers would be happy in the long term to pay for a tier that they don't really need (don't be evil and all that).
So our solution: Stop being clever about it. Just let the customers decide when a project is either active, on hold, or ready for the archives. This realization of course lead to even Less Software. I was able to do a bunch of what I enjoy most about programming — remove code rendered obsolete by simplifications by a deeper understanding of the domain. And I can tell you that I enjoyed yanking every single one of those methods and callbacks.
This of course goes back to the old Word joke Are you writing a letter? We had the simple answer all along, but refused to realize that we were doing harm in an attempt to do good. Lesson learned. Stop assuming on behalf of a human what cannot be assumed without inconvenience.
April 01, 0:59 | Comments (8)
The date has been set for June 25th and my flight has been booked for our Building of Basecamp workshop. A whole day to pick the brains of the team behind Basecamp on a wide variety of subjects from development to design to marketing.
I'll of course be talking at length about Ruby and Rails both during and after the workshop itself. Perhaps we'll even get down and dirty with some hands-on examples of this outstanding combination of pure web-app productivity. (As you can hear, I'm already at basecamp on the climb of Mount Evangelism).
Be quick, though. There's a hard limit of 40 spots available, which will likely be gone sooner rather than later judging from the early expressions of interest we got when airing the idea. Bring more than three people from your company and enjoy 10-25% discounts on the $395 admission and a free year of Basecamp premium.
See you in Chicago!
March 21, 19:56 | Comments (17)
UPDATE: Ruby on Rails has been released!
I gave a presentation to Madsen-Mygdal, Guan, and Husager today over brunch on that upcoming Ruby web-framework I've been developing in conjunction Basecamp.
It's probably a somewhat different experience just watching the slides without my 4-hour oral presentation accompanying it, but it'll have to do. Hopefully it won't be too long before I'm ready to announce a beta version of the thing.
February 05, 12:49 | Comments (6)
 After four months of development, 37signals and I have completed and launched Basecamp 1.0. It's a hosted service for flexible project management composed of categorized weblogs sprinkled with contacts, milestones, and todo-list tracking. There's no fee for single-project setups, up to 10 active projects is $19/month, 25 is $39, and unlimited is $59. 37signals explains pricing and the offering in detail on BasecampHQ and answers questions on Everything Basecamp.
Continued...
January 27, 21:30 | Comments (6)
We're hard at work finishing up Basecamp 1.0 scheduled for launch in "January". With just five days of integrity left in that promise, there's a natural sense of urgency within the development team. But when both designer and programmer are natural customers of their own product, it's incredibly hard to resist gold-plating — the continuous stream of tweaks and small additions.
Continued...
| 
