Assembla Blog

Posted by andy@assembla.com Sat, 27 Jan 2007 11:53:00 GMT

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.

Posted by andy@assembla.com Sat, 27 Jan 2007 11:34:29 GMT

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.

Posted by andy@assembla.com Sun, 07 Jan 2007 21:15:00 GMT

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

Posted by andy@assembla.com Sun, 10 Dec 2006 16:53:00 GMT

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.

Posted by andy@assembla.com Thu, 28 Sep 2006 21:43:00 GMT

A startup will often live or die based on its first product release. Did it get released? Did people find it useful? Good roadmapping dramatically improves your chance of getting to “Yes!� on these critical questions.

Read about my roadmapping technique over at th On Startups blog.

I think it’s my most immediately useful post so far. It’s a technique that has helped me work with individual entrepreneurs, my own products, venture funded companies, and giant corporations. I gave it to Dharmesh at On Startups because he has a much bigger readership that could benefit from this technique.

So, check it out.

Posted by andy@assembla.com Sat, 23 Sep 2006 18:29:00 GMT

Should team task assignments be controlled by a project manager, or should each team member create and accept tasks? You can get a big increase in peformance if you know when to use each of these methods of organization.

Posted by andy@assembla.com Sat, 20 May 2006 22:53:00 GMT

Jon Udell included me in his Friday podcast series this week with a conversation with Andy Singleton about building global teams . Jon has been putting up with me since 1993, when he edited some freelance articles that I wrote for Byte magazine. In 2003 he coined the term “dynamic development” to describe the work I was doing. He has recently been commenting on user innovation and the power of human networks to do work beyond open source sofware. In this conversation, he turns me on to Yochai Benkler’s The Wealth of Networks, and he cautions against a “walled garden”. Maybe we’ll be able to work together on a universally portable user profile.

Posted by andy@assembla.com Sat, 20 May 2006 21:16:00 GMT

I have been reading a book called The Greek Commonwealth – Politics and Economics in Fifth Century Athens. Originally published in 1911, it’s not out of date. According to the author, “it is natural for human beings to enjoy using their own best faculties. Men never felt that enjoyment so keenly, or put so much high effort into its attainment, as in the workshops of ancient Greece. If you seek a proof, go look through the shelves of our Greek museums. There is hardly an object that they made, however rude, but bears on it, sometimes faintly, sometimes with speaking clearness, the touch of the spirit of Art.� How can we bring that spirit to our work, every day?

Posted by andy@assembla.com Sun, 30 Apr 2006 10:21:00 GMT

Over the past few months, we have done a lot of work on Assembla.com, our online service for building and running distributed software teams, and Breakout, the underlying platform for professional networks. Now, we are ready to share. If you have suggestions for user groups that can benefit from this resource, or bloggers that might be interested in it, let me know at andy@assembla.com Read on for the story->

Posted by andy@assembla.com Sun, 30 Apr 2006 09:41:00 GMT

To me, it is self-evident that you should test any co-worker, in the job that they will be working at, before you make a permanent offer. I was surprised to see how much criticism Dharmesh Shah picked up for recommending a two month probationary period for new hires, during which the employer or employee could withdraw without negative consequences. Much of the criticism was along the lines of “You should do better interviews”. I suspect those critics have not hired many people themselves. I have been doing it for 20 years, and my hit rate for picking really good workers (who don’t bail out) from even the most extensive interview process is still only about 50%. By persisting in finding ways to run trials, I can move that to 90%. This makes an enormous difference in startup risk and ramp time.