April 11, 2007
For what it’s worth, I recommend OmniPlan if you’re on a Mac and in the habit of taking on fair sized projects with a bunch of people. The manual is super easy to follow, and it makes the process of estimating and tracking progress a lot easier (particularly if you have a lot of dependencies). It’s about $150, and the trial licenses are limited to a single day (grumble), but it just about halved the time it takes me to do estimates for time, people, and materials.
May 12, 2006
Here’s something I keep seeing when digging around on the ‘net and in books, and would like some perspective on:
PERT. The Program Evaluation and Review Technique.
Some people say it’s a relic of the Cold War; some people say it’s a good way to quantify how quickly individual milestones in a project can be completed.
What say you?
May 5, 2006
Have I mentioned I love 3×5 index cards? They are quite possibly one of the finest inventions ever, for several reasons:
The first three are obvious, but the last one is the lynchpin. Small is good because it enforces a reasonable constraint on the amount of information it contains. Small is good because you can fit a whole bunch on a desk, and you can move them around easily. Small is good because it’s “less,” and as the fine folks at 37 Signals like to say … Less is more.
What does this have to do with Project Borat? Well, index cards are really terrifically superbly great for collecting user stories. They’re not nearly as intimidating as filling out an official looking forms, and the interface is a heck of a lot more intuitive than any project management software I’ve ever seen. They encourage ideas, and when it comes time to cull the herd, they’re satisfying to rip up and chuck in the recycle bin.
The process of generating user stories with index cards is about as simple as it gets:
- Write down a goal on the front of the card. Something like “Person signs up for the site.”
- On the back of the card, jot down some notes about the process. “Requires opt-in confirmation of e-mail address, unique username”
- Cluster cards in some logically satisfying manner on the table. I suggest by functionality. For example, “User invites a friend to join the site” and “User removes a friend from friends list” both seem to fit into friend management.
When you think you have good coverage, take each cluster of cards and rubber band them together. If you have a lot of stacks and a lot of cards, feel free to put a top card on the stack to identify the general functionality.
In the case of Project Borat, it took about 1.5 hours to generate ~65 use cases in 12 groups. This isn’t complete coverage, it’s just for the business specific features of the site. Other things (like administrative user management) aren’t as sexy, and are relatively straight forward to implement without much guidance.
If you read my last installment, you’re probably thinking “where does the butcher paper fit into this?” It hasn’t, but it will—I just thought it would be good to break things down a bit more. The next step is selecting a core set of use cases that really define what the application is about … and then we hit the butcher paper.
May 3, 2006
For your enjoyment, I present Project Borat1, a top secret development project here at PLANET ARGON. What is it? I can’t tell you. Who’s the client? I can’t say. What does it do? Sorry. When will we see it? Nope.
How are you building it? Ahh .. yes. That’s something I can (and will) enthusiastically talk about in the months to come.
A little background: Project Borat is a pretty big project with high expectations, a fairly tight delivery schedule, an open ended feature set, and flexible priorities. The Client has extensive startup experience, expertise in the target market, and some rather good ideas.
All told, it’s a situation remarkably well suited for discussing agile practices and The PLANET ARGON Way.
So, first things first: requirements gathering and prototyping. We need to understand what The Client wants to accomplish, and deliver some mockups demonstrating how it can be done. This is going to take several days spread over the course of two weeks.
Yesterday we kicked things off with a healthy whiteboard session, identifying most of the significant components and their interactions. The result was mostly lists with a few interface doodles to demonstrate how information could be represented. We took pictures of the whiteboard as it filled up, and the relevant information was transcribed into about a thousand words for discussion on Basecamp.
While it was evident The Client had done considerable brainstorming and exploration on their own, a couple of significant and unique new features came to light. Take experts in unrelated fields, give them a common goal and a little time .. and innovation happens.
Next up: Indexing Project Borat
1 You may be asking yourself ”… Borat?” Borat is short for Borat Sagdiyev—a (fictional) Kazakh journalist who appears from time to time on Da Ali G Show. This project has nothing to do with the fine country of Kazakhstan, British television, or fake journalism.
April 21, 2006
No doubt about it, I am up to my eyeballs in Ruby on Rails projects. It’s exciting to see what people want us to build—everything from niche content management tools, to workflow management apps, to massive social networking projects. Proposals come in from companies ranging from basement startups to tier one financial institutions. Rails is certainly not a secret anymore; it’s a genuine phenomenon, and it’s attracting a lot of attention.
That said, there’s a big difference between attracting clients and signing contracts. Somewhere along the line, a decision is made to start writing checks, and if you’re in the business of writing software, it’s extremely important to understand why that decision is made.
So, here’s the stunner for a lot of us geeks: that decision has little to do with Rails.
“OMG,” you gasp. “WTF. Heretic!”
I know, I know. I’ll go back to drinking the Kool-Aid in a bit … But hear me out!
Rails won’t make your product a better product. Rails won’t give you the features that your customers want. Rails won’t manage your project and make everything run smoother. Rails won’t cook you breakfast, mend your pants, walk your dog, or print bumper stickers1.
People write code. People design and manage infrastructure. People answer the phone and fix problems. People create attractive designs and optimize interactions. And, thankfully, people also cook breakfast, mend pants, and walk dogs.
Those who are willing to invest a significant amount of money in a web application want confidence in the people who build it for them. They know technologies don’t guarantee anything, and they know buzzwords don’t make the product. They want developers who produce efficient and high quality code, designers with good taste and excellent CSS skills, and managers who return their calls and take a personal interest in their projects.
Quality people can produce excellent products with whatever platforms or languages they’ve honed their skills on. Java? Sure. PHP? Why not? C#? Yup!
So, why do we exclusively develop with Ruby on Rails? Because we’ve used Java, PHP, C#, Python, Perl, and a shocking array of slightly obscure languages. We’ve seen how language affects architecture, run the gauntlet of application servers, and rescued projects from spaghetti code hell. We’ve started our own companies, created our own products, and in the end, we recognize that Ruby on Rails works well for us, and how we build web applications.
In short, the magic happens when the right people people get their hands on the right tools for the job.
Sell the whole package: your people, your resources, your experience .. not just the technology.
1 Actually, this is a lie—Rails does print bumper stickers. One of our clients uses Rails to manage the printing of custom calendars, photo mugs, and all sorts of other photo paraphernalia.
2 Taking the Delicatessen analogy a bit further: Technology may be the buttery creamy icing, but people are the delicious fudgy cake; technology might catch a client’s attention, but nothing satisfies the appetite like good people.
April 20, 2006
When pair programmers go home for the night, they leave behind software and documentation—these are persistent artifacts. Persistent, meaning it lasts longer than the process that created it; an artifact being something with inherent value or purpose.
Persistent artifacts can be found everywhere in business. Products, for example. Shoes. Watches. Chopsticks. I’m not going to claim that pair processes work best for building all products … but they do work pretty darned well for written products.
What kinds of written products do you produce in your day to day life? Notes jotted down and kept in your pocket, casual e-mails sent to friends and coworkers, presentation outlines, meeting minutes, proposals, memos … even software.
We do a lot of writing. Of course, not all of it is well suited for pairing—things like your thank you note to Aunt Mildred, or personal notes from the morning standup meeting.
On the other hand, things like marketing copy, sales proposals, and software—these are substantive things that represent your team (business, division, etc.). They require attention to quality, and their content frequently crosses boundaries.
Lets take the example of a project bid—something I actually have to deliver this afternoon.
Now, theoretically I could just write something up, e-mail it to Jeremy for technical approval, wait for his feedback, incorporate his estimates and adjustments, then send it out.
But, dangit, theory just doesn’t match up with reality. Jeremy will see some flaws or opportunities and ask a few questions. I’ll respond in kind, but he’ll be heads-down on a project. He’ll eventually come back with his response, but I’ll be knee deep in other correspondance. The cycle repeats. You get the idea. We’ll get the job done, but these are the kinds of patterns that contribute to continuous partial attention and missed opportunities.
What’s the pairing approach?
Jeremy and I reserve time in the conference room1. I bring my laptop, he shows up empty handed. We spend a couple of minutes reviewing the client notes on Basecamp and then we hash out an outline for the bid. I type; he looks over my shoulder and helps navigate. Technical and client questions can be instantly answered (or at least identified as open), mistakes are caught (technical or otherwise), and in the end we have a bid that we’re confident in and are willing to take responsibility for.
So, where do you think paired writing could be valuable in your business?
Where do you think it’s superfluous?
Let me know!
1 We have an “open pit” development environment. I should write something about that later.
April 19, 2006
Yesterday I posed a question: can pair programming techniques be used to improve other business processes?
One of the aspects of pair programming is information transfer—that two people who work directly with each other have a much stronger mutual understanding of the task at hand.
Where this seems to be most important is when crossing boundaries of responsibility. For example, I’m responsible for delivering a price and spec for an iteration, and Jason is responsible for delivering the code. In order for us to be responsible for what we’re doing and have confidence in our goals, we need to a thorough understanding of what and how we’re going to do it.
Where else in business can these boundaries be found? Off the top of my head:
- Deployment and development: what are the deployment requirements for an application in development, and what are the deployment capabilities?
- Development and sales: what does the customer want, and how much will it cost to build?
- Sales and marketing: what do our potential customers respond to, and what through what channels can we reach them?
These are all things that fit the “pair” model well—they all generate persistent artifacts (documentation, code, marketing literature, etc.) and require detailed mutual understanding of the issue.
Where have you found these boundaries in your business?
April 18, 2006
… in the development room:
TDD makes writing code super easy. All the hard thinking happens when you’re writing the tests and designing the API, and then it’s just red light / green light when you’re writing the implementation.
It seems that writing your tests first helps enforce the idea that you need to understand a problem before you can solve it. Particularly with large projects, building a comprehensive test harness is a fairly cheap way to explore architectural issues without committing to a particular implementation.
April 18, 2006
Pair programming can be a really marvelous technique, especially in sections of critical code. It cuts out the communication lag between writing and review, keeps developers in sync, and helps the people involved stay focused on both the immediate technical issues and the overall architecture. I have ring-side seats when Jeremy and Jason take on a tricky component … and it’s an amazing thing to watch.
Anyhow, back to the original idea: can this practice be applied to business processes?
To frame the question a little better, lets look at what pairing achieves in the development world: high quality persistent artifacts, and detailed mutual understanding. That is, good code that sticks around for a while, and two people who know it inside and out. From a development perspective, you can’t get much better then that.
Can this be applied to sales? Marketing? Management? Food for thought.
I’ll write more later.