This is why I’m so pleased to see my friends at Lumatic (the company formerly known as Omniar) taking advantage of this for their product and UX.

They built a static HTML version of the product that simulates many of the user interactions and the interface. At the end, they use a free survey from SurveyMonkey to collect feedback. Even better, they’re building a mobile app, and have still prototyped using HTML.

This is a great way of collecting thoughts from users, instead of only sitting down with users one-on-one (which they’re also doing). They can find out if there are missing features, or if people are interested in the features that are there.

I’ve seen other effective prototypes done using paper — if you’re going to be collecting information from users that might have privacy implications, you can test out resistance to it with a sheet of paper (or another free SurveyMonkey form). Another startup gave potential users a small notebook to see if they would write their thoughts during the day on a subject (which simulated a part of their upcoming product).

Figure out what’s most risky in your new venture, then find a way of cheaply testing it so you can reduce the risk. Feel free to discuss in the comments, or email me if you have questions — tim @ cloudspace.com

Sometimes you just have to do it live! Sometimes a fix is so crucial that you head directly to the production server, edit the code, save the file, and restart the server. It’s not an ideal situation but it happens. Most of the time, the fix is pretty small and you can just go to your local repository after things are fixed on the live server and remake the changes to your code base and commit them. When the fix is more complex, you may want to commit the code on your production server and create a patch to apply your changes to the code in the repository. If your repository is in git, here are some instructions on how to use ‘git format-patch‘ and ‘git am‘ to bring everything back in sync.

Patching can be useful for more than just hot fixes.  Sometimes you don’t need to work on a live server, you just want to and by “live” I mean on an actual server just like the production box instead of your local machine. This can be very useful for anything from starting a new project to working on v2 of an enormous live system. Rather than mess with a local copy of the code (and trying to get some advanced technology working on your mac) or trying to configure a virtual machine (or several) to let you interact with a duplicate environment of what your production server will be, you can just build the server, deploy to it once and edit in place. You don’t have to worry about differences between when your development and production environments when you are working on an exact copy of the production system. You can just make changes to the code and restart the application to see them. Of course you’ll want to commit your work regularly and make sure to get it into the repository. You can do this by creating patches with git as well.

Can you follow these instructions?

Go to your local repository, make sure you are on your master branch, ‘git pull’ to make sure you have all recent changes and view ‘git log’ to find the ID of your latest commit. Save this value for later. Hopefully all of these commits have already been deployed to production, let’s check. Go to the production server and go into your project’s current folder and view ‘git log’. If your production server has all of the same commits then you are good to go. It is okay if the production server has more commits because you’ve already committed the new code on the production server, as long as they are all after the commits that are in your local repository. If you have extra commits on the master branch of your local repository these instructions will not work exactly as printed, take some time to read up on git am and git format-patch though and you can figure it out. (Try keeping your work off the master branch and only merge your working branches back into the master when you are ready to deploy.)

Patching Instructions

Step 1) Commit Code on Production Box First, go ahead and commit the changes you made to the code on the deploy branch on the production server if you haven’t already. You can commit it all at once, or split it into multiple commits if that makes more sense for the changes you have made. For the sake of this demo we’ll say that you put everything into one commit with the commit message “my fix” which is a horrible commit message but works great for example purposes.

git commit -m "my fix"

Step 2) Create Patches On the production server go into your application’s current directory. Using the ID of the last commit you have in your local repository run the command to create the patches.

git format-patch LAST_LOCAL_COMMIT_ID
(*replacing the LAST_LOCAL_COMMIT_ID with the value saved before
 -- should look like 48aa02be08fd5f2ed641b50f5611b968ff2699a7)

This tells git to create a patch file for each commit that happened since the specified commit. With our one commit, this would create one file named ’0001-my-fix.patch’

Step 3) Get Patches Now download the patches to your local computer with your protocol of choice (scp, sftp, etc) and put them in the root directory of your local repository.

Step 4) Run Patches Go into your local repository and run the patches

git am -s 0001-my-fix.patch
(*replacing 0001-my-fix.patch with the correct file name)

Path files tend to be named starting with ordered numbers (0001, 0002, etc) so if you made multiple commits on the production server, you may need to run multiple patch files. You can run them each individually or you can run them all at once like so

git am -s 0*
(*assuming no other files in the directory start with a 0 [zero])

Step 5) Push Patched Commits to Remote Branch

Now the commits have been applied to your local repository and you need to push them to the remote.

git push origin master

Ta-da! Now the repository is back in sync with the code actually running on the server.

We have been using versions of Agile Development at Cloudspace for most of our 13 year history — even before it had a formal name. However, we didn’t implement pair programming, or extreme programming (XP) as it is sometimes called, at the company until more recently. One of the driving factors for moving to pair programming was the rapid growth of our business working with tech startups. In order to serve these clients, we needed to grow the team rapidly. As we started discussing options, implementing pair programming came up. Pairing junior developers with more senior developer on the team to mentor them through on the job training sounded like a good idea. In fact, we thought this was so much of a good move that we carved out specific team roles for Jr. Developers and Pair Leads.

Guess what? It didn’t work.

The “Pair Leads” got frustrated trying to bring the junior guys, good developers with Comp-Sci degrees and industry experience, up to speed on our system of development. And the junior guys weren’t learning half as fast as we hoped. In fact, they weren’t learning half as fast as they did with the old non-pair programming system. We tried a few things to improve the process overall, but nothing seemed to work. Unfortunately, compared to computer systems, debugging people issues are very hard. But sometimes, you guys get lucky.

In a conversation last week, Steven Covey’s book The 7 Habits of Highly Effective People came up. I can’t remember how or why this came up, but I’m glad it did. The person I was talking with said that they tried to read the book but gave up because it felt dated. I hadn’t read the book since business school, but could still remember quite a bit of subject matter. I started spouting them off a few of the habits (as best I remembered them):

Sharpen the saw.

Seek first to understand, then to be understood.

Then I said:

In order to be interdependent, you must first be independent.

I said it and I just froze. That was it! We were trying to throw junior guys who were not first independent working in the Cloudspace system into a pairing relationship which requires two highly effective developers to work interdependently. We totally blew it and now I knew why.

When used properly with skilled engineers you can’t beat pair programming for solving hard problems; creating high quality code; and, as Covey would said, making 1 + 1 = 3. But it is absolutely the wrong way to get junior developers trained.

Hindsight being 20/20, I now see the two types of pairing as 180 degrees from each other. When highly effective developers pair program the conversation is around system performance, best practices, tech trends — discussions of craft which often break into passionate arguments about the best way to achieve an objective. When one of the developers is not yet up-to-speed, the discussion is completely different and easy to spot. This type of pairing primarily involves discussion of syntax, improving skills, following processes & procedures, “let me do that for you to save time.” Basically, anything but craft is discussed. Yes, pair programming helps keep the developers focused and catch errors at every skill level. But I no longer believe that this is worth using pairing as a form of training.

So where do we go from here? At Cloudspace we are now re-tooling our training (we have some very cool stuff in the works on this front), ongoing developer development, and career paths. New recruits will go through training and then work independently on simple projects that really shouldn’t need pairs — all while receiving a high level of feedback; especially in the form of code reviews. They will only graduate to pair programming after they have demonstrated a basic level of mastery of their craft. (One member of the team has suggested that we bring developers into a dark room with tiki torches and read their fate from slips of paper written by senior developers Survivor style; but we aren’t there quite yet.)

Overall, we think that Cloudspace will be much better for making the change. And, as always, we wanted to share our thinking and screw-ups as publicly as possible so that everyone else can learn from our mistakes. Hope this one helps.

“Don’t worry about it. Start. Begin,” he replied.

He was right. I had made a classic mistake and in doing so I was ignoring our work processes with my own pet project idea.  I had ‘gone huge’ with the idea from the very beginning. I was planning user accounts, graphs, how to handle variant covers (a recent favorite variant for Green Lantern 51), and complex relationships for keeping a single master library of existing comic issues that would be separate from each user’s collection and reading log. Don’t get me wrong, it is good to be passionate about your idea and to know what challenges may be in your future but do not let that get in the way of getting your project going. Start small. Do the simplest thing possible. Constantly adapt your plans to your application’s needs. Be Agile.

That day I stopped mulling about things like how to order numbers that sometimes had letters on the end (see Batman 700U) and took my project agile. I started by building the simplest thing possible. I got going with no users, just an entry form with blank fields for comic title, issue number and date. Since then I’ve added a pop-up date selector, notes fields, the ability to enter ranges at one time, different collection views and a few other features. It has been almost a month but I’ve only worked on my application for 15-20 hours, at least 10 of them in the last couple of days. The ComicReads application is usable. It rocks! You could clone the ComicReads github repo, rake create & migrate your database, run ‘script/server’, and be ready to log your own collection but I don’t expect you to do so.

The most exciting part is that I have stopped logging my comic reading on notecards this past weekend and am now exclusively using my new application on my virtual machine. I haven’t added users yet, switched to mysql or solved several sticky issues— but I’m on my way. By starting with the features I needed— the ability to log the simplest and most essential parts of my comic book reading— I’ve made my project more exciting. Now that I have a working version, I find myself trying to work on it more and more. One day I will add user support, grab a URL, get a better design, and throw the system up for public use. Not this week though, I’ve got too much else to do.

Go ahead and get started. Begin! Throw out the users, forget connecting your application to twitter or facebook accounts, don’t worry about which database you are going to need, just go for it. Start by solving the problems that make your application interesting.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

This Agile principle is such good business advice, I could approach it from many other non-Agile directions. It almost transcends business and applies to all human endeavors.

Starting with the motivation issue. Larry Bossidy, one of the world’s top CEOs, says that when hiring, a person with absolute determination to succeed will always do better than someone with a high IQ and elite education who is cruising.

Approaching this from a different direction, I recently read a football coaching book, and one of NCAA coaches who contributed to the book said that given the choice between a player with solid technique and a player who is 100% motivated, he will pick the motivated player 9 out of 10 times. This advice is coming from a top performer in an industry that is incredibly well-scrutinized with clear outcomes and performance metrics. This gives me good reason to trust it.

So, speaking of trust, let’s move to that. I think that motivation can be universally agreed on as valuable, and if you don’t believe me, you’re probably not motivated enough to post a comment and debate it.

Trust is tricky. A favorite Warren Buffet quote of mine is that “it takes 20 years to build a reputation and five minutes to ruin it.” How can you quickly decide if a team is trustworthy? Of course we’ve all got markers for trust, but I think that a track record of similar and successful projects is a good place to start developing trust. If you can get access to the person who filled the “product guy” or client roles, ask them how they felt the team handled it. Did they feel that the team made intelligent decisions, but kept the client in the loop? Most importantly, did the team provide good value for the dollar spent?

Another thing that can help identify trustworthy people is talking directly to them. Are their answers clear and specific, or vague and filled with jargon? Do they make an effort to understand the client’s business and perspective, or do they insist on a particular solution no matter what the context?

Since trust is something that naturally has to build over time, don’t wait for 100% trust. If you’re always waiting for the perfect conditions, you’ll never get anything done. Jump in and give them a shot. This is one place where Cloudspace takes advantage of fast delivery and iterative development. Our process is based off single weeks of work. Of course, we’d love to work with you for several months, but if you have 10 weeks of work, start off for a week or two and see if you’re happy. Our clients are free to leave at any point, so this makes for an environment where we consistently perform and deliver. It also makes for an incredibly simple contract.

The last parts of this principle relate to the environment and support. I think this primarily involves internal teams, although a smooth client relationship is always helped when the client trusts the technology decisions and doesn’t second guess how things are constructed. There’s a balance between understanding the infrastructure and guiding the project, versus micromanaging and dictating. If you were going for surgery, you wouldn’t tell the doctor to use a #5 scalpel because you read an article on WebMD. You’d ask the doctor what is going on, expect clear and intelligent answers, then give the doctor space to work.

With respect to internal teams: Cloudspace helps create a healthy environment for our engineers by treating them both as engineers whose skills need to be kept current, and as human beings who have higher needs (think Maslow’s hierarchy). Because we treat our people well, our clients get great results from them.

To keep technical skills sharp and communication healthy, we have daily standups that last about 15 minutes where everyone gets a turn to share what they did since yesterday’s standup, and anything new they learned. We have weekly “hack sessions” where we review a new technology, or spend time cross-training (teaching things that are immediately relevant to our projects). We constantly talk to people and make sure they are happy with the progress of their project, and to identify things that may limit progress. We’re all in a private IRC channel so that we can instantly tap collective team knowledge, or jump to a public channel and tap the knowledge of the community.

Also, good milk comes from happy cows (I know this; I saw them gazing out at the ocean at Point Reyes a few weeks ago in California before eating some of the amazing cheese their milk produced at Cowgirl Creamery). We have team outings where we’ll go out for beers, bowling, laser tag, go-karting, or a movie. We have a comfortable dress code — sandals and shorts are common in our Florida summers — but we still respect our clients enough to put on a collar to greet them. Since we pair program our Agile projects and have to communicate, we don’t wear headphones, but it’s typical to trade off on choosing music to put on the speakers (I personally love Pandora, Grooveshark, and The Hype Machine).

All of these things add up to a lean and effective team that has what it needs to execute client strategy and deliver great code. We trust our engineers to do a great job — we don’t micromanage them. Our turnover is virtually zero and we’re proud of it. That’s the value of a good environment and healthy support.

Business people and developers must work
together daily throughout the project.

In the post on agile principle number two, I gave the example of a Secret Santa management system, as an example of how being able to accommodate changing requirements can benefit a project. As a refresher, here’s the key story points of the project:

• A user should be able to sign up
• A user should be able to log in
• A user should be able to get a recipient assigned
• A user should be able to add notes to their recipient
• There should be an “Add Amazon product” link that searches on Amazon
• There should be a “Buy on Amazon” button

I’m going to reuse this example to show the value of business people working closely with developers. You can refer to the original blog post if you like. I’m going to be counting the number of product owner-engineering interactions in the Agile scenario:

1. Meeting with the dev team to decide that sign up and login functionality are essential
2. Being notified of the sign up and login completion/deployment
3. Verifying sign up and login
4. Being notified of the recipient selection completion/deployment
5. Verifying recipient selection
6. Being notified of the notes completion/deployment
7. Verifying notes
8. Having developers stop work

That’s 8 different product manager-engineer interactions, and this is a tiny hypothetical product — we only did 4 story points! This doesn’t include questions or clarifications that inevitably come up in all projects while the developers are at work. You show me a client that thinks it’s okay for each of these interactions to wait for the weekly (or longer) review and I’ll show you a client who is overpaying for bored developers.

So what if you’re concerned that these interactions suck up time? Given that other than planning meetings (which occur in waterfall too) the interactions generally last 30 seconds for a quick question or notification, or 5-15 minutes for verification. I’ve never met a client who was too busy for this. Also these frequent interactions give you frequent input. That lets you guide your project — think about driving a car that you can only steer every 30 seconds. It’s worth it.

This is actually one area where Cloudspace adds it’s own flavor to Agile. Pure Agile processes mean an onsite customer, working as a product manager full time. We realize that when working with startups, they don’t always have the time or resources to devote a full person to being available immediately. So we give our clients flexibility. We find out why the software is valuable and what the business goals are so that we can make good decisions if we reach a point where the product manager is unavailable but we need to move forward. Of course, sometimes the good decision is to hold off on one ticket and be productive on another. Clients are always consulted on key decisions. We’re also good at batching these interactions into the daily meetings — a 15 minute meeting or email where we update the client on the day.

From the developer side of things, having easy access to answers is great. There’s nothing worse than trying to guess how an entire feature should work, and then having to rewrite the whole feature due to a difference in perspectives. Remember: happy engineers are productive engineers.

Speaking of happy engineers and productive engineers, in my next post we’ll be talking about the 5th principle of Agile: trusting a team of motivated engineers.

P.S. If you are one of those rocking motivated engineers, Cloudspace is hiring!

We took a look at the documentation and the library seemed to implement the same functionality as ruby’s standard library and then some. It even supports punycode! We installed the gem and tested it in irb with the URLs that had given us problems. It worked perfectly.

For the most part, just config the gem in your environment.rb file and append “Addressable::” before any instance of “URI.” in your code. Instead of “URI.parse(url)” you’ll now have “Addressable::URI.parse(url)”. But be sure to take a glance at the documentation because there are a few methods that don’t exist one-to-one in the libraries. For example: instead of calling URI.decode you would call Addressable::URI.unencode.’

We decided to run a test using ruby’s built in Benchmark library and compare the parse methods in each since that was the method used most often in our code. We started by requiring all the neccessary bits and whipping up an array of 1 million random URLs.

array = (1..1000000).map {
  "http://cloudspace.com/#{rand}?#{rand}=#{rand}\##{rand}"
 }

require 'rubygems'
require 'uri'
require 'addressable/uri'

Then here is the code to run the benchmark:

Benchmark.bmbm do |x|
  x.report("uri") { array.each { |u| URI.parse(u) } }
  x.report("add") { array.each { |u| Addressable::URI.parse(u) } }
end

And here is the result (the values are in seconds):

Rehearsal ---------------------------------------
uri  65.660000  23.670000  89.330000 ( 97.630597)
add 128.030000  22.270000 150.300000 (161.927209)
---------------------------- total: 239.630000sec

          user     system      total        real
uri  65.170000  23.140000  88.310000 ( 93.674252)
add 127.920000  22.600000 150.520000 (166.662719)

With a little bit of math on our own

Addressable takes almost twice as long as URI to parse the URLs. In our case, the time difference is still a minimal concern considering the benefits of having the URLs parsed to the more modern RFC. So we went for it and it is working great for us! Thanks Sporkmonger!

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

As I mentioned with the last principle, we welcome change. We count on change happening, and we use it, Judo-style, to our advantage. But, part of the success to navigating change is feedback. You need quick feedback. And, when you’re developing software, feedback comes from delivery.

In my last post, I used the example of a project whose requirements changed midstream, and as a result, was able to be delivered under time and under budget. The requirements were able to be changed because the software was delivered throughout the project.

“They add the recipient selection feature, which takes a day, and then the notes feature, which also takes a day. Of course, they’ve deployed the entire project for your verification after each of these steps”

This demonstrates two other advantage of frequent deliveries.

1. Verification
2. Usage

Verification

Although I manage the Agile team at Cloudspace, I spend most of my time writing code. I will tell you from experience that the best time to verify that something was done correctly is right after the developer has finished the ticket. Even with well-written and documented code, the benefit of having that portion of the system fresh in the developer’s mind saves you on restart/context switch costs, however small they may be. Frequent deployment lets you verify changes during this golden period. I’ve heard of some clients verifying a feature months (even years!) after the code was written — it’s not pretty. If you’re paying for the development work, you want to verify things ASAP.

Usage

Let’s say your development team finishes the login/registration system on an internal company app first. Great! Now you’re free to go ahead and create accounts for everyone at your company. You’ve got to do it anyways; may as well do it in parallel with development. The same number of man-hours will be used, but the system will overall be usable in less calendar-hours. Plus, by using that part of the system, *you’re verifying that it works!* Awesome! You know it will make sense and work for the end user. Can’t do that if the code is sitting on a development server or in a version control system.

At Cloudspace, we facilitate frequent delivery by starting with existing base functionality, and deploying to a production server as soon as possible in the app lifecycle — usually within the first two days. Even if you don’t have a domain ready, we make sure you’re able to start moving through the app; I’ve even gone so far as to point a personal domain at a client’s project so that they could start playing around. We’ve also got custom deployment scripts to make sure that the process is easy and painless for our developers. Given the frequency of deployment, anything more than a single command is too much friction.

So, I think I’ve given a few compelling reasons for frequent deployment being a good thing. The time and money savings are direct, and as a consequence of fast verification, you’ll notice bugs or user experience issues very quickly. This translates into happier users, and more success for your project.

If you’ve had success stories as a result of continuous delivery of working software, or if you think I’m full of hot air, I’m interested to read your thoughts in the comments. Fire away!

Keep an eye out for the next post in the series, where I explain why business people should talk with the developers. Don’t be scared of their non-existent tans, or the fact that they work in darkened offices. Developers are your friends!

And with that intro, here’s #2 of 12

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Everything changes. Software is not set in stone, and even if it was set in stone, it would still change. So, we need a process that gracefully handles change. Part of this trick is by getting rid of the idea of a 12-week project, and instead having 12, 1-week projects. You want to have small, frequent plans.

Let’s take a sports analogy. If you found out a football coach was trying to plan out every single play for the whole game during the first quarter, you’d laugh yourself off the bleachers. There’s too many contingencies to account for. Instead, you want a coach that’s going to break their planning down. Each play is a new project. Each project is planned quickly, executed quickly, and learned from…quickly.

So, this sprint-based planning is intuitively better. Let’s work with a more real, software world example.

Let’s say you’re responsible for a system so that your company’s users can coordinate their Secret Santa gift giving. You’d have your requirements:

• A user should be able to sign up
• A user should be able to log in
• A user should be able to get a recipient assigned
• A user should be able to add notes to their recipient

Now, since Amazon.com is super cool, and lots of people buying their gifts do so online, so you definitely need Amazon integration.

• There should be an “Add Amazon product” link that searches to Amazon
• There should be a “Buy on Amazon” button

OK, so we’re good on the requirements. So, let’s play this out through two scenarios. The first is a regular, waterfall-based project. The second, is Agile.

Waterfall

You go to your dev team, and find out that they think the sign up and log in features will take 3 days, the recipient selection/notes feature will take 2 days, and the Amazon stuff will take 4 days. 9 days of development time. Not bad. That’s just under two weeks. So, you let them have at it.

One of the devs starts working on the sign up process, and the other starts looking into the Amazon APIs, for the integration. They go back and forth a bit, each working on their parts, the Amazon researcher adding information to the docs, then doing some coding on that part of the project, and 9 days later, they are miraculously done on schedule.

You being the proud project manager, you put it out there. Sally in Accounting notices that the Amazon integration doesn’t always work right when she presses enter on the text field, so there’s a day of debugging that. OK, 10 days. Not great, there’s about an 11% overrun on days, but not bad either. All is well.

Agile

You go to your dev team. You decide that the sign up and log in functionality is essential to the project, so that gets implemented. This takes 3 days. Your Agile dev team deploys the code so that you can verify the features. Sign up and log in both work. Awesome.

The dev team continues. They add the recipient selection feature, which takes a day, and then the notes feature, which also takes a day. Of course, they’ve deployed the entire project for your verification after each of these steps.

Since you started on Monday, and it’s been 5 days, that makes today Friday. That’s perfect! Next week, finish up the integration with Amazon, and you’re done.

Since your dev team has done such a great job, and the code is out there and running, you decide to send an email to the management team at your company, showing the progress so far.

You come in on Monday, and find an email from the company president in your Inbox.

“Hey, great job on the Secret Santa project. I love the notes feature, I’ve been able to search Amazon for gift ideas and just paste the URLs into the notes section for my recipient. Everyone else has been using the product already, and is really impressed. Great job!”

Wait, what? We had a spec document and haven’t even implemented all the features. The project isn’t even done!

Oh yes it is. Tell your devs to stop working. It’s 100% usable, because your requirements changed. The project is done, you adapted to the change, and you got it done in 5 out of the 9 days. That’s a 44% *underrun* in time. Go ahead and give that extra 44% back to the accounting department, and enjoy the shocked look on their faces.