Assembla Blog

Thanksgiving product update

Andy Singleton — Fri, 28 Nov 2008 14:27:00 GMT

Our November 27 releaese includes the usual bug fixes, and some feature goodies that will be of interest to Assembla.com user.

The space Stream page has a new, more compact format with icons for each event type. I am using it a lot more because it is easier to read. I use the filter sidebar to see all of the code commits, or everything that one team member is working on. This is the first user-visible improvement based on the work we have done on event processing, with a lot more coming.

The Time tool has a much improved time reporting interface. You can easily see time entries for a particular date range, or a particular use, and if you use the Time tool in a Portfolio Manager space, you can get a rollup report of tasks for all of your spaces.

The Twitter tool is fixed. Thanks for your patience. This is another demonstration of the event processing system. We changed the UI for adding Messages to put the forms inline for faster access.

Creative Contact - How we build and release a Web product

Andy Singleton — Wed, 26 Nov 2008 09:18:00 GMT

Bob Hubert of Creative Contact writes: "It sort of amazes me that just 5 months ago we started to put this site together and we have completed a credible, professional and altogether good looking product. My hat is off to you and your whole team."

Creative Contact is a site where designers, photographers, designers,filmmakers, and other artists can post galleries, find gigs, and collaborate on projects.

Bob Hubert, the founder, is an experienced entrepreneur who runs a company called Spec that builds biotech factories, and in his spare time takes photographs. In this case, Bob hooked up with Fresh Tilled Soil, a design firm that we often collaborate with.

You might be interested in the stages that we went through to deliver a web product, because it demonstrates some of the ways that we minimize delays at each step.

Proposal: This was a short phase, a few days, because we already had a mockup - HTML representing the site features. I looked at it, determined we could get something out in 8 weeks, and quoted a fixed weekly rate for a specific team structure. In our methodology, we give you a team, a number of weeks, and a weekly rate. Then, we deliver a release in the time available, and we cut features to fit the time. We never negotiate a fixed deliverable, because this takes a long time to specify, and the start of the job is delayed. So, from the beginning, we are working to eliminate delays in getting to a release.

Roadmapping: Usually, we do a roadmapping session, in which we make a list of features, sort them by priority, and try to find a minimum useful beta release. In this case, all of the features were represented in the mockup. FTS likes to make an HTML mockup that represents the complete product vision. I selected a subset of the items for implementation, and got Bob's agreement on that.

Setup: The first week we deploy a reduced-size team. The technical lead has to make some architecture decisions, set up the code skeleton, and build a staging server. Usually, a designer also works during this time. We build the team around the technical lead. At the beginning of this project, we assigned some new guys on trial jobs, so there were more team members than planned, and we used the project to qualify some new developers.

Incremental releases: We put the development team to work on tickets with weekly releases. The Creative Contact team was involved in testing the weekly releases, and they learned to write tickets to get what they wanted. This is the bulk of the work, but it flowed smoothly.

Stop! Bob called us up and said "I need you to completely stop development for a few weeks while I show this to some people and do some marketing". This happens on almost 100% of the short-cycle development projects. Nobody actually expects to have a product in eight weeks. We get into week 6, and we start ramping up the analytics, the blog, the user forums, and the other operating apparatus, and it becomes clear that there will have to be a launch process. Our customers usually want a break to organize that.

Commercialization: We did testing and small changes with a small group of users during the summer. Bob arranged to launch the product with special deals for a set of art schools, so the first big batch of users came in at the end of the summer. We ramped up up development team at about half the original size (2.5 instead of 5 people) to handle changes required by these users, to tune the marketing on the site, and to finish the for-pay "Professional" features. This second round of development also lasted about 8 weeks.

We don't often post testimonials for the consulting side of the house because we don't want to steal attention from the other great consulting firms using Assembla.com. Also, we are often in one of two situations that keep us quite. The first situation is rescuing a project that has lagged for a long time without a release. The second situation is where we are building a product for a company that will need further financing. In that case, we have to work on building an in-house team that will be an asset of the company, and we need to let the new team assume leadership. So, thanks to Bob for giving us this opportunity to explain how an Assembla development engagement can work.

Subversion upgraded with new features

Andy Singleton — Mon, 24 Nov 2008 16:49:00 GMT

We have upgraded Subversion, our most popular tool. Until now, we relied on the worthy Trac code browser to show files and changesets, but our new integrated code browser has improved integration and new features.

How to get it

The new code browser is available for all Subversion repositories. If you are already using Subversion with our Trac/SVN tool, you can see the new code browser by navigating to the Trac/SVN tab and selecting the small link under “Browse Source”. We recommend that you switch to the new code browser if you use Assembla tickets, or if you are not using Trac. To switch your links to the new code browser, go to the Trac/SVN tab, and select “Use integrated code browser”, and submit with "Update Subversion Settings".

If you are making a new workspace, you can select the packages for Subversion with Assembla Tickets or Just Subversion.

If you are logged in to Assembla.com, you can find all of your repositories at http://code.assembla.com . If you are not logged in, you will bounce to the home page.

New Features

Single sign-on. You won't have to go through the trac login to see your changesets.

Unified design. You'll stay oriented with Assembla headers, footers, and styles. This will be true even if you run it locally on your own repository. The changeset view is redesigned to match our new stream view, so you can easily recognize commit events wherever you see them.

Links to Assembla tickets, wherever it sees #<ticket#> in commit comments. You can also configure it to link to Trac or other ticketing systems.

Assembla profiles are linked to usernames.

File rendering improvements. For example, a “readme” file will be rendered under the list of files in its directory.

View as Web page. This feature totally changed the way we work with our designers. In the old Trac browser, they committed HTML mockups, and we would see the code like this. In the new browser, we show a “View as Web Page” button on the top right. When you select this button, the browser will render your HTML with all of the relative .css, image, and .js links. For example, you can get a look at our mockups for the new space/Stream and user/Stream page using the "View as Web Page" button.

The default "Download" button will give you the individual file (if you are looking at a file), or a zipped directory (if you are looking at a directory).

Repository copy. Select “copy” in the footer or on the Instructions page, and you get a new space with a complete copy of the repository. You can build templates for open source frameworks or commercial SDK's, then click and customize. Now you can use our free public spaces to publish code templates for svn users, in the same way that git users post code on github, and Mercurial users post on bitbucket.org. We will even put your public templates in our catalog. Private templates can be useful for firms like Assembla Consulting that start new projects with a standard configuration.

We are discussing enhancements like code commenting, git support, and in-place editing. If you want to suggest an improvement or vote on these ideas, please head over to feedback.assembla.com . Please go to forum.assembla.com to report bugs and problems. It's been fun working on this tool, and I thank everyone who reminded us how important SVN is to our user community.

Notes from the Instanbul War Room, part 2

Andy Singleton — Fri, 21 Nov 2008 17:41:00 GMT

The Istanbul trip was an experiment to see what a face-to-face meeting could do for our core product team. Traveling home, I have to ask myself: Was it successful, and what did we learn?

One thing I learned is that if you only have three days, you spend entirely too much time in a basement working, and not enough time siteseeing and goofing around. Independent of productivity, it feels good to hang out and get to know co-workers.

This meeting confirmed some things:

Its easier to reach consensus with face to face meetings, and it's easier to manage. I was struggling for months to get a plan for a new and more scalable server cluster. It was important to me, and I kept bringing it up, but it never made it to the top of the list with our technical team. On our first day, in less than an hour, we resolved this standoff and came up with a great new block diagram that will make the system more scalable and maintainable. I think most management issues can be communicated remotely if you know how to do it, but there is no question that it is easier to just have a meeting, and more people know how to do that.

People like showing their ideas in person. Our team gets most of its ideas out online into chat and storyboards and tickets, but they aren't presented with the same enthusiasm.

If you meet toward the end of a product release cycle, you will spend time working on tasks you already have, rather than planning a bright new future.

Traveling is a big drag on short-term productivity. The immediate metrics for how much product we built this week will take a big hit because we were traveling, rather than just working. That's why I recommend avoiding all travel if you have a short schedule. If there is a payoff, it takes a while to realize.

We decided that it would be a good idea to meet again when we are starting something new - a new product, a new product strategy, or a batch of new features. In this case, we aren't losing productivity, because we haven't started anyway, and we will get a big benefit from sharing ideas and reaching consensus on the plan.

Notes from the Istanbul war room

Andy Singleton — Tue, 18 Nov 2008 13:19:00 GMT

I just arrived in Istanbul to for a meeting with the Assembla.com brain trust – Vitalie, our systems leader, and Sergio, our product leader. This is notable because we have been working together on this thing for more than two years, and we have never taken the time to travel for a face to face meeting.

A friend from Hawaii IM'd me the other day.... “I spend all day on IM, but for design and architecture, it's not as productive as a war room where everyone sits together.” He also complained about multiple time zones. That was ironic because this guy lives on a remote Hawaiian island, in possibly the worst time zone in the world.

He's right though. It is harder to get consensus on big issues of design and architecture without a meeting and a whiteboard. After two years of basically incremental of the server cluster, the code, and the product strategy, I'd like to make some bigger changes. So, we will meet.

I'd like to be able to bring in project team members from anywhere in the world, on short notice,

I ran into an interesting challenge finding a location. An American or EU resident can travel almost anywhere on short notice and get visas. But what about the folks from Moldova, Ukraine, Pakistan, Vietnam, Argentina? A small country like Moldova does not have visa arrangements with many countries. In the worst case, a Moldova resident would have to travel 500 miles to Kiev, in a different country, to pick up a visa, and suffer long delays. In the George Bush paranoid version of America, it takes two months to get a visa for these guys to visit my home office in Boston. If I want to systematically arrange these meetings on short notice, we need a better option.

I identified one country, one country in the entire world, that will grant a visa to a presentable person from any country, at the airport. That country is the tiny Caribbean island of Saint Vincent. God bless their laid back ways. I am going to go there soon, check out the Internet access, and look for a resort with a conference room. I hear there are some nice beaches there, and they have a fiber optic cable. I think Saint Vincent has a bright future hosting the top brains of the world software business. If you are from Saint Vincent, please contact me.

But, it's hard to get to Saint Vincent. They don't have an airport for big jets. You have to go to Barbados or Trinidad and then get another plane ticket on a small airplane. You can't go through Miami because the Bush administration (did I mention how irritating those guys are) won't give you a transit visa. Blah blah blah. We are going to have to get more expertise with the local travel arrangements if we want to go to Saint Vincent.

Our next choice was Istanbul, Turkey. We have a guy from Moldova, and a guy from Argentina, and a guy from the US, and we can all get visas at the airport for Turkey. It seems that Turkey likes to welcome visitors from nearby Moldova. I've never been to Istanbul before, but I can verify that the crossroads of the ancient world has great modern airline service. You can get there on a variety of airlines, from any other major city with no more than one stop. It's the off-season there, so we had our choice of hotels. I'm looking forward to it.

If you are interested in arranging war-room meetings for your globally distributed team, get in touch with me. We can probably systematize the locations and streamline the travel arrangements. We can identify friendly locations – Turkey, Saint Vincent, and an Asian location, perhaps Singapore. We might even think about having a gathering that also includes an un-conference for all of the teams together.

Teams ARE distributed, and they can still be agile

Andy Singleton — Mon, 17 Nov 2008 06:41:00 GMT

I went to an executive seminar on agile methodology two weeks ago, and an audience member asked about running agile with distributed and outsourced teams. The panel members nodded their heads silently. Then the guy on the left said something like “We try to avoid it”, and the guy next to him said something like “we get better results when we can meet every day”, and the consultant next in line, a woman said something like “we recommend against it.” They looked stumped, and frankly, defeated. It was a very unproductive response to someone that clearly has a distributed team.

Then last weekend I was talking to a guy from Rally, the vendor of agile project planning software, and I gave him my distributed / inspired-by-open-source pitch. His response was short: “We think it's important for the team to meet every day.”

These guys are living in a reality-free zone. They are like ostriches with their heads in the sand. Almost everyone that I talk to has a distributed team. When I first started managing distributed teams ten years ago, it was a little unusual, but a variety of trends make it the new normal. Companies of any size have always had multiple offices, with cross-function and cross-location teams. Then there was outsourcing. The outsourcers tried to control the amount of dispersal by centralizing their staff in big offices, but the clients kept moving around and blending teams. Then people like me got wise about finding good talent and started deliberately recruiting global teams. The escalating costs of commuting, both time and money, left more people working at home more of the time. Finally, there is random motion. People move. Their husbands and wives move. Their company offices move away from them. Almost every team I see that is more than a few years old has some long-time team members that are no longer co-located. Look around you and you will see what I mean.

So, we all have distributed teams. This attitude that distributed agile teams are by definition less productive is unhelpful and defeatist. It's bad propaganda that is starting to irritate me. A MUCH better and more useful approach would be to admit that distributed teams are here to stay and figure out how to make them at least as productive as co-located teams.

I say at least as productive, because although a bunch of guys in a room have some communication advantages over a bunch of guys scattered around the Internet, distributed teams also have some advantages. You can put them together faster, and you can get better talent.

We have taken a systematic approach to boosting distributed team productivity.

The first thing we did is study the process, starting with the amazing example of productive open source teams, and absorbing low-overhead agile methodologies like Scrum. I have a presentation that I give which highlights some of the differences in our process and approach, compared with more traditional teams, and I will post that here in the next week or so.

The second thing that we did is invest in tools like Assembla.com. Our teams get a lot of use from the tools on Assembla.com, the ticketing, the workstream, and the alerts. We invest in build processes, staging servers, and continuous integration, which we also hope to bundle with Assembla workspaces. We also use a lot of Skype chat. I'm going to post some videos and some other examples when I get time.

We're about to take a third step and start having meetings. I'm all about speed, and meetings, which take a lot of time to arrange and travel to, are an obstacle to speed. But I'm not dogmatic. If we need meetings to hash out architecture, then we should streamline the process of putting together a team meeting. As an experiment, I am on my way to Istanbul for our first Assembla team meeting.

The customer is always right, but he can't design your product

Andy Singleton — Mon, 10 Nov 2008 01:13:00 GMT

We recently added a customer request page - feedback.assembla.com - from the folks at Uservoice. Although we have so far only received votes from a tiny fraction of our user base, we have already learned a lot. The top two requests - a customer login with special permissions, and the ability to tune permissions inside a space - are really two views of the same request. "Customer login" is a clear statement of the request. The requester wants to invite his customers as users, but show them a special customer view. "Custom permission for tools" is a suggested implementation. Our blog comments contain a third closely related request - lower charges for customer roles.

So, we have learned what users want. Users are experts in what they want - the ultimate authority. However, they are far less expert in figuring out how to get what they want. They are perfectly happy to suggest an implementation, but if we follow that suggestion directly, we are likely to get a bad result. That makes sense. Designing our product is not their area of expertise. It should be ours.

Customer implementation suggestions, so readily offered, will typically pose two problems. First, they may be impossible, because the customer doesn't know all of the constraints. Second, they are almost always purely incremental, rather than innovative, because the customer hasn't studied all of the options.

For example, a customer might come to you and say "I want to travel from New York to Los Angeles in less than seven hours." Great idea.

But, if you ask the customer how to design the product, he will probably say something like: "I use my car to travel to other cities. I want you to boost the car to 2000 horsepower, streamline it, and build a very, very straight road. Then I will drive to Los Angeles quickly."

This customer is making a series of logical and incremental extrapolations from the current product.

The engineer assigned to build this product quickly sees that the customer's design won't work. He comes back and says "We can build a jet airplane that will fly through the air at 600 miles per hour, and we can build an airport in New York, and an airport in Los Angeles." That would work. But, it's a non-incremental solution, a completely different approach. It requires expertise about the available options and constraints that the customer does not have.

So, now we have the following request, which I will paraphrase as "I want to be able to invite customers and give them a special and controlled view of tickets, documentation, and status."

The suggested implementation - a special set of permissions for someone with a customer role - poses a few problems. If a customer has permission to see one tool, but not a linked tool, he will get "Permission denied" from some links. We will need to assign a new user role for customers, and the team owner will have to manage those roles, without getting confused. If it's not completely simple and clear what is included in the customer permissions, there might be security leaks where the owner inadvertently reveals more than he wanted to reveal. The product is already complicated. We want to make it look simple for the user.

Time to put our thinking caps on and get to work.

Free spaces for student projects - how to get them

Andy Singleton — Thu, 23 Oct 2008 08:43:00 GMT

We will provide free scholarships for student projects. If you have a non-commercial student project, here is how to sign up.

You will add your student space to our "Student Projects" portfolio. Our customer service team will review it and pay for it. You can then run it, or continue to run it, as either private or public. Please make sure it is a non-commercial student project, and remove it when you are finished.

Go to the Admin panel, and select tools, and find the Member tool. Press the Add button.

On the Member tool page, enter the join code "studentproject" and submit.

If you want to write us a message, write in one of the form fields on the bottom.

Tell your school before next semester. Next semester, you will need to get projects from your school. We need to distribute the administration. We will distribute portfolios to universities, and they will manage their own lists of student projects. Please tell your professors about this, so that they can get their portfolio spaces. They should send us a message at info@assembla.com, or create a space to hold the student projects and add the portfolio tool, and then add themselves to our student portfolio with the instructions above.

I hope that this will be the last administrative announcement before we can get back to our regularly scheduled programming about accelerationg software development.

New subscription plans: Clarification, and even better pricing

Andy Singleton — Mon, 20 Oct 2008 22:30:00 GMT

I got flamed by users that felt we didn’t give them enough advance notice about changing the subscription plans and restricting free private spaces. The comment thread from my last blog post was long and educational.

In penance, I will try to clarify a few things here. I will also summarize the discussion, for people that are interested in how Internet products get priced.

First, this is not an emergency. We will provide a transition period of at least a few weeks for free-private users to upgrade or migrate. If we do not hear from you in that time, we will not expose your data, or delete it. We might restrict it to read-only at some point.

Second, the minimum disk charge is currently $0.30 for 100 megabytes. So, the minimum charge for a space is $2.30. Actually, if you read on, you will learn that we are capping the user charges, and the minimum space charge has been lowered to as little as thirty cents!

Third, a "payment unit" pays for $1 of subscription charges at full price. Some of you have opted for advance payments of $100 to get 120 payment units, and I thank you for that vote of confidence.

Fourth, if you are an existing subscriber, you don’t need to do anything, and you will get a price reduction in most cases. We will credit the full amount of your last payment as "payment units" for the new plan. If you think this will cost you money, we can provide additional credits, or a refund.

A few people asked if their team members and customers will have to pay something. Fortunately, in our system, the subscriber / space owner pays for all of the team members. The team members that you invite don't pay, and they never have to submit payment information. We never ask team members for payment information, unless they go to create their own space.

Price Reduction Again! Per user charges limited to $8

Our users are negotiating in various ways for lower prices. I was not sympathetic to many of their arguments because $2 per user is a VERY low price. It needs to be higher to support reliability and features at the level of quality we all want. The negotiation never seems to end. Two years ago, we were charging $50 per space per month, and users said that was too much. We reduced it to $19 per space per month, with a discount to $12.50/month for annual purchase. People bought the annual plans, but others said that the $19 number was too big, and they wanted a way to buy smaller amounts. So, we broke it down into users and disk space, and now we sell a space for as little as $2.30/month. That sounds like an amazing deal to me. There is a limit to how low we can go and not be wasting our time. I have four kids, and employees that rely on me, and they need to eat.

So, it was with a hard heart that I first looked at the analysis from Joao Saleiro, who has six users on his team, and brings them all into 10 projects. That would add up to $120 under the per/user per/space plan. Other people with a lot of projects also noted that their charges would escalate quickly. Joao is exactly the kind of power user that I want on our system, and he’s using the space structure the way I think it should be used. I looked at my own list of more than 60 spaces. He was right! We were charging too much for users with lots of spaces, users like me. I crumbled.

We are making an important modification. The price per unique user will be capped at $8 per month per payer. After you add yourself or a team member to four spaces, the fifth space through infinite spaces are free for that user. If you have the same team in many spaces, the extra spaces cost you only storage charges (30 cents, in most cases), and premium tool charges, if there ever are any.

This means pricing of $8 per user for serious users, and you can forget the "per space.” You won’t have to worry about archiving spaces, because the extra spaces won’t cost you anything. And if you are frugal and have only one space, you can get going for $2.

And, if you pay in advance, you get EVEN MORE DISCOUNTS. If I sound crazy, it’s because I can’t believe it myself. We’re open for business.

Upcoming communications

I learned that users want to receive emails from us about topics like this. In order to reduce spam, we only email to all users about twice per year. We are going to send two emails this week. An email to all registered users will summarize the application upgrades, and an email to owners of free private spaces will present our subscription upgrade offer.

Other suggested pricing schemes

Many of the commenters, persistent negotiators, proposed schemes that would reduce the prices that they would pay. We have adopted the most important suggestion – a limit on per-user charges. I will review the rest here for your comments.

You should show advertisements
Good idea. I’d like some advice from an expert about how to make advertising work for us, if any of you want to provide it. However, it won’t solve our problem, because the fast usage growth is with subversion clients, which won’t render ads. And, we are talking about about private spaces, which have limited visibility anyway.

You should provide free services to us students. We don’t have a good way to pay.
I want help students. I like the student projects on Assembla. We tried providing a special free student plan, but a LOT of people emailed us to request it, so it became costly to administer. I had to work on it nights and weekends. We will try to arrange something for them that will be more automated.

You should sell us a fixed price bundle of users, spaces, and disk quota so we can get more spaces or more users for the money.
This is the Basecamp/Unfuddle pricing strategy. It would result in a price reduction for people who have the right mix of users and spaces. We considered this, but we rejected it for a very specific reason. We want to keep expanding our feature set and adding new “tools” like instant staging servers, which will be amazing but will cost extra money. With fixed price bundles, you can’t add new services without breaking the fixed-price model. What actually happens with vendors that use this model is that they put new features into new products. I have talked to a lot of users of these fixed price bundles, and many of them are spending more than they would spend at Assembla, because they buy more than one product. This is not only expensive; it creates user management hassles. So, we went with “metered billing” – you pay for what you use at the end of the month, rather than a fixed price at the beginning of the month. We give up a lot of cash flow to do this, but it gives us the flexibility to include new services.

I think our $8 per user cap gives you the best of both worlds. You can start as small as $2.30. If you more fully adopt the product, the price is essentially fixed at $8 per user, so you would pay $48 for a six user team, and you can use an unlimited number of spaces. There is no need for “archiving” or any other bothersome space management.

The user charges are too high. You should give us a lower price for “client” users.
We are already at $2 per user. How low can we go before it gets ridiculous? My competitors are charging $50/users. And, haven’t we seen that users will always put themselves into the cheapest category?

You should charge only for disk space. I don’t use much disk space.
We considered this, but we discovered that most projects use less than 100MB. If we charge only for disk space, it would need to be a high charge, which is not what the people making this suggestion are looking for.

You should charge only for “activity”. That way, heavy users will pay more, and I will pay less, because I don’t use my spaces very much.
If we try this, we will have a new argument about what constitutes “activity”. What will you say if I charge you an extra $2 because your RSS reader keeps checking the event list? Furthermore, this sounds like a recipe for receiving a very small amount of money. How will I cover the $40K/month in expenses?

Was this an evil plan?

Thank you to everyone who supports us with words or a subscription. A few commenters called us bad / evil / asshole / disappointing-bait-and-switchers for drawing in users, and then suddenly proposing a change.

Our communication has been limited, even stilted, but our intentions have not been hidden in any deliberate or sneaky way. During the last three months, we have discussed all of the details of the new subscription implementation on our ticket list, which is visible to the public at https://www.assembla.com/spaces/breakout/tickets . Going forward, we will continue to be completely transparent.

The restriction of free plans wasn’t some sort of evil plan. We thought we were doing a good thing by offering the free plans with no restriction for more than two years, and we did not think about restricting the free private plans until recently. The free services have given us a chance to work with a lot of great agile developers, which helps us with recruiting. That is why we still offer a generous free public plan. However, like all bootstrapped startups, we need to be adaptable. We discovered three things that eventually forced us to make a change.

Staffing services will not cover the cost of our software services (the original plan). The standard gross margin of 10% just isn’t big enough to provide a profit, unless we spend a lot of VC money to get to a much bigger size. Assembla is not VC funded.

Many users came only for free private subversion repositories, which are especially difficult to "monetize". I was happy to pay for these repositories as long as the basic hosting and admin and support cost was affordable. Our total costs are around $40K month (making us a small but serious business), and our variable hosting and admin costs are around $10K/month. However, growth of the free services is exponential at about 8x per year, which means that at a certain point costs go beyond what we can afford. A $5K/month expense today (I’m paying at least that much personally for your free services) is a $40K/month expense a year from now (definitely not affordable). Once the exponential turns the corner, it blows us out of the water. And, as the number of users grew, free users started calling me at all hours with support questions, which is another type of expense.

We have a lot of commercial users that will stick with the free service as long as it is private and relatively generous. We need to bring them into the boat as customers.

So, we made a decision to compete for subscription revenue. That's great news for you, because it means we need to do an even better job on our features and customer service.

Release 2.0 - restricting free plans, giving back with features and price reductions

Andy Singleton — Fri, 17 Oct 2008 04:00:00 GMT

Within the next day, we will be releasing a new version of Assembla.com that contains major changes to the subscription packages, and many improvements.

Subscription Changes

We will no longer offer free, private spaces. If you own a free, private space, we will send you an upgrade message later this week asking you to buy a "Private / Professional" subscription, or convert the space to public permissions. You can make a migration decision here.

[Editor's Note: we posted updated pricing here. We posted instructions for free student projects here.]

If you run a publicly visible project, such as an open source project, we will continue to support you with all standard features, for free. If you have a Commercial space, we will roll your subscription into the new, more flexible Private/Professional plan. If you have a free private space and you do not respond, then we will not expose your data or remove it, but we will eventually set it to read-only.

Why are we making this change? We enjoy working with developers and supporting the community, and we will continue to support the community with free public plans, and low-cost subscription plans. We are grateful for the positive feedback and suggestions that we receive daily. However, our free private subversion repositories have become so popular that we no longer have the time and administrative capability to support them at a high level of quality. So, we need to ask more of our users to support the site with inexpensive paid subscriptions.

In return, we are offering a simplified payment plan that will result in a price cut for most subscribers. The "Private / Professional" plan costs $2 per user per space per month, plus $3 per gigabyte of file and repository usage. You can buy it for any space that requires privacy, improved security, or more disk allocation.

A lot of users told us that they had multiple spaces for personal use, or small teams, and they wanted to buy in smaller increments. We heard you, and now we are giving you full professional support with this amazing deal.

If you have bigger teams and more spaces, the deal gets even better. We are now offering the portfolio, branding, and staffing tools for free - formerly a $150/month value. Just select the Manager and Employers package from our new catalog. And, if you pay in advance, you can get additional discounts of up to 50%.

If you already bought the old Commercial subscription package, we love you forever. You are probably getting a price cut, and you don't need to do anything. We will credit the full amount of your last payment into the new "metered" payment plan. Contact us directly if you want any other adjustments.

New Features

This release contains three months worth of upgrades, some very visible, and some more subtle. Here are the completely new features.

Catalog: The first thing that you will notice is that when you go to create a new space, you select your configuration from a catalog where the various tools are clearly explained, and pre-configured. We will expand the catalog over time with packages that contain code for popular development platforms, and with packages for other types of non-development collaboration. You won't have to figure out all of the new tools. You just click and go.

Do you start every project the same way? You can customize the spaces to make your own templates, and then use the "copy this space" link at the bottom for the same click-and-go effect. You might even consider contributing your branded content and methodology to our catalog.

Integrated Subversion: We are piloting an integrated Subversion browser for looking at source code and changesets. The Trac code browser has served us well, but it doesn’t feel integrated, and it is missing some features from the best modern code browsers. Our repository support needs to match the best of breed. The new Subversion browser eliminates an additional login, includes full user names and profile links, and has nice features like “view” which will serve up HTML files with relative links. As soon as this is ready, we will apply the same design to upgrade our git tool with full support for branching and forking. And, we will release it with a free open source license so that you can also run on local repositories.

Twitter tool: Send your team activity to Twitter and follow it wherever it goes.

Mylyn connector: For Eclipse users, we added a MyLyn connector so that you can view Assembla tickets and track time inside Eclipse. It takes advantage of continued API improvements.

Improvements

Tickets: We improved the integrated Tickets tool with better formatting, reports, and export capabilities. My favorite new feature is a screen capture applet that pops up from from the Ticket attachments panel to capture a picture of bug in seconds. Get an RSS feed of changes and comments for any ticket report, including “My Tickets” (that is, your personal tickets). We upgraded the script that imports tickets from Trac, so that it will capture custom fields, type, resolution, and other fields. We now capture and attach comments from svn, git, mercurial, and github, so it might be time to import and switch to Assembla tickets.

Chat: Now works through firewalls

Mercurial: Now shows commit events in the Stream and Dashboard.

Git: User keys are automatically resynced.

Wiki: Allows raw HTML, iframes (embed Google calendar, for instance), and has formatting fixes.

Have it your way: Are you using a Trac wiki or a Basecamp or Google groups messaging system? Wiki, Messages, and files are now optional tools. You can strip a space all the way down to its essentials: The "Team" list, and the "Stream" view of team activities.

Under the hood

"Under the hood" are invisible changes that will power a lot of improvements in the next few months.

We improved our architecture for adding “external” tools as new tabs. We have long supported Trac as an external tool. We have now integrated online services like Github, user-hosted svn repositories, and Twitter. More are on the way, and we are documenting a tool development kit so that you can insert your own team application.

Our most radical move was to build a new piece of infrastructure – the Event Hub – to let you see what your team is doing around the net. It collects events (code commits, ticket edits, new messages) from Assembla internal tools and displays them in the Stream and alerts. It can ALSO capture events from external applications (for example, your external repositories), show them in the Stream and alerts, and ROUTE them to other external applications (in a simple example, Twitter). It’s like a permissioned friendfeed for a working team. With this improved architecture, email alerts will be sent as soon as the events happen.

Internationalization of many features will allow you to view the Assembla site using your native language, as soon as we build and test translations.

Get involved!

Work on translations to other languages. Some users have emailed to offer translation services. Now we are ready to use the translations. If you want to write and test a translation, please send an email to info@assembla.com and tell us your language and your rates or payment structure.
Build packages for the catalog. Do you have your own project templates on Assembla? Are you a consultant who can package your platform or methodology into the wiki, settings, and code repository of a template space? For example, if you make a living doing J2EE Web development, and you have packaged the initial documentation, code, and build scripts into a space, other users can benefit from that. You can contact us about publishing and promoting your branded template space in our catalog. It could be a great lead generator
Add your tool or application to Assembla. If you have a tool or application that Assembla teams can use, we might be interested in helping you package it as a tool in the workspace and promote it in our catalog. We can even make sales and collect money at prices that you set.
Add your questions and suggestions to the forum.

Surviving and Thriving in the Best of Breed Web

Andy Singleton — Fri, 17 Oct 2008 03:45:00 GMT

About six months ago, we noticed we were getting our butts kicked. As I talked to leading edge developers, I found that many of them were not using Assembla. They said they liked Assembla, but they wanted to use some one tool that wasn't on Assembla - a repository, or a messaging system. They ended up registering every team member for several different services, to get the capabilities they could get from Assembla all in one place. For them, the single team list and login at Assembla wasn't a benefit. They were willing to put up with the hassle of multiple accounts and kludgy Web services, because they wanted Best of Breed.

This is a major trend in Internet buying behavior. It will affect everyone that sells application services. Read on to find out what we are doing to survive and thrive on the Best of Breed Web.

To see how Best of Breed becomes a powerful driver of buying behavior, consider a situation where a user needs three capabilities - a code repository, a message/discussion system, and a ticketing system. Imagine that Assembla provides a capability in each category that is competitive with the best service available anywhere else in the world. In this scenario, Assembla is awesome. When comparing Assembla's integrated feature with the best feature available in the world, a user will select Assembla 50% of the time. Even in this case, the awesome Assembla case, there is only a 12.5% (1/8) chance that Assembla will be preferred in all categories. 87.5% of the time, the user is tempted to go with best of breed

On the Internet, an application that tries to force the user into a complete and isolated solution (as our users suspected Assembla was doing), will only get a small percentage of users. On the other hand, if an application is clearly best of breed in one category, it can wedge itself into the best of breed bundles for many users, and benefit by getting links from all of the other apps. You can offer a complete solution - many people will appreciate the convenience - but the first rule is that you need to be best of breed at some one thing. That one thing is what gets you into a lot of bundles.

We needed to find our entry in the best of breed race. Many of our users come to Assembla for Subversion, and often they come only for Subversion, so in the eyes of the marketplace, that was our best of breed slot. However, Subversion is a commodity that is available from almost any hosting compay, which sets a very low pricepoint, even for our enhanced version. We have been working to bring our Tickets tool up to best of breed status. It's good, useful, popular, improving quickly, and near parity with the best of breed. We will achieve best of breed with Tickets. However, it's in a crowded category. It would be even better to have a high-value, original, unique offering.

After thinking about this for a few weeks, and trying to work with disjointed best of breed bundles selected by clients, we realized that Assembla had a huge new opportunity. The people who are running their teams with best of breed bundles have created new problems for themselves that need to be filled with new best of breed tools - Team, and Stream. When we originally wrapped the Assembla application around Trac and Subversion, we solved those problems.

Team: The first problem is simple - keeping the team list. If we can add team members in one place, and then replicate the team, we prevent problems for new team members, and if we can remove them in one place, we prevent security problems. So, if we can replicate the team members or permissions from the Assembla team tab, we make life a lot more convenient.

Stream: You want to see what your teammates are doing. This second problem is more complex, but more important for driving productivity. I talked about this as Workstreaming. Workstreaming is like lifestreaming, like a professional version of Twitter of Friendfeed. However, it's more complicated because the you can't just share your work activity (events) with all of your friends. The permission to see them is controlled by the project owners. So these events get organized into permissioned project views like the Trac timeline or the Assembla Stream tab. If we could gather a wide variety of events into the Stream and Alert system, we could build a powerful view of activity that would unify the team, improve communication, quickly expose and resolve issues, and provide visibility for managers.

So, in this new world, you want to make a list of the apps that your team uses, and have some godlike hub application replicate the permissions and show you everything that team members are doing. In Assembla, it might work this way:

Create an Assembla space with just the Team and Stream tabs
Select the external applications that we use from the Tool list in the Assembla space. These tools are "external" tools.
Go to each tool tab, open the settings panel, and put in the information that allows us to connect to our account on the related app: user credentials, API credentials, RSS URL, etc.
Use buttons on the tool page to replicate the team or data, if those operations are supported by the external tool
See everything that your team members are doing in the related applications, run reports to see what happened, register for activity alerts to see what is happening now, and send the activity "events" to any of the related applications.

We went to work building the architecture to make it happen. We streamlined our tool architecture to make it easier to add external tools, and started working on documentation for a development kit that outside developers can use to add their tools.

If we end up supporting hundreds of tools, then it will be confusing for users to configure them and connect them together into useful combinations. So, we built a catalog where users can select a preconfigured combination of tools with a single click.

Introducing the Event Hub

The Event Hub is a major piece of infrastructure for the Best of Breed Web. It's necessary. Without the event hub, every application needs to implement many interfaces to other applications, and there are millions of combinations. For instance, if a repository system wants to post commit events to ticketing systems, it needs to implement a different Web service for each supported ticketing system. With the event hub, the repository only needs to post commits to one system - the event hub - and from there they can be distributed to any supported ticketing system.

Enterprise - they prefer integrated

I will note that Enterprise buyers will prefer an integrated solution rather than a best of breed bundle. Inside the corporate firewall, there is not as much choice to put together a bundle. Enterprise buyers want software that meets a consistent standard of security, compliance, and support, and we've got a great integrated offer for them.

Dogma barks at "Mythical Man Month" reference

Andy Singleton — Sat, 23 Aug 2008 18:13:00 GMT

My call to Vanquish the Mythical Man Month got a lot of pushback from "Mythical Man Month" defenders, including a series of rebuttals in the blog comments, and some defensive comments on Reddit.

It's hard to give up comforting bit of dogma, especially when wrapped around ideas as sophisticated and helpful as the Mythical Man Month. You feel well informed at having understood it. It makes you feel smart. And you get great feedback from your peers, who also feel smart.

Let's go to the comments:

"I enjoyed the comments, especially the one taking the author to task for presenting unsubstantiated theories to counter the scientific studies cited by Brooks."

I am guessing that the person who wrote this has never read the book, but feels smart anyway. I didn't see the scientific part of the Mythical Man Month. It's got a lot of references to real projects, but very little in the way of scientific data. To see if I missed anything, I went out and found a more recent copy, the "20th Anniversary Edition with four new chapters". I found a couple of good statistical references. Page 30 cites evidence that good programmers can be 10 times as productive as others on the same project. I agree with that, even built a business around it, but it doesn't shed light on the scaling problem. Chapter 8 presents evidence that larger projects go more slowly. I observed that in my opening sentence. It's the whole point of the discussion. The book is useful even if it is anectodal, and so is my response. Fortunately, my question about dependency can be scientifically analyzed, as noted later in this article.

"You're kidding right? Brooks' law: adding manpower to a *late* software project makes it later. ... Adding manpower early to an understaffed project will improve its chances of on time completion but as sure as someone on the internet is being called Hitler, there will reach a point where you will get negative returns for every engineer you add to that project."

Brook's law isn't really a law. It's an epigram, a witty saying that sticks in our heads and reminds us of our limits. Brooks calls it a "zero order approximation". It's NOT scientific. You can't show this statement to be true or false because you can't do a controlled experiment where you split a project, and add manpower on the first fork, and don't add manpower on the second fork.

I can think of a lot of times when adding manpower to a late software project will accelerate it.

- When nobody is really working on the project. This is a common case. Often people are fixing bugs on the old system, or a different system.

- When the team isn't very good. The project will go faster as work gets handed off to better people.

- If you have an unlimited budget and you can ask people to work on items in parallel, independent efforts. At some point, random differences in approach will make one effort faster than another. So, in my opinion, the limit as you expand the resources to infinity works against Brooks's law, not for it. Otherwise, you just aren't thinking big enough or parallel enough.

There was a strong reaction to my statement that "you need two developers working 40 hours per week to replace one developer working 60 hours per week. That is exactly why good developers work such long hours."

"I quit reading after '...good developers work such long hours.' More hours in the office == more bugs. Don't hire the folks that work 60-80 hours a week, hire the ones that'll work 35-40 and yield the same output."

"Good developers do 60 hours worth of work in 40hrs, the better ones in 30 hrs or less... good developers are useless if they're overworked and demotivated by clueless managers"

"Personally, after reading the article, I wouldn't want to work as a subordinate of the author. "

"My reading of the article is that it's easy to vanquish the Man-Month by exploiting your minions..."

The truth hurts. I knew that this observation was going to make people emotional. But, I couldn't leave it out because it explains so much about the software business.

To the argument that this smacks of exploitation and that you shouldn't work for anyone who believes it, I present the evidence that almost every startup entrepreneur works very long hours. Are they exploiting themselves? Should they stop working for themselves? Are they being stupid because they won't hire two guys to do the same work, or a better guy to do it in fewer hours? No, they are being rational. The scaling problem makes this the most efficient way to get work done. People who want to work fewer hours (and much less efficiently) go to work for big companies where they truly are "exploited" with a 35 hour work week. If you really care about working conditions for developers (and I do, I am a developer working very long hours), then you will embrace the truth of this observation and start working to reduce the problems involved when scaling from one developer to two.

To the argument that you should just hire a better programmer who works fewer hours, I ask, "Who does this?" Since when do the best programmers work fewer hours? I have never seen a case where a good programmer works 30 hours per week, does more work than the other three developers on the team, and then goes off surfing, while the others work overtime to catch up. More likely, the good guy is working 60 hours, and doing the work of six others. That's where the 10:1 productivity ratios come from. The painful, paradoxical truth about the programming business is that good developers don't get rewarded for higher productivity, at least with time off. Salespeople do. It's blatantly unfair. But it is efficient. There is a huge motivation to ask the more productive worker to work more hours. Once you understand this, you can work with it, and extract a bigger reward.

The commenters reminded me that "There is no silver bullet" [for accelerating software projects]. That probably is true. It's Brooks' parting shot. But, I must remind the audience that Brooks was driven to give this advice only after he went out searching for the silver bullet. The master is more flexible in his thinking than the followers.

The research project - Communication versus Dependency

I didn't get a thoughtful discussion of the main question: Do software projects scale poorly because of communication problems (workers have to spend more time figuring out how to communicate with more other people), or because of dependency problems (workers are waiting for someone else to finish something specific).

Communication versus Dependency IS the beginning of a scientific proposition because you could actually test it. What we would need to do is examine a bunch of large-scale software projects, and find team members in these projects who were not progressing by some metric, and ask them what the problem is. Are they not progressing because of communication issues (confused, contractory information, or information unavailable), or are they not progressing because of dependency issues (they are waiting for something specific to be delivered).

If you know of some large scale software projects that would be interested in doing this survey, let me know. We will collect some data and report back.

Time to Vanquish the Mythical Man Month

Andy Singleton — Sun, 10 Aug 2008 16:40:00 GMT

Developing big and complicated systems quickly remains a difficult problem. Big, complicated systems cost a lot more per "function point" than smaller systems, and they famously seem to resist attempts to accelerate them. It often can't be done, even when a big organization is willing to spend unlimited funds to get results. However, the availability of unlimited funds should provide motivation for the entrepreneurial among us. I think these big projects CAN be accelerated, using ideas pioneered in open source projects.

The Mythical Man Month is an analysis by Fred Brooks of the problems involved in truly large software projects, using the example of the effort that IBM started in 1967 to build OS/360, the operating system that would go on to run most of the world's mainframe computers. Brooks noted that "Adding manpower to a late software project makes it later" (Brook's law). He also pointed out that "Nine women can't make a baby in one month" - a reference to the problem with the idea that you can add more people and get productive "man months" out of them.

You have probably read this book. At a recent gathering of 25 CTO's, I asked who had read The Mythical Man Month, and 23 hands went up. It's a great book, but it's dogma now, the conventional wisdom.

The statistics in Software Assessments, Benchmarks and Best Practices put numbers to the scaling effect. Productivity is measured at 15 function points per developer month for software having 100 function points, declining to 5 per developer month for projects having 10,000 function points, at which point 67 people were involved. The author notes that "projects having more than 100,000 function points are more likely to fail than to succeed." Typical staff size on these projects was 690. There lie dragons.

Software development productivity has improved enormously in the past 30 years. Today's developer has fast hardware, dynamic scripting languages, instant access to tools, documentation, and advice over the Internet, and decades of experience in development process to draw on. As a result a contemporary developer able to produce a lot more "function points" per day than a developer could produce 30 years ago, or even 10 years ago at the height of the Internet bubble.

If one person today can do the work of 5 people from days gone by, that in itself ameliorates the problem. For any given project, our staff only needs to be one fifth as big. We see small entrepreneurial teams doing work that big companies did 15 years ago, and bootstrap entrepreneurs producing products that would have required millions in venture funding ten years ago. If you don't want to fail, don't take on big projects. You can wait for them to become small. However, this is an unsatisfying solution, because our software becomes continually more complicated, and over time, the functionality expected by the user inccreases just as fast as our developer productivity. To produce great systems, we must slay the dragons.

I should also note the the scaling problems are actually worse for small projects. For example, when you go from 1 person to 2 people, you get a big decline in developer productivity. I usually estimate that you need two developers working 40 hours per week to replace one developer working 60 hours per week. That is exactly why good developers work such long hours. Improved scaling ratios will have a disproportionate benefit for small teams that need vacations.

I am one of the few development managers who feels free to ignore Brook's law. I will add a lot of developers to any project, if I can afford it. My limits are imposed not by productivity, but by the fact that I have limited funds for my own product development, and that my clients, like me, are cheap entrepreneurial bastards.

Linus Torvalds provides a more famous example of a developer ignoring Brook's law. Although much of Linux is built by a small core of very dedicated developers, there are currently about 1000 kernel contributors. This has produced a steady, rather than a declining, scaling effect. The kernel has consistently grown by about 10% per year.

I think that Brooks is fundamentally wrong about the cause of the scaling problem. He points the finger at communication problems. If you have N people working on a project, you have N squared communication channels, and each person needs to spend more time communicating. Furthermore, if a new person tries to come into a big project, they have to get a lot of information from a lot of different people, so the ramp up time is increased.

Brooks proposes various tactics to reduce the complexity of communication, including having a master architect produce a well-documented architecture and manual, and having designated "tool makers" to supply each team and subteam. Essentially, he's recommending that we translate a network of technical communications into a hierarchy with a lot fewer connections.

If we compare Brooks' recommendations to typical practices for Linux development, there isn't much overlap. Code is accepted hierarchically, moving from "contributors" to "maintainers", but this is the output, not the raw material. It's done to control quality, not to provide information. Tools and architecture ideas are expected to come from a variety of sources.

I think the scaling problem is not a communication problem; it's a dependency problem. It's not necessarily true that when you work on a bigger system, you need to do more communication. However, it is always true that you depend on more things, so you are more frequently waiting for something else to get finished. Take a close look at a development team of 100 people. At any given time, 50 of them are waiting for something from someone else. That effect alone can account for the observed 50% degradation in productivity compared to a six person team where a blocked team member can demand, or build, an immediate fix.

From this point of view, you can see that open source projects have a huge scaling advantage because all code is shared. If someone is waiting for a component, and they are frustrated enough, and talented enough, they can just fix the problem. The code is all shared, anybody can build and fix any component, and the responsibility for critical components can move around. The answer to the dependency problem is less hierarchy, and fewer official tool builders, not more.

If we do grant some truth to the idea that bigger systems require more time from each developer for communication, we can see that are ways that modern developers reduce this time. Most notably, they share code. Code is a relatively crude form of communication compared with deliberate documentation, but it's accurate, and it's immediately available.

Furthermore, Internet projects tend to communicate in writing, on tickets, blogs, mailing lists, and wikis that are accessible to all team members. This changes the communication from a network of conversations that take time from a lot of people, to a simple text search that a team member can do individually. Perhaps this is why the time spent on conference calls is, in my observation, a good indicator of management problems.

So, what are the takeways for me?

It is possible to be productive in big groups, and I think it could be a lucrative area of study.
It is important to share code, and very important to accept new components and fixes not only from designated developers, but from the users of that code.
It is important to share ideas in writing.
Control quality by being hierarchical and rigorous about how you test and accept changes, not how you generate them.

Time for Genetic Programming?

Andy Singleton — Mon, 23 Jun 2008 12:50:00 GMT

The announcement of a petaflop computer has resurrected my dream of computers that write their own software and come up with their own ideas. That would take us a long way toward delivering our promise of "accelerating software development", with a completely different mechanism than the organizational mechanism I am using now. I've written before about ways that computer-generated code could be woven into a rapid application development process.

15 years ago I worked on genetic programming – the evolution of computer programs. However, I ran into a severe shortage of computing power, eventually filling a rented house with racks of single board computers (top of the line, 40 megahertz 80486) in clusters. Genetic programming requires vast amounts of computing power to generate and simulate millions and millions of functional cases, and the computing power of my homemade cluster was pathetic by the standard of today's desktops. Genetic programming is ideally suited to make use of parallel computing, and it can make good use of almost any topology – clustered, or MIMD, or SIMD/vector. The IBM monster is a useful combination of these architectures - Cell vector processors out of the Playstation combined with independent Opteron processors out of a PC.

If we can't get useful results from these new computers, we're doing something wrong. And, in fact, we are doing something wrong. We fundamentally don't understand evolution. The evidence is in that increases in programming capability of 1000 or more over previous systems have not significantly increased the rate of new discoveries. There seems to be a limit on the complexity of the evolved artifacts, and with the faster computers, we are just hitting those complexity limits faster.

There is an "existence proof" for the effectiveness of evolutionary methods. DNA-based life forms are amazingly complex. A human genome has at least 30,000 genes. The most complex genetic programming artifacts have only about 100 active elements.

What will get us over this hurdle? I have some ideas, a three point plan.

Cooperative mechanisms

The high-school depiction of evolution as a survival-of-the-fittest competition is crude and limiting. In the real world, organisms and genes co-evolve and cooperate in expanding systems. We still haven't fully absorbed the lessons of Lynn Margulis and others studying symbiosis and cooperation.

Genome structure

If you try genetic programming, you will find that running the evolutionary algorithm has an immediate and powerful effect on the genomes - the code fragments that you are evolving. The first thing that they do is expand and add redundancy - something like the introns that make up most of an animal genome. This change in the genotype moderates the effect of mutation operations, without changing the phenotype - the output - and it's crucial for making the process run smoothly. So, we see evidence that the structure of the genome is a hugely important player in the game of evolution. It's no accident that our animal genomes contain chromosomes which cooperate and co-evolve, or that they contain lots of "junk" DNA. These structural features are what make complexity possible. If we understood why the genomes are set up this way (we don't, mostly don't think about it), we could make much better genetic programs.

Discovery with Meta-Genetic Algorithms

We have questions cooperating systems and appropriate genomic structures. Now that we have big computers, we can answer these questions with a meta-genetic algorithm machine. This machine will generate new genomic structures and population parameters (new types of Genetic Programming), and run the lower level genetic programming runs to see the results for each set of parameters. This is exactly the kind of machine that I built to run on my primitive rack clusters. In one run, it could answer questions a the level of PhD thesis. For example, the Meta-GA very quickly identified the programming operations and inputs that would be most effective. However, it had to run for days because it would run thousands of runs with the lower level GP to find the higher level parameters. Hence the problem with computing power.

With the more powerful machines, we can resurrect the meta-evolution layer, look at a range of genome structures, and find a way to harness cooperative evolution. Did anyone follow that?

Cloud Computing is Hot at Railsconf

Andy Singleton — Thu, 12 Jun 2008 09:58:00 GMT

Last weekend I spent 1.5 days at Railsconf. It was a 6,000 mile round trip squeezed into a weekend between busy working weeks, and interrupted by the datacenter explosion that took down our site. So, I didn't get to see many technical talks. I did get a feeling for what's hot: cloud computing.

The vendor booths were dominated cloud computing infrastructure providers. Amazon was there representing EC2, the key enabling infrastructure. Heroku showed rails development and deployment on EC2, backed by their recently announced VC funding. Morph showed a more enterprise-oriented service for hosting and scaling Rails and java applications on EC2. Rightscale showed a polished version of their more general-purpose EC2 cluster management tools, backed by their recent VC investment. Engineyard, which runs their own full-service, fully staffed virtual server cloud, was doing a booming business, backed by their recent VC investment. They talked about releasing some of their management tools as open source projects. Clearly the Silicon Valley money is going into infrastructure at this stage. Sun was showing off an Assembla-like workspace that will showcase their ability to host team applications on their cloud computing infrastructure. Google was the big player that wasn't there, as their recently announced Google App Engine runs only Python and faces off against the Ruby-centric Amazon cloud.

I'm a convert to cloud infrastructure. We have started moving our clients onto Amazon servers. Assembla.com was hurt by our dependence on a more traditional server topology, and we'll be moving it into a virtual server cloud over the next month.

There are number of implications for software developers:

You can get instant staging servers. Start releasing even faster. We find this very useful, and we will build it into Assembla workspaces.
You can put high-volume fragments of your app on high-volume hosts. For example, the big selling point of Google App Engine is that it can handle a very large number of HTTP requests and survive a slashdotting or a facebook-scale rampup. If you are considering adding a facebook front end, or a component like polling chat that is very request intensive, you have an incentive to throw that onto Google App Engine and link it to the rest of your systems with web services.

You need to think about file management. Files in a system like Amazon EC2 don't just live on a permanent, homogeneous SAN. You need to back them up to a storage cloud (S3) and restore them when you move to new virtual servers. Amazon and Google offer BigDB and SimpleDB, which aren't exactly the same as the databases and persistent stores you are used to.
We have to move beyond HTTP request based applications to new mesh-computing architectures that send messages in real time. I saw some interesting projects based on the XMPP jabber protocol, Erlang, and the eJabberd server, which is a jabber server written in Erlang. To back up, XMPP is a protocol for sending messages to jabber instant messengers, but it can also be used to send messages between servers, or to route messages through a high-volume cluster to handle Twitter style applications. Erlang is a computer language that naturally distributes processing to multiple servers. We are seeing these tools deployed to manage servers in the cloud. However, we are also seeing applications in which browser ajax panels connect directly to XMPP servers for real-time chat or dashboards.
Having a professional-quality repository with a build, stage, release process is important for cloud applications, because your team and your code are likely to be distributed in the cloud just as your servers are.

Do's and Don'ts for User Stories, Use Cases, Scenarios

Andy Singleton — Wed, 11 Jun 2008 12:32:00 GMT

The “User story” or “use case” is a powerful tool for designing software. You pick a user, or “actor”, with a specific goal, and you diagram the process / workflow by which the user employs your system to accomplish the goal. Many of the projects that I see do not use this tool effectively, and as a result end up lengthening development cycles. Here is a list of issues, and fixes, that will make your stories more useful.

Generic user: This is the single most damaging user story mistake. You define an imaginary user with very broad needs, a “scientist” or a “mother”. You run into two problems that kill your ability to release software early and often. First, this generic user has a very broad set of needs. You end up looking at a huge number of features. Second, you can't actually call this user and ask specific questions - “red or blue?”, “do we need a lookup here?”. So, you don't get any of the details that you will need for implementation. When you diagram a user story, you should have a specific user in mind. This user only has a small number of specific requirements, and this user can answer detailed questions.

One demanding primary or reference user: You can go too far and pick one user. This causes delays because this one user may have some one particular feature they really really want, even if it is irrelevant for most other users, and hard to build. They probably volunteered to be the reference user because they have an agenda. It pays to shop around and find less demanding users for your early releases.

Unfamiliar user: Software design is most effective when you are designing software for yourself. The user stories in this case are easy to get, accurate, and nuanced. A high proportion of really good software is built by people for their own needs. If you find yourself building software for users that you don't understand, you have a difficult problem. You can learn a huge amount from interviews with the intended users, but you will miss some things that will only come out when they test the prototype. I suggest two maneuvers in this case. First, you should make yourself into the user by walking through the process yourself. You will be like the hotel company CEO that takes a day a year to work the reservation desk, and ends up leading a rebuild of the entire reservation system. How many times have we heard that story? One way to get started is with a paper trail. I like to collect all of the pieces of paper that go into or come out of a business process, and pin them into a storyboard. You find a lot of data structures that way, and some workflow. Second, you need to partition your user base and find users that will take early alpha and beta releases. Your user stories will come more by feedback than by initial specification, so getting releases in front of external users becomes more important.

Non-user features: The user story concept isn't very useful when you are working on features that users don't see: infrastructure, architecture, middleware, administration, etc. You can make it more useful in these cases by remembering two things:

System administrators and developers are users too. They have user stories.
If you really want to be agile, you build the underlying infrastructure As Late As Possible. You get releases to users faster, and you save yourself a lot of work in the cases where you find you don't end up needing the infrastructure. So, there is an argument to build the minimum amount of stuff that supports a visible user workflow.

Vague stories: Vague user stories without a specific user or actual example task will not give you the details that you need to do an implementation. You aren't doing any damage with them, but you are wasting your time, because you aren't learning very much.

Textual stories: If you have been in software development business long enough, you will eventually encounter a specification that has been built with use cases and formal requirements based on something like the Rational Unified Process. The first encounter is very impressive. It drops onto the table with a loud THUD, 400 pages of printouts. In some ways, this is a very useful document, filled with details that will help the developers go forward. However, it incomprehensible to the human brain. It has long lists of labeled requirements and step by step processes. You cannot absorb information in this format, and you cannot explain it to your users and project sponsors. It fails the first purpose of a user story, which is to get feedback from the subject of the story. So, you end up getting diminished benefit from the (expensive) planning process, since the user will ignore the specification and instead provide feedback only after seeing the prototype.

The solution: Make pictures, storyboards, and not text. Everyone will understand the storyboard. A storyboard is simple, even simpler than a flowchart. It's basically a flowchart with only the components that a user will see. It shows screens that the user will encounter while working with the system, and links that represent transitions between screens. It can be converted directly to a mockup. You can skip most of the text and write it in later as ticket detail and comments.

An explosion ate our servers - how cool is that?

Andy Singleton — Mon, 02 Jun 2008 12:18:00 GMT

Our site started misbehaving on Saturday when we got this message from our datacenter: "...electrical gear shorted, creating an explosion and fire that knocked down three walls surrounding our electrical equipment room ... This is a significant outage, impacting approximately 9,000 servers"

An explosion. How cool is that? It's way cooler than having a guy accidentally dig up your wiring with a backhoe, or run it over with a truck. It's an outright privilege compared with the squirrel that ate the fiber cable. Imagine spending nights and weekends rallying your troops around a disaster recovery plan, all to do battle with a squirrel. That would be humiliating. My wall of flame incinerates your squirrel.

The flame walled us off from three servers out of the approximately 8 that we need to run Assembla.com at full power. In theory, the rest of the system, including the www.assembla.com site itself, should have continued to work properly. In practice, we found that processes on the remaining servers would hang while waiting for responses from the missing servers, and users would get “Unavailable” errors on www.assembla.com or find themselves unable to access trac.

It's better now. The missing servers are back online or replaced. We'll be moving to improved virtual server topologies that will hold up under explosive attack.

Server problems on June 1

Andy Singleton — Sun, 01 Jun 2008 11:59:00 GMT

Many of you are experiencing problems accessing assembla servers. If you get a "Service Unavailable" error on www.assembla.com, you will be able to get through, but you may have to refresh. If your svn repository is on the server "svn.assembla.com", it is offline. Other svn servers are working correctly. Some trac services may be hanging intermittently.

We hope that everything will be fixed in time for the work day on Monday.

We have received a message from our datacenter that says:

"...electrical gear shorted, creating an explosion and fire that knocked down three walls surrounding our electrical equipment room Thankfully, no one was injured. In addition, no customer servers were damaged or lost.

This is a significant outage, impacting approximately 9,000 servers and 7,500 customers. Our initial assessment, although early, points to being able to have some service restored by mid-afternoon on Sunday."

Fortunately, most of the Assembla servers are still online. However, there seem to be communications with the servers that are offline that can hang some parts of the system. Again, we hope to resolve this quickly.

3 Options for Rebuilding Your Software Without Risking Death

Andy Singleton — Mon, 28 Apr 2008 00:18:00 GMT

Rebuilding your software to update the architecture is the riskiest development project you will ever dive into. Big, successful companies have been crushed by this task. The right tactics are essential. Recently, a more moderately sized company called me in to advise them on a much-needed rebuild, and we broke the tactical options down into three categories - "standard", "incremental", and "buy", each with its own advantages and disadvantages.

A personal story illustrates the risks involved. In 2000, I launched a rebuild of my PowerSteering product. There were all sorts of reasons to rebuild the product, the least important but the most motivating being that we wanted to make the product extensible in some exciting new ways. Over the long term, this turned out to be the right thing to do. We added a lot of new capabilities that customers appreciated. However, this was a crushing mistake for me personally. We were coming to market with this product in 2001, just as the big recession hit, and we were carrying the extra expenses of the product rebuild. We got some VC's involved, and they set to work with a well-oiled plan to fire me, strip me of the assets that I had invested in the company, and dilute me out of a meaningful shareholding. It was hard on my pregnant wife.

In this case, we had a rare controlled experiment. Someone else took the same code and went into an alternate universe without a rewrite. An entrepreneur had approached me to purchase full ownership of some project management code, so that he could turn it into a product for his startup. I sold him the OLD code for a nominal sum, with a stipulation that he should send me $200K if he ever sold it. He changed the front end to be more industry specific, but he never made any upgrades to the underlying code. A few years later, my (former) company got a check in the mail. It turns out he sold the company and the product for $6M.

Dharmesh Shah elaborates upon this lesson in Why you should almost never rewrite your software.

Why take the time and expense to rebuild software? Because after a while, it becomes harder and harder to do the things that you want to do. There is an ever-increasing amount of code that is structured incorrectly for the new demands you are placing on it. Eventually, it looks easier and faster to rebuild the software with an updated architecture, than to continue working with the old code.

Here are the three major options:

1) Standard Approach - Prototype and expand

The standard approach is to build a prototype of the new product, and then expand it into a complete application.

Advantages: This approach has the advantage of being relatively cost efficient. During the prototyping phase, you can work with a very small team, or even your best individual architect. And, you can make significant changes to build the product you actually want.

Disadvantages: The start of the project might be delayed by work on specification, to ensure that the important details of the old product make their way into the new product. And, it's risky. Once you commit to expanding the prototype into a complete application, you enter a potentially long period in which you are spending extra money on development, and you do not have an up-to-date product. In the worst case, you have a situation like the one faced by Microsoft when they release a new operating system, where the new product needs to do everything the old product did, or it will break customer installations. You could hold your breath for a long time waiting for this to happen.

2) Incremental

In the incremental approach, you replace big components of your software with more modern components, or you refactor the existing code. However, you do this in a series of steps that leave you with a releasable and saleable product after each step. This is often compared to "rebuilding the plane in the air".

Advantages: The big payoff is that you have a much lower risk of ending up without an updated product. A more subtle advantage is that you don't need to do as much specification, if you are willing to say that the new product should do basically what the old product did. That saves you time.

Disadvantages: Compared with building software from scratch, this is more complicated to do, and it takes longer. You are working with a larger codebase, and you have to figure out how to keep the plane flying while you rip off the engines.

3) Buy

You might be able to acquire the rights to something that does most of what you need to do (see my story). In an open source world, you might be able to take something off the shelf and adapt it. In fact, modern product rebuild plans almost always contain a significant component of buying or borrowing from open source. As the amount of software in the world grows, it's increasingly important to do research to find out what you can acquire or adopt.

Advantages: Much faster, and probably cheaper.

Disadvantages: Might not meet all requirements. Might place some restrictions on the ultimate value of the asset.

In this case, we decided on the "Incremental" option. The team was able to come up with an amazing plan in which every aspect of the architecture was replaced, but an existing application would still run correctly at each step. If you find yourself contemplating a rebuild, the reduction in risk from the incremental approach is so great that is worth applying your best brainpower to figuring out how to do it.

Planned downtime for server upgrades, tomorrow, April 10, from 7:00 to 9:00 UTC

Andy Singleton — Wed, 09 Apr 2008 11:19:00 GMT

Tomorrow we will upgrade our server configuration to provide improved performance and private URL's. The Assembla.com servers will probably be down from 7:00 to 9:00 am UTC, or 3:00 to 5:00 am EDT. Thank you for your support and patience.

Workstreaming

Andy Singleton — Wed, 09 Apr 2008 11:06:00 GMT

An increasing number of people blog, add to their facebook page, twitter, and post pictures to document their entire life, and they call it Lifestreaming. It seems like an unstoppable trend. In the future it is likely that we will have phones or similar devices that do record an entire life. Be afraid, be very afraid, and amazed, and curious, and productive. Here at Assembla we are looking at a similar trend that I call Workstreaming. The goal of Workstreaming is to share what you are working on, so that you can work more effectively with your team members. In Assembla, we provide email, RSS, and Web views of Alerts, our list of Workstream activity. As Lifestreaming and Workstreaming infrastructure improves, we should be able to provide a much more connected team experience.

Already, your phone will track where you are. Customers have asked me for this kind of tracking for their team members.

Typical workstream events include code commits, comments, wiki edits, ticket edits, and chat. We get all of those things inside Assembla spaces. However, we are taking Workstreaming serious, so we are also developing tools to suck in information from other systems.

What about sharing the other way? I have been asking myself if we can take Workstream data and feed it into the Lifestreaming infrastructure. Can we put your workspace activity on your Facebook page? Unfortunately, the permissioning does not match. A user owns his or her own Lifestream data and can decide what friends to share it with. When the user is working in a team project, the project owner or funder controls this information, and may not want to share it with the same friends.

We can share events from public spaces in the Lifestreaming infrastructur, and we will do that. However, 90% of our projects are private. So, we will need to work on permissioned ways to share that.

Copy and share preconfigured workspaces, save years of work

Andy Singleton — Mon, 17 Mar 2008 07:23:00 GMT

Assembla preconfigured spaces give you a fully configured workspace, with related code, in one click. For example, if you drop into the Just Chat preconfigured space and copy it, and you get a chat room. Too lightweight? Preconfigured paces can also contain complete code repositories, with wiki documentation that explains how a developer can get started, and the initial milestones. Any user can copy, improve, customize, and share a space.

The actual feature is simple. In the footer of every space page is a link that says "Copy this space". You can click on that link, and make a copy of the space. The following picture shows you where to find the link.

The copy operation pulls in tools (the extra feature tabs), wiki pages, milestones, styles, and the complete subversion repository. It does not copy content that you will not want to reuse - flow messages, tickets, tasks, or chat messages.

Why is this important?

Preconfigured spaces will save hours of work on a typical development or customization project, because they can be set up with best practices, and can include extras like deployment scripts. Just in the current Assembla user base alone, that will save staffing-years of effort.

Assembla will build a list of featured spaces. We're leading off with Ruby on Rails to demonstrate elements that we think are important: Build documentation for the team, source code with build scripts and svn configurations that help code move smoothly from developers to the staging and production servers.

Assembla will also be working with other open source frameworks to produce a bigger library of preconfigured spaces.

If you run a lot of projects, you can set up your own starter space and copy it every time you launch a new project.

Users with frameworks to share can post their own preconfigured spaces. To share, just enter "preconfigured" as a tag under the Admin tab. I don't know all of the ways that people will use it, but I suspect we will learn something as we make Assembla more configurable.

Here's an idea: If you are setting up an application process or contest, you can provide the applicants with a preconfigured space that contains their instructions and template documents, and ask them to attach the completed space to your portfolio.

Coming attractions

The instructions for building your own server are can be dramatically simplified. It could be one button. We plan on adding a "Rails server" tool that gives you a virtual server, on demand. This will link to a virtual Rails server provider like Morph or the magical Heroku. With this tool instructions will be "Push the deploy button". You push the button, and you click on the provided URL to see your app running on the full-bore EC2 cluster. We will have moved the team, code, and servers all the way into the on-demand cloud. The rapture will arrive as we effortlessly float into our deployments.

I am particularly interested in the development challenge posed by applications like Drupal and SugarCRM. These popular applications are often customized. However, they aren't designed for a professional, version-controlled development process where the developers build and test on a development system, and then deploy their tested changes to the production system. These applications want you to configure to the production system manually - not a reliable or acceptable process for a big site. It's a big problem that we can solve by providing preconfigured spaces with documentation and build scripts from developers that have figured out the best practices for this type of customization. I'm going to create public workspaces for each of these frameworks and solicit help from experts to complete the configuration.

If this goes well, we'll be able to build a foundry for each of these frameworks and applications. It will really smooth out the application life cycle. There will be a documented process that makes any customization maintainable, an people that own those customizations can always return to the foundry to get the code, tools, and top talent to do serious development work or maintenance.

The tools on Assembla.com right now are designed to be used without configuration - instant on. With the preconfigured spaces, we can start introducing tools with more complex configurations. We'd like to add workflow configuration to the ticket tool, and make a generic workflow tool (user-defined fields and states) that would handle a variety of tasks from use cases to customer support.

It used to be complicated to set up a project correctly, but it isn't any more. There's no excuse not to do it right.

So take my space ... please.