Make big things happen with small teams

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.

I wish I could be there !

Is there any plan to put the video online ?

That session just blew me away. If only Building of Basecamp would come to TX...

Speaking of a video.. I've actually wondered if any thought was ever given to a downloadable version of the BoB workshop (or something like it).. video, audio, powerpoint/keynote, or combo of all.. I'd be willing to pay for it.

Although, I would completely understand if 37s specifically decided *not* to do that, as it really destroys the interactive nature of the workshops...

A video would be nice, I doubt they're ever likely to come to New Zealand to do Building of Basecamp.

Then again, linux.conf.au is supposedly coming here next year. There's an excuse for you ;)

Huh, I was in the room and was only moderatly impressed. If you've read 37S and learned even a bit about how BC was designed and built, it wasn't really anything new. And Jason wasn't exactly clear about the (significant) difference between "how we build products in a way that works well for us" and "how you mortals might apply this stuff in totally different circumstances."

I didnt attend the SXSW, but i read about the outline of it here: http://www.terrystorch.com/2005/03/sxsw_how_to_mak.html and i also saw a video presentation about basecamp and teh technology with which it was built.

And i must say that i am NOT impressed by the "methods" behind it. I cant say anything negative about Basecamp as i havent used it, but in my mind several "points" in the method is completely screwed up :)

"get real, start with the UI (user interface)"
Wrong, wrong and wrong. I dont get how anybody like Jason and also David(the techie behind Basecamp just to clear things up) can say something like this and actually mean it.
Don't get me wrong - Im no fan or supporter of 150 pages long specs and so on. But without knowing what you are trying to archieve you wont have a f*cking clue as to how your interface should look. If you dont which functions you want in some way, you have no idea whether you should build the interface with a searchbox or not, whether users should login or not and so on.
There is no way in hell that you could do some real development doing this. Then you let som nice interface decide what functions you need and not the other way around which is all wrong. When developing an application you try to solve a problem of some kind - You figure out how to solve this problem by looking at what functions you can come up with which makes things faster, better, more secure(or whatever your goal is) not by saying "We have this pretty interface, we can only fit a few things into it so the rest you must still do in the old way or not at all"
I REALLY dont get this - And no im not a developer who comes from a typical enterprise enviroment where you plan everything down to the last letter - I dont support that - But you cant solve a problem by looking at how "pretty" you can make it look.
The interface should support the functions and make them easy to use, not the other way around(Besides that the functions shouldnt make it difficult ofcourse).
Can anybody maybe show me the light here or is it just plain stupid?

"scalability (don’t build for it until you need it)"
What?! How stupid is that. You just keep on going :)
Again, im not saying that should develop for something which might happen ten years from now, but not at all thinking your code trhough a bit as to how you can make it scale better and so on is plain stupid and will require you to redevelop your application several times during its life because all of the sudden it cant handle the load it is subjected to.
The result is an application which will cost several times more in the long run than something which was just thought through a bit.
Again, somebody please prove me wrong cause otherwise i will again just have the feeling of somebody is quite stupid.

"admin interface (don’t spend time on admin side)"
What?! Again?! Every single system you use is an admin interface - Whether it be for the secretaries at an office, the CEO or somebody else. They all use systems with an interface which lets them administrate the tasks and information their job requires. The same goes for the backend of a system - In that position you might have a system administrator or somebody else who "works" there - Not thinking of those people is like saying they are just not important and whether they spend 10% or 90% or their time managing some system or function is trivial. Thats just WRONG!
Again please prove ME wrong cause all of the sudden i get my otherwise very positive oppinion about David and Jason turned to something VERY negative and i get the feeling that they really dont know what they are talking about and i find that VERY hard to believe.

And at least we can have an interesting discussion out of it :)

Michael, if you know what you want to build (by talking things over), there's no reason not to build it top-down. That pretty much makes sure your back-end only contains what is required by the interface, and not a whole lot more, which _can_ be the case when building bottom up. That's the point - if the interface doesn't need it - why build it? It's not that you should just doodle until you strike gold - you're aware of what you're doing all the time, it's only the approach that differs.

As for scalability - well, it's pretty easy to run around like a crazed chicken and erronously quote Don Knuth. I agree with your concerns, and I need to know that whatever framework/architecture I use will scale if I throw enough hardware at it. What I'm not yet too sure about, is that we can design anything using todays patterns and know that it will scale before actually implementing it. How does one plan for scalability in a framework? Pooling, caching and reuse ad nauseum, yes yes - but let's wait until we find out where it's needed. It is somewhat well-defined to measure/improve performance once an application is running, but it's a really difficult (thus expensive) task to pinpoint bottlenecks beforehand. What do you suggest?

As far as I can tell, the above are the points David et al. are making, they just tend to cover it up by hyping it and "rebranding" it to their (business) advantage.

Yeah guess i took things a bit to literate.

But in regards to performance as i said you cant plan for something which will happen in 10 years, but you sure can do some planning ahead.
For instance developing an application which will only be used by 5 people now and the wildest thing you could imagine plus 50% is maybe only 25 users in the future, well then what technologies you use such as which database, inline sql or stored procedures etc. dosnt make that much of a difference.

But if you from the start are planning something like for instance Basecamp which could be used by thousands and thousands of user with a rapidly growing futurebase, then you very much need to think about using software such as the database, which can handle it. Plus you would also need to consider something like stored procedures instead of inline SQL, also plain and simple optimisation of your SQL commands/stored procedures can make a HUGE difference in the load on the server and though a huge impact on whether a single server can host 100 customers or 1000 customers.
In my opinion throwing more hardware at a problem is not a solution. Ofcourse at some point you need more hardware but alot of companies are solving performance problem by just buying more servers instead of looking at where the actual problem is which can be anything from a slow database, badly designed SQL statements, non optimized webserver etc etc.
And ofcourse you can find some bottlenecks beforehand - Lets say you develop an application with some kind of search function - Everything is running pretty fast but your search function uses 15 seconds each time you use it - Then it should be clear to everybody that it will be a bottleneck when you might have 20 users using the function at the same time or even more.

I believe that a very important part of development is keeping an eye on performance and think about how you design your functions. Just like having a function, calling a function which in turn calls another function and so on. for lets say 10 levels deep - That will proberbly not be the best and fastest way to do something so even something as small as that can cause major problems if you got several thousand simultaneous users and that is also something you could easily avoid from the start.

And something as simple as running some loadtesting software a few times during the development process will also allow you to find possible bottlenecks.

But all in all you are proberbly right - They put it pretty squarely.
But i just think it is important to not have people overlook these important aspects as well. I agree that speed in development is important, but not for the sake of a good, fast and stable application.
Serious development is a lot more than just making a pretty interface and just banging some random code in behind the scene.

"Serious development is a lot more than just making a pretty interface and just banging some random code in behind the scene."

Except it seems that you've missed one of the central tenants to this topic, if you have a solid enough framework then you can start from very simple beginnings and iterate through the development and scaling issues at low cost.

Hence the buzz surrounding Rails.