Assembla Blog

We are moving to Blog.Assembla.Com

andy@assembla.com — Thu, 21 Jun 2007 11:38:00 +0000

We are moving most of our content to Blog.Assembla.Com. Please subscribe on that site if you are interested in hyper-agile development, Assembla.com services, software & internet startups, and team building.

I will continue to update this blog with my personal messages.

US visas run out. What's the solution?

andy@assembla.com — Sun, 08 Apr 2007 09:52:00 +0000

We ran out of H-1B visas on the first day. US Immigration services received 150,000 applications for 65,000 H-1B visas, which are the visas most commonly used by programmers seeking to work inthe United States – as summarized by this Cnet story. Last year, it took two months to reach the same limit. What does this mean?

America still is the land of opportunity. Our technology business has recovered, and we are ready to work. We need to bring in talented people to build and create our entrepreneurial businesses.
Our government has converted this opportunity into a problem – a problem for employers, and a problem for offshore talent.
It has become even more important to figure out how to effectively manage distributed teams, so that we can work our way around bureaucratic obstacles.

There is another, important implication that I think has been overlooked by almost every commentator on the immigration issue. Employers are increasingly eager to bring skilled workers to the US, instead of leaving them in “low cost” countries, because the cost differential has narrowed. It doesn’t cost much extra to move someone to the US. If US salaries were much higher, there would be a bigger incentive to leave workers at home.

In the last year, salaries in places like India and Russia have risen rapidly, the dollar has declined, and US salaries have risen only moderately. So, the demand for H-1B visas indicates two favorable trends for US skilled workers. First, there is a big demand for local skilled labor here in the land of free enterprise. Second, the price war that fueled outsourcing has mostly run its course, and the next field of competition is about quality and the freedom to do a good job.

Although the advocates of raising the H-1B cap deny that H-1B visa holders push down wages for skilled Americans, I think it is probably true that wages get pushed down somewhat. A pure economic analysis would show that wages are held down, while the number of jobs is increased. I am willing to admit that I am not sure that this is a bad thing. I like the idea that jobs go to the best candidate. And, I work for a number of startups that are strugging to attract local technical talent so they can move forward.

So, we are working to fill this demand by building our local recruiting skills, and by constantly improving our ability to manage globally distributed teams.

How to select good trial tasks

andy@assembla.com — Sat, 27 Jan 2007 11:53:00 +0000

We use trial projects to help find the best developers to work with. We hire candidates to do paid trial tasks from our live projects. In working with the candidates, we understand how good they are and how well the they work in our process. We try to sign the good ones for longer term contracts. Itâ€™s a lot of work, but it is well worth the effort.

Sometimes, clients want to do this themselves. Or, they want us to perform in a trial, which is a hassle for us, but a good idea for them. That brings us to the subject of how to select trial tasks. To make the process work, we need good trial tasks.

I find that a managerâ€™s first instinct is to create a â€œtestâ€? task. Itâ€™s a small task that can be assigned to lots of candidates. That way, they save time by doing one specification, and they get the advantage of being able to compare results from multiple candidates. Or, they select a task that they have already specified and completed. That way, they save even more time because they donâ€™t have to do a new specification, and they can compare the candidate result with the previous result.

I donâ€™t use either of these approaches (a test task, or an already completed task), because they make the task meaningless. This causes two problems.

Good developers (including us) are busy, and work very hard, and donâ€™t have time to do meaningless work.
These trials fail. As a busy manager, you will never bring yourself to pay enough attention to a meaningless task to get a good result.

So, I only assign trial tasks and features that I intend to deploy, or that are R&D / prototyping for something that I intend to deploy. I only assign meaningful tasks. I think to do otherwise shows disrespect to the hard-working candidates I hope to work with.

For trials, I take a real system that I am working on, and ask for a meaningful improvement. Essentially, I assign tickets out of our live projects.

I hear three objections to this approach

â€œI need the deliverable. I canâ€™t risk it with a new guy.â€? If that is true, then hire two guys to do it.

â€œItâ€™s too much work to specifyâ€?. Thatâ€™s true if you are working with mediocre developers. However, if you are working with people who require precise specifications, and they just do coding, they arenâ€™t saving you much time. They would save you a LOT more time if they could take the general idea and a do something with it. So, it makes sense to test for that.

â€œMy systems are too complex for a quick trial.â€? Thatâ€™s true if you are working with mediocre developers. If you are working with good developers, you should be able to throw them into a complex system and get some forward motion pretty quickly. From a qualification point of view, complexity can help you. If the build process is such that you canâ€™t get new people set up easily, then you will benefit from improving the build process. That in itself can be a trial task.

Build an online game in 7 days?

andy@assembla.com — Sat, 27 Jan 2007 11:34:29 +0000

This article on Gamasutra provides a variety of “juicy” hints and examples from “4 Grad Students Who Made Over 50 Games in 1 Semester.”|

My last article on Hyper-agile product development focused on managing a complex project for minimum time to market – a sort of top-down approach for managers and teams. This article is a great follow-on for the individuals involved, a bottom-up approach to prototyping and testing individual features.

Lessons for Hyper-Agile product development

andy@assembla.com — Sun, 07 Jan 2007 21:15:00 +0000

Recently we were called upon to build and launch a new Web product with a hard deadline in a seasonal business. By the time we started our work, only three months remained until the planned launch date. It was a big system. Our mission was to build a new and greatly enhanced version of a product which had taken 15 months to build in its last iteration. So, we had a benchmark.

In this case, we ran more than four times faster than a similar project implemented last year with older tools and development methods. We also came in on-time and under budget, and we ended up implementing features faster than we could figure out how to use them.

How did this happen? Want to try this at home? I will share our lessons below. Good luck.

Donâ€™t do things that take time to arrange
Donâ€™t get dragged down by old code
Establish the data schema
Pile on with new team members
Use a ticket list / work queue
Build something now, even though we know we will have to rebuild
Donâ€™t split the codebase into components
Daily releases instead of stabilization periods
Make a usage dashboard
Web services are your friend
Hire users as product managers
Donâ€™t create obstacles: Users provide the data
Documentation on a wiki
Find the one thing people will use

Here is the expanded version, for people who actually do this for a living.

Donâ€™t do things that take time to arrange

We get big time savings by not moving people around. Travel takes time to arrange, and it takes time to do. People should be working, not moving, and they should start now. I donâ€™t do interviews. I found that even arranging a phone interview takes five to seven days â€“ a big chunk of a 70 day project. Instead, I let people start work and I evaluate their work later. I also donâ€™t set up conference calls for the product team. In my observation, time spent on the phone is a good indicator of communication problems, and is best avoided by improved management and communication.

Donâ€™t get dragged down by old code.

I believe in doing a lot of research and trying to adapt existing open source code, as an alternative to diving into new development. We spent a week of our precious schedule taking a in-depth look at open source alternatives. We considered a system with a friendly academic license and $4M worth of development behind it. What we found was big, complicated enterprise software with lots of heavy baggage. We talked to people who were adding to Sakai, and found that they were typically taking 8 months to do things that I thought should take a month. We discarded the existing product for the same reason. We moved on to a more agile architecture and never looked back. I had to change my thinking because, in the new world, it often is faster to build from scratch.

Rails is simpler than java for this type of application, and the build was much faster as a result.

Establish the data schema

It is easy to add to a data schema, but difficult to change it. I sometimes visit old clients and find that the people, products, and code that I knew are long forgotten, but the data schema remains. Data schema is the one piece of up-front design that we do before diving into the build.

Pile on with new team members

It is possible to bring in a lot of new team members and let people pick their own tasks. Using this technique, we were able to triple our output in three weeks. This approach is the exact opposite of the “Mythical Man Month” recommendation, which holds that adding new team members imposes a cost of learning time and management time which will delay a project that is on a short time schedule. In my experience, adding team members DOES delay a project, if you need to guide them and manage them. The pile-on method works if the new developers are good and can find their own way. We are helped by our â€œinspired by open sourceâ€? methods, which were developed to serve large teams with loose central management, and the fact that some of the new developers are very good. We can weed out the rest a few weeks later.

An obvious related lesson is to work with good people. I am not even going to put it in the list of lessons from this project because it is far from a new lesson. A good developer seems to be about 5 times as productive as an average developer. In this project, there were several cases where a team member spent 2 weeks working on something, did not finish it, and then found it replaced by something our best guy finished in 2 days. Given the potential gains, most project managers donâ€™t invest enough in recruiting and retention.

Use a ticket list / work queue

We put all of our tasks, bugs, and new requests into a list of “tickets”, often called a work queue. We use Trac. In fact, we use Assembla.com. We sort the tickets by priority and milestone, so the tasks from the next milestone are on top of the list (queue). Itâ€™s easy to figure out what to do. Just look at the list of tickets and pick something near the top. You can try to adopt a more rigorous agile methodology, but you will find that it is hard to improve on this simple and effective technique.

Build something now, even though we know we will have to rebuild

We started building copies of the old product, and copies of features that we saw in other products, before we even had a coherent visual design or plan for the new product. Then we ripped out a lot of the guts and rebuilt it. This was still faster than waiting around for a coherent design and product plan. Why? In this new environment, development is faster than product management. From a product management point of view, it is faster to ask for changes than to figure out what the product should do from scratch. It takes forever to build something that is unknown, but if you know what you want, builds are fast. So, the two steps (copy and redesign/refactor), with clear instructions for each, are faster than one build from a blank sheet.

Donâ€™t split the codebase into components

In this application we needed several types of servers that were different â€“a permissioned application, a public portal, and a central user registration server. We lumped them together in one repository and one application with configurable â€œrolesâ€? that turn features on or off. This made the code a bit more complicated. However, it made other aspects of managing the app â€“ setting up developers, testing, staging, deployment â€“ a lot simpler.

Daily releases instead of stabilization periods

In a normal Web 2.0 style release, you just run beta releases of increasing quality, until you are ready to do a bigger announcement. In this case, I didnâ€™t think we had time for such gradual stabilization. I initially recommended that we do a code freeze with a week of testing and stabilization. The resulting product might not be perfect, but at least it wouldnâ€™t crash. We started with a daily release process and no code freeze, and it worked well enough that we didnâ€™t need to a code freeze and stabilization period. Itâ€™s not bug free, but we fix the bugs as fast as people notice them. I now have abundant evidence, from several projects, one of them a big enterprise ASP, that users will tolerate a product which comes directly from developers, every day, with minimal testing, if the time to release a bug fix is less than 24 hours.

Make a usage dashboard

Program a custom dashboard that shows registration and usage statistics. Everyone on the team will use it every day as soon as the beta period starts.

Web services are your friend

Arranging integration with external systems can absorb a lot of calendar time. We were able to use SOAP services (easily offered or called in Rails) to make it go faster than I expected.

Hire users as product managers

Product management â€“ figuring out what the product should do â€“ became the bottleneck early on and remains the bottleneck. Using the above techniques, the developers pull requests off the ticket stack and implement them as fast as we can make the requests. Our strategy to deal with this is to hire users as part-time product managers, and let them each work with a mockup team to redesign the visual parts of the app. With the distributed team system, itâ€™s easy to integrate part-timers like this.

Donâ€™t create obstacles: Users provide the data

We took out the centrally controlled categories and allowing users to just type their own tags for the content that they entered and shared. I think we would still be waiting if we had to build our own categories. We got a surprise when we released with a comprehensive list of US data, and we had immediate requests from dozens of countries. I now think that users should be able to post additions to any part of the database if they need to. Why block them? Sometimes the additions can be released directly, and sometimes they may need to be approved by an editor.

Documentation on a wiki

If your application changes every day, you need to put the documentation on a wiki. If you set up the documentation wiki early in the development process, you can start linking to it from inside the app, just like embedded help pages.

Find the one thing people will use

If you can find the one feature that people will use and adopt, it makes the whole system simpler. So, release early and often and watch your dashboard. Find that thing.

What "Enterprise Web 2.0" Means to Me

andy@assembla.com — Thu, 14 Dec 2006 16:10:00 +0000

Iâ€™m seeing a lot of the phrase â€œEnterprise Web 2.0â€?. Weâ€™re doing some work with Nexaweb, a company that positions itself as delivering Enterprise Web 2.0. I recently had a great discussion at the Enterprise Web 2.0 meetup here in Boston. Google turns up a bunch of hits, including a blog and a conference. What does it mean? Is it important, or just spin?

I fought the â€œWeb 2.0â€? label for a long time. It seemed vague, and I suspected that as soon as I started using the phrase, I would find it replaced by â€œWeb 3.0â€? and thrown into the â€œExpiredâ€? column in Wired magazine. But as I started learning more about how to launch Web 2.0 products, I found that the term started meaning something to me. It represented a distinct package of techniques that could solve some big problems with enterprise systems. So, for us, itâ€™s not just spin. Itâ€™s the useful product of intense evolutionary pressure and innovation.

Web 2.0 players like Assembla, working on startup projects under severe time and cost pressure, in a global marketplace, have developed processes that will deliver substantial benefits when they are applied to enterprise problems.

Some people define Web 2.0 with product attributes like ajax interfaces. Thatâ€™s one part of it. Others define it around the way the product is built and used â€“ with user-generated content and mashups. Those are other parts. In reality Web 2.0 is a product strategy that uses all of the parts. Web 2.0 is a product strategy that is designed to maximize adoption.

The fundamental building blocks of a Web 2.0 product add up to this whole.

Itâ€™s delivered over the Web. The Web is global, so anyone can use the product. Itâ€™s delivered to standard browsers that everyone has.

Users can get started quickly. Usually, there is a free trial. If registration is required, itâ€™s fast. Even the email confirmation step is being squeezed out so that users can get in faster. I would describe the ideal Web 2.0 adoption sequence as free, fast, and fun.

The UI is fast and fun overall. We donâ€™t want people getting frustrated and moving on before they have fully adopted the product. Thatâ€™s why the ajax and other RIA techniques are important.

Product launch and improvement cycles are very fast. That means that the product is better. You get what you want fast.

The software is in permanent beta mode. If users want fast product cycles, they have to pay for it by doing testing. This means you have to find a group of users who want the newer and less reliable stuff.

Users share data and documentation. They know what they want, and if they can share it directly, it dramatically shortens the product cycle. Over at MySQL, users add comments directly to the online manual. Often the comments are better than the manual entries. And if you need to sort your data, forget edited topics. Users need to put in their own tags. An editor canâ€™t keep up with them. Itâ€™s a small step from that to Wikipedia. What about teachers sharing lesson plans? Itâ€™s faster than a 3-year textbook publishing cycle. Programmers sharing code? It seems so obvious now.

Why is Web 2.0 important for “The Enterprise”?

The biggest risk with enterprise systems is user adoption. Most planned enterprise systems are never adopted. When they are adopted, they require expensive training and infrastructure. Web 2.0 is a silver bullet aimed directly at the largest risk of enterprise software deployment â€“ the failure to adopt in a timely way.
Web 2.0 product cycles and deployment costs are cheaper than typical enterprise software costs.
As an added benefit, Web 2.0 systems can capture value from SOA investments by putting apps on top of them.

Marketing In A Web 2.0 World: Why The Best Products Sometimes Win

andy@assembla.com — Wed, 13 Dec 2006 22:03:00 +0000

Read the full article at OnStartups

Here is a summary:

For 100 years, it has been a truism that “the best product doesn’t win. The product with the best marketing wins.” At the risk of being thrown out of capitalist society, I claim that on the Web, this is no longer true. The best product often does win, with virtually no marketing, if it is easy to adopt.

In this new product cycle, figuring out how to get users to adopt is the hard and expensive thing. Marketing serves the adoption work by bringing in the right number of prospects for us to experiment with.

To meet an impossible deadline, cut your time in half

andy@assembla.com — Sun, 10 Dec 2006 16:53:00 +0000

A major consumer goods company told me last Tuesday that they wanted to put in a gift purchasing system. This involved a couple of roles (giver and receiver), a credit card gateway, Web services for fulfillment, email reminders, etc – a serious application. I would normally want about 6 weeks to build and test such a system. They told me that wanted it for the following Monday – 6 days away – and they were willing to pay a premium for that. I took the job, and I told everyone that it wouldn’t make sense to do it in six days. Instead, we needed to do it in three days.

When I plan a software development job that has a deadline, I use a 50% scheduling rule. We need to have a relatively complete, working version of the software available for testing when we are halfway to a full release. If I want to do a product release 3 months from now, I plan to have a testable version of the product in 1.5 months. The halfway release can be rough and even ugly, but it needs to do most of the things the complete release will do. This rule ensures that the incremental release process can work its magic. You have half of the total time available for finding and fixing problems and making improvements.

What if someone gives you a seemingly impossible schedule? What if you don’t have enough time to get even the first version out? In this case, I still use the 50% rule. You force yourself to deliver something in half the time.

This just recognizes reality. In reality, no product is done in its first testable release. If you think you can do a release without spending half your time on incremental improvement, you are probably wrong. If instead you make a simpler product and give yourself a few cycles to make it work properly, you will look pretty good. As an added bonus, you motivate the business guys that you are working with to deliver all the stuff you need.

We posted our midpoint release early on Friday. It didn’t look great, but it had all of the transactions and it worked. I got my gift. Thursday was an all-nighter, but now it’s Sunday, and I have time to write this blog post.

First release of Rumrz - What's Hot in Finance

andy@assembla.com — Mon, 13 Nov 2006 10:02:00 +0000

Please check out our new community news site, Rumrz – What’s Hot in Finance.

Site: http://rumrz.com

About: http://www.rumrz.com/content/about

Community sites like Rurmz always start from a very small base of contributors. I expect that traffic on the site will be slow for the next few months, but that it will grow at an exponential rate and become significant within six months. Your early contribution will set the tone and establish your expertise. Thanks.

First, I was laughed out of the room. This spring, I talked to some of my friends in the securities research business to find out if they were interested in using our Assembla workspaces to collaborate with clients. Everybody I talked to totally panned the idea of collaboration on securities research. Who would want to collaborate? They just want hot tips thrown over the wall. However, almost everyone we talked to was also interested in the idea of the “wisdom of crowds”. They were looking for some way to identify experts with unique insights, or to find out what people are talking about, or what direction opinion was headed. There was a general suspicion that social software techniques could yield useful information.

So, I looked for an opening – the simplest and most easily adopted type of social software. I looked at community news sites like Reddit and Digg. These sites are fun to read, and have a fascinating ability to show you what’s hot, through the action of thousands of readers and contributors.

To turn this into a professional tool, I added a twist that combines Web 2.0 accessibility with the old idea of controlled circulation. The site is open to the public, but users who register as Accredited or Professional users get extra privileges – and extra weight when they submit or vote. A person browsing can look for links rated by the public, or only by professionals.

Once I decided to move on this, our amazing development team brought us to a a beta release in four weeks. 15 years ago, I was working building financial information services to run on proprietary networks. In those days, Bloomberg was a startup that cruised past Telerate and Reuters with much faster product cycles. I think our fast, enterprise Web 2.0 release process will give us similar opportunities in the Internet age.

Trac / SVN server upgrade today

andy@assembla.com — Sun, 12 Nov 2006 22:20:00 +0000

We finished a Trac and SVN server upgrade today. This will increase our reliability. However, some people were disconnected from their development space because we changed the IP address of “tools.assembla.com”, and this took time to propagate from the DNS. I hope everyone is working now. Thank you for your patience.

We had to upgrade to a bigger server with much more disk space because we now are hosting 844 workspaces with Trac and Subversion.

If you continue have trouble reaching the SVN server because you have the old IP address, please add the correct address your “hosts” file. The hosts file is usually in /etc/hosts or /windows/system32/drivers/etc/hosts on windows.

Here is the correct hosts line:

66.180.170.8 tools.assembla.com