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.

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.

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. 

The March 15 release included dozens of fixes and design enhancements. If you are Assembla user, here are few things that might help you:

A lot of help pages are filled in.  We are making a lot of progress on both help pages and a user manual. Thank you for your patience. 

We improved the format for the Trac/SVN tool page.  We're making it easier to configure, and easier to bring a new user into a version-controlled proejct.  The big new feature here is a button for  importing Trac tickets into Assembla Tickets.  So, you can import the Trac tickets that are already hosted on Assembla, or you can upload your Trac, and then import.  Soon, we will offer an export to Trac tickets, so you will have a migration path both ways.

If you use Assembla tickets, you can update the tickets with Subversion commit comments.  Use "closes #99" to close ticket 99 (also closed, fixed, and fixes), or "Re #99" or "to append a comment (also references and see), or  "test #99" to move it to test status.  You will also find a much-requested "Group by" option in the reports. And, as mentioned in my last post, we added a Notification list option, so that you can select the people who will be alerted by email about a ticket.

The big new alpha/beta test feature in tickets is the  "drag and drop sorter".  It gives you a grid view of the tickets where you can drag them between milestones, or priorities, or users.  I am looking forward to using it for roadmapping.  Try this new link, above the ticket list near "batch update", and tell us what you think.

We made some improvements in the layout of Milestones, and in integration with the Tickets tool.  Milestones is a bit of an awkward feature  because it spans the gap between Basecamp-style milestones and to-do's, a very simple feature for non-technical users, and the release milestones used by developers in the Tickets tool.  It's worth doing because both constituencies work on the same milestones.  I think we are making it flow more smoothly.

The chat implementation has been tightened up.  It will take a big step forward next week when we add HTTP polling to support users that are behind proxy firewalls.  How many of you think we should add audio and video chat?

I won't mention the two BIG features that we have been working on now.  We will cover them in posts over the next few days.

The popular blog post "Build a dotcom in 24 hours" took readers through the steps of building and deploying a simple Web application.  I know it was popular because when it made the Digg front page, about 1000 people clicked through to Assembla and signed up, even though Assembla was a minor link way down in the article.   So, there is a real hunger for this type of tutorial.  I work with people that need to solve a different and more complicated problem - how to build a real product, company, team, and user ecostem.  I'm going to give this bigger problem the same treatment, going through all of the steps in 24 working days, and documenting what we did and what we learned about each step.  As an added bonus, we're going to build an interesting product that I have been thinking about for some time.

Thursday, February 28, was our first day. In the  time-bound spirit of the exercise, I executed step one of the project in the airport waiting for my morning flight to Miami.  Step 1 is "register a silly name that nobody else wanted", so I got online and registered "respondz.com".  The app listens to what you want, and responds.  The registrar site was slow and I barely made the plane.  Then, I wrote a slide presentation on the airplane, and presented it to a roomfull of Barcamp geeks I had never met, with the tagline "You will help.  We will start today."  We're not going to run the days consecutively (the original 24 hours wasn't consecutive either), because we all have intense day jobs, but we will report our results within 24 working days.

You can see the presentation here.

Three people signed up out of the audience.  Ken Scott said he could help with system administration, and he set up a Web server on the spot. Bob Baldwin volunteered to do some development. And, I can draw on my team for both development and management talent.

We're still lacking an expert in online advertising and affiliate marketing.  We need to fill the role soon, so contact me if you can help.

Here's the Idea:  We show a form that asks the user some questions about what he or she wants, and then we present information and offers that match.

Duh!  We ask the user what he/she wants, and then we give it to him or her.  That's the most simplistic advertising idea, and possibly the most stupid, since asking people to pay for search placement.  It's going in the opposite direction from complex techniques like behavioral targeting.

If we drill down, we can we can see that the actual implementation of this idea supports more subtlety and sophistication.  For example, we can offer the user a chance to answer a few more questions, and get better targeted content and offers.  We can optionally save user attributes (by default usage is completely anonymous) this so the user doesn't have to answer the same questions in the next search.  We can provide freelance editors with ways to maintain questions and matching content, and get a percentage of the proceeds in their subject area.  We can provide sponors with ways to "bid" for a match.  We can get smarter and smarter about matching.

I've posted a picture of what this might look like below, as done on the plane between peanuts.  This example is from the subject area of health and wellness, and it uses an idea that I have seen in the wild working for diet sites - a banner ad that contains inside it a little 2 question form, a micro-assessment.

You could apply this to a wide range of subject areas, like travel, or books.  I originally proposed this idea as a way to match travel offers with itineraries.  Then, a few years ago, a client wanted to build a health and wellness site, and he had licensed a "Self assessment" from a medical school that included about 100 questions on every aspect of your health and habits.  My reaction was that nobody would sit through 100 questions on the Web, but we might be able to suck them in if we only asked for 2 at a time.  I was also in favor of community content, with sponsors being engaged to match their own offers.  Nobody went forward with the suggestion, so it's come down to us.

This idea has advantages that make it appropriate for our 24 day startup launch.

• It's simple.  We can get it up and try it out.
• It's easy to explain.  That saves a huge amount of time out of the 24 working days, during which we will explain what we are doing to dozens or possibly hundreds of people.
• It uses existing revenue streams from online advertising and affiliate commissions.  We aren't going to wander in the wilderness for 40 days looking for a way to "monetize".
• It's specializeable. You can pick a narrow subject area.  That's important because when we start, we are a tiny company, and we need to go after a market that fits our resources.  This is important for most startups.
• It's optimizable.  We can always make this product a bit smarter and a bit better.  That's how we sneak up on the competition.

 
There is one big disadvantage.  There isn't any obvious way to defend this service from competition.  If it turns out to be a good idea, and Google or Microsoft or two guys reading this blog want to take a swing at it, they can.  We just have to specialize, optimize, and get good at our specialty.

 Another disadvantage is that we need some innovation in the techniques for matching content to answers.  The ideal business applies a known technique to an underserved market.  Innovation slows you down.  That's why VC's don't want to get involved until your innovating days are over.  But, all in all, this is a pretty limited area to innovate in, we can start stupid and optimize, and I have some ideas.

The Deliverables

We have a bunch of things to deliver in the next 23 working days:

Assemble the team - In addition to an operating team, including a marketing, development, and a CEO (could do double duty at this early stage), we will need a board of directors that will figure out how to go forward with this fabulous product at the end of our 24 day time and money budget.

Create a company structure - To build a team, we need to be able to give out equity in a real company.  And, we need to take care of the messy details like budgeting and accounting.

Targeting - We need to identify a subject with a lot of user and sponsor interest, and sign up at least one editor.

Build the product -  We're going to showcase the Assembla tools and process.  We'll run daily builds starting from day 2, and we'll show our work in a public space.

Blog it - document what we did and what we learned

We start now.  You will help.  Contact me if you want to participate in some way.

In the Tickets, tool, we have added the ability to ONLY send alerts about ticket changes to the assigned user, the reporter, and possibly an exclusive list of recipients that you choose.  Since this is the single most requested feature for Assembla tickets, and people have been complaining about it, I'll interrupt this blog to provide a quick introduction.

You can go to the Tickets settings panel and, under "notification strategy", you can select "Email ticket changes only to the assigned user and the notification list." The reporter is automatically added to the notification list when the ticket is created, so the default behavior is to notify the reporter and the assignee. When this option is selected, you will have a new "Notification list" panel on the ticket.

Remember to set your email alerts to get only the volume you want.  When you get an email alert, you will see a link at the bottom that says "Click here to change or remove your alert settings", and links to the Alert settings panel.

Around Boston, I often work with with teams that are bogged down in slush and complicated code.  A new day dawns!  Last week, I traveled to Miami to attend an event called Future of Web apps, which also included a Barcamp, and got a completely differerent view of fast and vigorous Web app development.  Engineers and founders from Wordpress, Twitter, Pownce, and Flickr talked about how to build and deploy scalable Web apps.  Many of the other participants were Web developers turning out weekly releases of their own early-stage products, while also churning out a stream of apps and Web sites for clients.  They represent a tremendous talent base.

Cal Henderson of Flickr hit on most of the themes that I hit on, but with better graphics, and more kittens.  His recipe for aggressively adding features to a big, always on-app like Flickr includes: Use good source management and ticketing; don't branch - release from trunk; use an online commit log where users can post big red messages if their code is not ready to release (I'm going to find a way to do this with Assembla), and use bot and build scripts to create a ONE BUTTON deploy process.  In his slideshow, he showed the button.

The FOWA future vision is about a sort of personal mash-up space, where a user can link together best-of-breed Web apps into a complete worldview and personal dossier.  Kevin Marks of Google noted that in this world a user is represented by a URL, not an email address, and he showed how OpenSocial and the Social Graph API help you find a complete picture of that user.  That saves the user time.  And, it doesn't cost much developer time.  Small operations like Pownce (3 developers) and Remember the Milk (2 developers) showed how they deployed a long list of API's to integrate with the world around them.  Want super-secure authentication?  Use OpenID with a provider that requires visual tokens.  Need to get alerts to your mobile phone?  Feed them into Twitter.  Tired of filling out profile forms?  Use the Social Graph.  And so on and so on.

My engineering brain was filled with strange new ideas about how to improve the user experience.  Kathy Sierra was terrific on the subject of apps that help users feel powerful and capable and passionately enthusiastic.  I'm so far behind her on this subject (I did understand the WTF key) that I won't attempt to reproduce any of her advice.  You can get it from the source.  The colors of Miami Beach - the turquoise sea and the sunny art-deco pink and orange landscape - also gave me a lot of design ideas.

 A Barcamp session titled "Build a Web app in 48 hours" featured the founders of Tasty Planner, a recipe site.  They originally built the app in 48 hours as part of a "Rails Rumble" contest.  It's a beautiful app that has since attracted a big audience.  They ran as a distributed team and set up their own staging server and svn, and used Campfire chat room to stay in touch.  It would have been a lot easier with the Assembla pre-configured Rails space, coming this week, which bundles SVN, alerts, and chat, and will include the Rails code and deployment scripts.

I took the opportunity at Barcamp to launch new project with a friendly audience - "Build a dotcom in 24 days".  We've seen the video showing how to build rails app in 15 minutes, and we saw a big response at Assembla to the blog post from Dominiek ter Heidi titled "Build a .com in 24 hours".  These are essentially programming tutorials that explain how to build and deploy software, and they are illuminating.  The people that I work with get called on to build not only software, but also a complete product and a complete company and user ecosystem.  I'm going to take it a step further and go through the steps of building a company, team, non-trivial product, and user ecosystem.  It's a stunt, but it's also about a cool product.  Stay tuned.

I have posted articles that suggests ways to do roadmapping, in which you prioritize the things that you want to do into a series of releases, iterations, or milestones.  We call them Milestones in our system.  This is a nice tool for showing people what you want to do.  But, you can simplify the job.  My own technical lead reminded me of that when he recently reorganize our Assembla.com tickets.  You actually only need three milestones to get all of your work done.

The agile process depends on scheduling releases, iterations, or milestones.  The process is simple.  You select a set of tickets that describe tasks and features you want to work on for the next milestone - the stuff that is most important.  Then you finish as many of the tickets in that list as you can, and release.  Then you take the leftover tickets, select some additional work, and start working toward a new milestone.

Here are the milestones you need to set up:

1) The release you are working on

You need this release because it tells your team what to work on.

2) The next release

Scrum teams often use only two milestones - the current iteration, and the backlog (unplanned).  They don't bother to sort the backlog until they are ready to work on it.  So, this proves that you actually only need TWO milestones to do your work.

However, this causes a political problem.  There are always people who will argue that their requests need to be included in the current milestone.  They are afraid that if a request doesn't make the cut, and gets thrown into the big backlog list, they will never get it.  They apply pressure to hold or expand the release until those requests are finished.  The releases don't go out on time and the process becomes less agile.  You can relieve the pressure and get the release out by proving that the requests that don't make it are only moving to the next release.  Before you have any discussions about what goes into the current release, I recommend setting up a next release where you can move contested tickets.

3) Backlog or Unplanned

I had four conversations this week about the same damn problem, which is fixable.  Enterprise software buyers often request, and get, customized versions of the software they buy.  Building and supporting these customizations can exhaust even the best development team, and can slow down the vendor's product cycles to the point where the business is in danger.  If you aren't an enterprise software vendor, you can thank your lucky stars and move on.  Otherwise, read this article to find some solutions to this persistent problem.

If you sell enterprise software, you sell to big organizations that hopefully will pay you a lot of money.  In exchange for their business, they will ask for customizations, enhancements, and special features.  You will find that your biggest and most lucrative deals hinge on providing customization.

Sometimes, this can be a good thing.  The customer requests improvements that you need anyway, and is even willing to pay for them.  However, if aren't well organized, you will find that all of your energy goes into building and supporting customizations, and that your core product development effort stalls.  And, the delays only increases over time as you support more customizations.  My job is to figure out how to accelerate software development, so I consider those delays unacceptable. 

Figure 1 shows the simplest way that you can organize a customization.  You go to your core development team, and ask them to fork the code and build a custom application.  It's certainly the fastest way to get started.

The Fork and Go process causes two problems.  First of all, you are using your core development team, which is a limited resource.  It's not scalable.  And, supporting forks is SO PAINFUL and inefficient that most development organizations will go to extraordinary lengths to avoid this fate.

Typically, the team will move to the process shown in Figure 2 below. Instead of forking the code, they wrap everything into the core product, and the put in configuration switches to turn off things that the other customers might not want.  This gives you a smooth way to share the improvements that you really do want to include in the product.

Now you aren't officially supporting a fork, but you still have the problem that your core development team is doing the work, and that's not scalable.  And you have two new problems.

The short term problem is that you have just destroyed your agile release process, the process that works best if you release at a release on a timed schedule, rather than when features are ready.  Under this plan, you have promised specific features to a major customer in the next release, and you cannot release until they are ready.  The core product release will inevitably be delayed.

The long term problem is those configuration switches.  If you have N switches, you have 2^N ways to turn them off and on. Your product becomes exponentially harder to test for all configurations.

You may not even be able to specify the system.  I had a client that supported about 30 different configurations with about 100 switches.  Each switch triggered some sort of "if-then" behavior in the code.  This allowed them to accomodate a lot of different customers on one SaaS code base.  But when they wanted to move to a new implementation with a new programming language, it became clear that there was absolutely no way to fully specify the behavior of the system.  Instead of making a new system to spec, we had to write a translator to compile the old code into the new language, and then compare the behavior of the old and new system.  Obviously, it was impossible to test more than a tiny percentage of the possible combinations.

The solution is to move the customization to the customer side, as shown in figure 3. You provide an API, which has fixed and testable behavior, and the customer, or a new customization team, makes (and tests) the custom code.  This has huge advantages if you can do it.  You don't have to maintain forks, because the API is stable enough to support the custom apps in each new release.  And, you have created a scalable process.  You can  engage new teams to make the customizations.

But, there is a critical problem for new product development.  New products are new.  They don't have fixed API's or even fixed behavior.   You promise the customer that the API will be fixed and stable.  The very act of offering the API stifles future innovation.  The API should be introduced LATE in the product cycle, not early.

If you have any intention of innovating, I recommend the process diagrammed below in Figure 4.

This process is derived from the way that open source projects are organized. If you want something new in an open source project, you can ask the "maintainer" of the project to  include it in the core roadmap.  He can refuse on the grounds that there is a lot of other stuff to do, which makes it your problem, the customization team's problem.  That's what makes the process scalable.  However, you still have the option to build  your enhancements, and "contribute" them to the maintainer.  If they make sense, the maintainer will include them in the build and maintain them in future releases.  You get innovation without forking.  If the maintainer does not accept the enhancements, you end up with a fork and some future merging.  However, you still get the scalability and freedom of running your own team with it's own custom release cycle.

This is a no-lose situation for the core team, since they are protected from disruption by the maintainer.  It's exactly what we were hoping for as a way to accelerate core development. 

When you combine this with an API or some other extensible architecture, you get the best of both worlds.

This is a good way to integrate a distributed team, working on customizations and customization architecture, with an established core team.