peat dot org

Estimates for software are terrible, terrible things. When I was a budding web developer, I thought I had it pretty much figured out: X hours to solve the stated problem, X hours to write the code and tests, then double the sum (aka, “the optimistic compensation adjustment”).

That worked alright when my job was just writing code, but utterly failed when I struck out on my own. Aside from figuring out how to budget for planning, communication, integration, and deployment … I also realized that I brought a huge number of technical assumptions to the table, and that my assumptions weren’t always in line with what the customer needed.

So, over the last several years I’ve compiled a set of questions that help me better understand the general technical requirements for a project. It isn’t comprehensive or complete — you can’t fill out the form, pull a lever, and have an estimate shoot out — but it is a good starting point, and has helped me quickly figure out a the client’s expectations and experience with building web applications.

Chances are you’ll have to put on your expert hat and coach your clients through some of these questions (and their implications) … but that’s what they’re paying you for, right?

So, without further ado …

Accessibility

• What are the minimum requirements for devices and browsers we should support? (eg: a modern computer running IE 6+, FF 2+, or Safari 2+)
• What accommodations are necessary for impaired individuals? (eg: adjustable font sizes for the visually impaired, tactile interfaces for the blind and deaf)
• Are there specific accessibility regulations that may apply to this project? (eg: Section 508)

Reliability and Recovery

• What are the primary usage hours? (eg: business hours across the continental United States)
• What is the maximum acceptable downtime during primary usage hours? (eg: 4 hours down per month)
• What disaster scenarios should we have a contingency plan for? (eg: failed hard drive, hurricane, nuclear war)

Performance and Scaling

• Approximately how many people are expected to interact with the system during peak hours?
• Approximately how much tabular data will the system be managing? (eg: contact information, dates, product descriptions, etc.)
• Approximately how much binary data will the system be managing? (eg: photographs, music, video, etc.)
• How many reports need to be available in real time, and how many can be run in periodic batches?
• What is the minimum acceptable load time for interactive pages? (eg: a wizard for creating a new member accounts)
• What is the minimum acceptable load time for data intensive pages (eg: a report, or complex searches across the database)
• How quickly do you expect the site to grow? (eg: 2000 users within 12 months, 1M photos within 3 years)

Security

• Will we be managing sensitive information? (eg: passwords, bank account/credit card information, etc.)
• What are the requirements for encrypting data sent over the public Internet? (eg: checkout process involving credit card transactions)
• What are the requirements for restricting physical access to the hardware? (eg: sealed cabinet at hardened telco hotel)
• Is a shared hardware hosting plan acceptable, or are physically separate servers required?
• Is operating system access control of network resources sufficient, or is a separate hardware firewall device required?
• What security breaches should we develop contingency plans for? (eg: customer account compromised, theft of physical server)
• Are there any specific security regulations that may apply to this project? (eg: PCI-DSS, government security clearance)

Integration

• Will this system interact with any other systems? (eg: credit card gateway, LDAP server, Google Maps)
• What contingency provisions should we have if those systems are not reachable?
• Will this system provide services for other systems? (eg: this system provides single sign on, or web services for accessing data)

Environment

• Does your company have any specific requirements around languages, protocols, or deployment environments? (eg: Oracle database server, Java EE 5)

Documentation

• How comprehensive should the technical documentation be? (eg: inline comments in the source code, UML modeling, interaction diagrams, API documentation, etc.)

Anyone have other things to contribute?

Found in the OmniPlan manual:

Heh.

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.

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?

Have I mentioned I love 3×5 index cards? They are quite possibly one of the finest inventions ever, for several reasons:

• Cheap
• Portable
• Recyclable
• Small

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:

1. Write down a goal on the front of the card. Something like “Person signs up for the site.”
2. On the back of the card, jot down some notes about the process. “Requires opt-in confirmation of e-mail address, unique username”
3. 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.

For your enjoyment, I present Project Borat¹, 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.

Good stuff.

Next up: Indexing Project Borat

¹ 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.

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 stickers¹.

The trick to selling web applications is Delicatessen’s secret ingredient: it’s all about the people².

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.

¹ 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.

² 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.

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.

Sound familiar?

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 room¹. 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.

Good times.

So, where do you think paired writing could be valuable in your business?

Where do you think it’s superfluous?

Let me know!

¹ We have an “open pit” development environment. I should write something about that later.

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?

… 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.