Behind the Curtain at TCG

Challenging Torvald: Specs Are the Language of Negotiation

According to an article in SYS-CON, Linus Torvald posted a message on the ‘net saying that specs don’t help in software development, that they are a needless level of abstraction.

Torvald may be right when the developer is the client, creating a program for his own use and perhaps for sale. But he is wrong when the developer is hired to fulfill someone else’s vision. Specs, and all the other stages in the planning process (project plans, wire frames, prototypes, mock-ups, etc.), are the language of negotiation between what the client wants and what the developer can deliver -- given the time, the cost, and the limitations of the technology.

If you were a builder you might build a three-bedroom center-hall colonial based on your idea of what a three-bedroom center-hall colonial should be, and then sell it to someone willing to live in it. But no one is going to come to you and say "I want a three-bedroom center-hall colonial," and then sit back and wait for the results. The future owner wants to have a say in exactly how big the kitchen will be, and whether there is a deck in back, and a host of other details. To avoid having to tear down walls later, you are going to sketch out the house and then create blueprints for the client's review, long before you start digging the foundation.

Similarly, if a developer were to have an idea for software, and build it, he might not need specs: it would be his work, and he only has to communicate with himself. (Whether it would be a good idea for him to lay it out in increasing levels of conceptual detail before he starts coding is another issue.)

Our clients don't say "I want a system that will handle all grants for the Department of Transportation" or "Give me a Web site that will help autism researchers" and give us a pile of money and wait for it to be delivered. They work with us step by step, and we reflect back what they say they want in increasing degrees of complexity -- from back-of-the-napkin drawings to elaborate mock-ups through the actual design and build. At each point they are asked to review what we have produced so they can be sure we understand what they are aiming for. "Specs" just help people work together. They are an important step in the communication process.

Recycling business detritus

When in the course of business events it becomes necessary for one party to dispose of that which once seemed necessary, the question is always: What the heck do I do with all this stuff?

It used to be easy to donate computers - nobody was really all that picky about what they got, as it was all expensive and useful. Nowadays, that's no longer the case. I find that more and more we're paying people to take our old hardware off our hands. (Occasionally I have had success in getting people to "acquire" my equipment/furniture/manuals/swag. I do this by leaving it somewhere with a lot of traffic and making it look valuable. Alternatively, selling it on Ebay seems to work pretty well.)

Cell phones are still pretty easy to donate. There are a lot of organizations that'll take your cell phone off your hands and give it to someone who needs it. Good thing, too - these small phones make terrible doorstops.

The most annoying thing to me was always toner - toner cartridges are really easy to recycle if you know how to do that. But finding a place that will take my old stuff has been complicated by my extreme frugality - I simply refuse to pay for shipping.

Yesterday, however, I learned of a wonderful initiative. Costco just started a program to take old cartridges - laser AND inkjet. So this morning I printed off a couple of labels, filled boxes with old empty cartridges (amazingly, we had 10 lying around the office), walked out to the mail drop in our office, and noticed the postal truck across the street. Five minutes after I started, the cartridges were out of my office forever. What service!

Better proposals - feedback from evaluators

Captureplanning.com has a great insight into what proposal evaluators are looking for, what they do not like to have to read through, and what type of information delivers the strongest proposal. There is a wide range of evaluator types included in the article but most of the insight is valuable to everyone involved in the proposal effort. Bottom line: drop the fluff.

Small Business Report leaves questions

An article at FCW.com points out that the Small Business Administration may have overstated the percentage of federal contracts going to small businesses in a recently released report.

An Aug. 25 SBA report states that the government awarded small businesses $69.2 billion worth of prime contracts in fiscal 2004, just more than the minimum 23 percent statutory requirement.

However it is believed that this number is inaccurate because it does not take into account all awards including contracts awarded outside the United States and those that agencies such as the Transportation Security Administration and the U.S. Postal Service funded. These concerns are valid because the SBA notes that there is a "margin" or error in the reporting used to generate these numbers. The agency's report marks the first time that SBA has used the Federal Procurement Data System-Next Generation (FPDS-NG) as the source for the small-business report.

Critics complain that the revamped federal database contains errors. The SBA report states that transitioning to FPDS-NG has created some data challenges, but the business impact of most of those challenges is minimal.

This leaves the question of what is considered "minimal"? And how will these discrepancies be corrected for future reporting? Unfortunately according to this account

An agency document states that as a matter of policy, SBA measures small-business wins using a baseline that includes contracts funded with appropriations covered by the Federal Acquisition Regulation. "We anticipate following the same procedure when we next update the goaling guidelines," Raul Cisneros, an SBA spokesman Cisneros added.

It appears that in this case, close is good enough, but is that true? The Small Business Administration negotiates with each agency to determine how much money should be spent with small companies. SBA is responsible for regulating compliance with government-wide goals. If they set these goals, and they are monitoring these goals, shouldn't the reporting be as accurate as possible? The overall goals established by SBA for the agencies to award are:

• 23 percent of prime contracts to small businesses.
• 5 percent of prime and subcontracts to small disadvantaged businesses.
• 5 percent of prime and subcontracts to woman-owned small businesses.
• 3 percent of prime contracts to HUBZone small businesses.
• 3 percent of prime and subcontracts to small businesses owned by service-disabled veterans.

Why is any margin of discrepancy acceptable when we are discussing small business retaining its fair share of the pie? Would any margin of discrepancy be tolerated if this was a report for big business’? How can small businesses change this and make sure that the reporting numbers are accurate and that a true representation of what the agencies are spending with small business is reported?

The Information Pioneers

Last week I attended the a reunion of the NSFnet crowd -- lots of people whose names you probably don't know (and a few whose names you'd recognize immediately, like Dave Farber), who 20 years ago developed the standards and the systems that led to the Internet we know today.

At dinner I was sitting between the past and the future: on one side of me was a man who said that the creation of NSFnet, when none of us knew what we were doing and everything was possible, was the best time of his life. On the other side was someone who said that everything we experienced in the mid-80s is happening again, but today the focus is not networks, it's information.

Some of us (and I'm pleased to be among that group) are trying to figure out what it means to have so much information at our fingertips, and how to make it useful. One project I'm working on at TCG is to allow researchers to share autism data and tools; another one is to understand grants-management data and figure out how to streamline its collection and application. And of course I'm working to get The Journal of Electronic Publishing going again after a hiatus of three years.

These are all efforts to understand how to take advantage of the reams and reams (okay, that's a dated metaphor; perhaps it should be "terabytes and terabytes") of information that is <I>out there</I> and that can help us do our work and live better and more fully.

In 20 years I look forward to meeting many of my colleagues again over dinner at a great restaurant, and saying "that was the best time of our lives..."
--
Some links you might find interesting for the history of that time:

What happened in Internet technology in the 80's:
http://www.thocp.net/reference/internet/internet2.htm

A new project to document the history of the Internet:
http://internethistoryarchive.org/

What not to say in proposals - a quick list

What Not To Say In Proposals is a good resource for review prior to submitting a proposal. Since proposals are the final chapter in closing professional services and development projects, it never hurts to get advice and reminders of what might make your proposal better. The list is a good reminder that the proposal needs to be about the client's problem and the solution, not about you or your company. I have been referring to this page often and find that it assists me in staying focused on the things that make winning proposals.