Do You Really Need a Patent?

Back in June 2008 I attended a seminar on intellectual property rights (IPR). A lot of the hype around entrepreneurship seems to centre around the idea that one must have patents to protect a company's IPR, otherwise the sky will fall, or at least, the company won't be worth anything if and when you want to sell it. Here are my notes on why that isn't necessarily the case, what you can do (other than patenting) to protect your IPR, and what role patents do have to play.

Patents protect functional designs by granting a monopoly to the holder, ensuring that no one is permitted to produce a product that carries out the same function in the same manner, regardless of whether that invention was independently conceived (see Out-law's article "Patents: the basics"). In principle, this means that the holder has a 20 year head-start on their competitors. The downsides are that when a patent is granted, the details of the invention are publicly disclosed, and that registration and maintenance of patents costs huge amounts of money, particularly if one wishes to hold the patent in multiple countries. Asking a friendly lawyer to waive their fees on the promise of future profits may help with drafting the document, but not with the Patent Office fees.

Do you need a patent?

Firstly, it's important to realise that there are rights for which there is no need to register. These include:

• Copyright: prevents exact copies of your work (literary, film, software) being made. Note that this does not prevent against quite similar designs, provided that these were the product of independent creativity. In the UK, copyright is automatic, i.e. there is no need to assert your claim via a legal message (though many people choose to, for clarity). See Out-law's article "Copyright law: the basics".


• Design Right: unregistered design rights cover aesthetics qualities, such as the form, colour, look and feel, or texture of a product. For software, look and feel is hard to protect with copyright (though logos can be), whereas it can come under design rights. Registered design rights (fee required) allow the holder to enforce a monopoly, i.e. even an independently created identical design would be an infringement. In contrast, unregistered design right only prevents direct copying. See Out-law's article "How design rights can add value to a business".


• Semiconductor topography right: design rights protect aesthetics, whereas semiconductor rights protect the layout of integrated circuits that are used within a product. The main reason for this is that the different layers of such circuits can be easily photographed, and then copied, but the investment required in initial design may be enormous. See ESA's article "About semiconductor products", and Mewburn Ellis' article "UK & EU Unregistered Design Rights".


• Database right: a database is essentially a systematically ordered collection. The items within the collection may or may not be subject to other protection, but the effort/costs in amassing and organising the collection is what is protected by database rights. It is important to note that such costs are solely those of collecting and verifying the data, rather than those of creating the data. See Out-law's article "Database rights: the basics".


• Trademarks: the goodwill associated with any design that can be represented graphically, such as a name or a shape can be protected against a competitor "passing off". This takes place if they use the trademark in such a way as to take advantage of the goodwill associated with the mark. Registering a trademark does cost a fee, but additionally ensures that the mark is protected more widely, in areas you may not yet be trading in. Not registering may mean that another party does register it, and later prevents you from using it. See Out-law's article "Trade Marks: the basics".

The key point is that all of these are IP rights, but they don't cost anything (at least, the unregistered versions). It might well be that you're actually better off registering (or not) one of these rights instead of trying for a patent. Note that all rights are time-limited.

Secondly, is the patent registration actually worth it? Patent ideas can (hopefully!) be commercialised, but they must generate enough cash to defend the patent! If the value of the invention (or subsequent inventions that might depend on it) isn't high enough, there's little point in patenting.

Thirdly, 18 months after filing, the idea will be revealed. Do you actually want to reveal anything, rather than relying on keeping the mechanisms of your invention secret? Competitors can catch up fast after your public disclosure! Even if you decide to patent, when is the right time to reveal? Waiting longer may mean your competitors develop a similar technology and file a patent, but may also mean that you can develop the details further, and hence file a broader and more detailed patent, which may be more defensible. Dragging out the filing process as long as possible will mean you have the protection of a patent application, and yet are not liable for maintenance costs.

General Patent Advice

As regards working with another company, the received wisdom is to never give another company joint ownership of your patent. If this happens, questions of how revenue is to be shared, or who dictates the territories that the patent is registered in, arise. Licensing to the partner company is by far the best way, particularly if your partner subsequently wishes to sell their portion of the patent (rather than having a license) to one of your competitors!

Note that a single patent may not be enough. Again, the advice is that defence in depth is a definite advantage, which guards against a "bad" court judge ruling in your competitor's favour. Of course, the more patents, the higher the costs...

Prior art constitutes any expression of the proposed invention that is already publicly known about. Hence, if you are the first to invent, prior art will, by definition not exist. The concept of "first to invent" is particularly significant in the United States. There, one possibility is to use lawyers to store date-stamped ideas in their safe, thus acting as witnesses to the statement of when the invention was created, whilst not releasing the idea publicly. Several ideas stored in such a way can later be included in a single patent, thus reducing costs.

When drafting a patent application, you could of course attempt it yourself. However, if you seriously intend it to be useful for later enforcement, it is far better to bite the bullet and contract a good lawyer. Failure to invest at the beginning may well mean a far greater loss later on.

Finally, it's worth asking why patents are regarded as so important. One reason is that investors are keen to ensure that their stakes will appreciate in value. This will not happen if the company's core product is able to be copied by a competitor. Because patents grant a monopoly, provided that the invention is in demand, the patent holder has a guaranteed revenue stream.
Hence, when, for example, a venture capital firm invests, their due diligence procedures involve checking that the source of the company's core business is patented. One corollary of this for startups is to ensure that all employees and contractors are contractually obliged to cede any IPR they generate to their employer, thus clearly stating the ownership.

Views from VCs: Notes from The Investors' Forum

Yesterday evening I attended The Investors' Forum, an event jointly organised by CUE and CUTEC in Cambridge, aiming to show that there is still investment available for start-ups. On the panel at the event were Reshma Sohoni (SeedCamp), and Laurence John (Amadeus Seed Fund), who talked about (pre-angel) seed funding; Kerry Baldwin (IQ Capital) for injections of around £1.5 million; and Simon Cook (DFJ Esprit) and Sitar Teli (Doughty Hanson Technology Ventures), for investments of £10 million or more. Alex van Someren (nCipher) moderated and gave the entrepreneur's viewpoint. Here's my notes on what they said:

• The economic downturn has affected some funding decisions. Seed funds are asking companies to try to do more with less investment, and to have working demonstrations in less time. Larger funds have been used to their companies not being able to obtain bank loans, hence there has always been a sort of "credit crunch" in that area, thus no effect. However, Sitar Teli pointed out that some businesses (such as semiconductor manufacturing) would need to take on debt at some point, and at present that type of company would not be a good investment.
• Software start-ups were more likely to receive seed funding than hardware start-ups, due to their need for smaller amounts of money. However, hardware is still an option (Laurence John).
• Proposals seeking VC investment need to show both a strong business case, but also a robust customer base. Previously investors would not have checked as rigorously as now how strong the market is (Kerry Baldwin).
• Investors did not believe that they were using the economic downturn to drive down the price they offered entrepreneurs for equity stakes.
• When coming with a proposal, it was emphasised that the amount being asked for should be planned to result in a real step change in the company. Similarly, a plan of what funding will be needed at which points in the business, and what the end dilution and valuation will be, is hugely important in order to ascertain whether an investor will even consider the company. If the end valuation means that the investment does not gain very much value, evidently investors will not be interested.
• Getting to know VCs before asking them for money was recommended. This allows them to be more confident in you at the point where you ask for investment.
• Select which VC to court carefully. There is little point going to one that invests £10 million minimum if the company only needs £250k.
• Try to court multiple investors, in order to allow the market to set a fair price for a stake in the business. Otherwise one investor can effectively set as low a price as they wish.
• The relative importance of teams versus ideas was debated. For seed funding, where ideas are at a malleable stage, the quality of the team was regarded as most important (Reshma Sohoni). For larger investments it was less obvious which was most significant.
• Experience was regarded as hugely important in obtaining large investments at the start (unsurprisingly). First-time entrepreneurs should normally start with seed funding. The exception was if there was significant, patentable IPR behind the business idea.
• In any presentation, get to the point, and explain how much investment is needed, and what it will be used for.

All sounded sensible, though valuable as it goes to show that some investor attitudes have changed, whilst others have not.

Lessons from Hermann Hauser

Another interesting Enterprise Tuesday lecture by serial entrepreneur and angel investor Hermann Hauser (Amadeus Capital Partners). He talks about the mistakes he has learnt from in five of the 62 companies that he has been involved with: Acorn, ATML, Harlequin, ART, and Polight. Here are my notes and thoughts:

• Acorn spent its first five years not being able to produce enough computers to meet the demand. It therefore signed long-term agreements with manufacturers, and eventually met demand. Unfortunately, at this point the market crashed. Inventory piled up, and the company had to be rescued by Olivetti. Corollary: understand the variations in your market, and plan inventory sizes appropriately.


• ATML's initial product was (probably) the best 25 Mbit/s ATM switch on the market. This did not sell, as 100 Mbit/s switched ethernet soon arrived on the scene. Larry Ellison (of Oracle fame), invested in the company, and hence kept it afloat. However, the company began to make significant sales of its ATM to IP "conversion" chip to manufacturers of DSL modems. The business model was then changed, resulting in real growth. A merger with American company Globespan was proposed, but this turned out to be a bad move, as their management team was not as strong as ATML's (by this time Virata). Corollaries: product strategy needs to be correct (and malleable); don't assume that as a British company you need to be bought by an American company to succeed.


• Harlequin's aim was to build the world's greatest AI company, by producing a LISP interpreter. But this wouldn't be profitable, as it would be a small market. In order to obtain revenue, the company produced PostScript technology for printers. The founder refused to raise cash through selling equity, but wanted to raise debt. Natwest gave him a £5 million loan. That increased to £10 million. The difference between banks and VCs is that banks can call in the loan. Harlequin was sold for £1. Corollary: in a fast growing, high-tech company, you need equity, not loan, finance.


• ART (Advanced Rendering Technology) made a break-through in hardware rendering technology. Genereated photorealistic images for car companies. But there were only so many car adverts that needed making! Corollary: market size matters!


• Polight produced holographic storage technology. Unfortunately, a very gifted physicist on the team showed that it was in fact impossible to produce the technology that they were working towards. Corollary: sometimes the technology itself may be at fault.


• Time estimation: whatever you estimate, multiply by Pi to get a realistic estimate. Similarly, market size estimates tend to be very overstated.


• People-related issues are common: people fall out with each other surprisingly easily.


• Finally, keep making mistakes, but make new mistakes.

Personally, I think that much of the above is obvious in hindsight. In other words, I'm sure that ART were aware that they needed a big enough market in order to generate sales growth long-term, or that Acorn would not have signed manufacturing contracts if it had known that demand was going to fall. Perhaps the most interesting conclusions to be drawn centre around how ATML was nimble enough to change their strategy (i.e. that they were willing to sell that one chip that was a tiny part of their much more complex core product), and that they would probably have done better not to merge with Globespan.

So how to avoid the "obvious" mistakes when starting out? Clearly it's not easy. Here's my take, for what it's worth:

• Market trends & inventory: of course, the ideal company is one that has no inventory, and yet can keep up with demand. If you're selling pure IPR, like chip designs (e.g. ARM), that's great, because inventory becomes someone else's problem. In the case of a software company (assuming its products are sold for download, or online use, rather than on shop shelves), inventory perhaps becomes synonymous with how much server capacity you have, plus possibly support staff. Hence, using cloud computing services such as Amazon's EC2, (or their content distribution network, CloudFront) and outsourcing non-core work to contractors (as suggested by Seedcamp's Reshma Sohoni) provides much greater flexibility to respond to demand. Of course, reading market trends hopefully means that you're aware of what proportion of your services are "base load" and hence could be performed in-house.
• Product strategy: be prepared to admit that your first idea didn't work, but that a part you never envisaged could be valuable actually might be. Concentrate on your core competencies.
• Market characterisation: talk to your potential customers! I find it incredible that there are so many web sites that make it so hard to give good feedback once they're selling (and that's after they've decided on their product!). As David Langendries pointed out in a comment on my post "The Dangers of Online Feedback", companies would do well to pick up the phone. Most successful products are preceded by good marketing (distinct from advertising), says Seth Godin. Which to me, means that technologists need to be very sure they can convince the customer that their product solves a problem that the customer (maybe) never realised they had. And convincing means talking, rather than yet another online survey.

So there you have it: terribly simple, right? ;-). Then again, you'll find plenty of other conflicting advice elsewhere. Over at OnStartups, Jason Cohen suggests that instead of trying to figure out which strategy is best, given that conflicting ones have produced equally successful companies, perhaps you just need to buck conventional wisdom (and hence not copy 37signals or Fog Creek)... Thoughts?

The Dangers of Online Feedback

Business Week has a very interesting book excerpt from "What Would Google Do?" (Jeff Jarvis), titled "Detroit Should Get Cracking on its Googlemobile", which caught my eye, in part, because I'm currently reading Tom Vanderbilt's "Traffic: Why We Drive the Way We Do (and What it Says About Us)". Jarvis points out that at present auto manufacturers don't really communicate with their customers about what they would like, or allow them to customise their cars in any meaningful fashion. If they had, he argues, we would have had ways to interface our iPods with our car radios long ago. In the future, if they treated cars as a platform that allowed users to create their own cars, we might see unpainted cars being sold, then taken to local graffiti artists. All hail "open-source" (?!) cars, apparently, not to mention open-source urban planning.

That got me thinking. Many large corporations are today accused of not listening to their customers. Meanwhile many are trying to use the Internet to change that (take a look at Get Satisfaction). It used to be that to listen to your customers involved conducting telephone or paper surveys, or paying people to be in focus groups. Now you can just set-up an online forum, or blog about your ideas and see what comments come back. In many ways that's good: the cost of soliciting feedback is minimal, so even one-person startups can do it. The bad bit is that the company has to take the time to actually listen.

Whilst older companies have a reputation for not asking for feedback, it seems to me that the newer technology companies have a bad history of actually listening to feedback that concerns policy. That's distinct from feedback on software bugs, which are effectively win-win for the company and the consumer. Google, for example, is great at releasing its products in beta versions, and fixing them up in response to feedback. However, looking at the upset surrounding its retention of search logs, and it's the opposite. Similarly, Facebook's introduction of its Beacon technology, for publicising what purchases users had made, didn't really go down that well either, though they at least made the service an opt-in feature after about three weeks. (Any other examples?) The point is not that users aren't eventually listened to, but more that they're listened to quickly or completely only when the company considers it to be commercially sensible.

"So what?", you might ask, "Isn't that obvious?" Well, to a company, yes. Pandering to users whilst potentially cutting your revenue or effectiveness doesn't seem commercially sensible. But if consumers now expect this easy-feedback channel to be taken notice of, then when it's not, a revolt occurs. On the web, where the switching costs tend to be lower, customers might just decide to go elsewhere. Even with companies who produce more tangible products (cars, say), users can still make a fuss very publicly, and very quickly. Worse, they'll accuse the company of "not listening". Suddenly the feedback channel isn't so great any more. Particularly since a lot of that feedback is public for all the world to see.

So, as a small company, online feedback can be great for understanding how to shape something new. But it's perhaps important to manage users' expectations. Otherwise you might end up like Face Party, who closed shop for a while after users complained that they hadn't been given what they'd been promised. Moreover, dedicating time to making sure that the online feedback channel is tended to, so that you at least appear (!) as though you're listening will probably pay off.

Welcome to a brave new world, where goodwill is generated by listening, rather than another PR campaign. Oh, and where trying to fake reviews to gain goodwill will probably be discovered.

The E-Myth Applied to Software Startups

In his book "The E-Myth", Michael Gerber asks why most small business don't work, and what to do about it. His main point is that people who go into business on their own tend to do so in order that they won't be working for someone else. Moreover, they tend to be the "worker" or "technician" type (not the manager, or strategist), who is good at creating the widgets/loaves of bread/furniture/other product. So they open a widget workshop/bakery/carpenter's workshop/other place as a one person venture.

So far so good. The new business probably works well, because the owner has enthusiasm and is skilled in what they do. However, the owner spends all of their waking hours attending to the work of producing the product. Gerber gives the example of a pie shop, where pies are baked early in the morning, sold throughout the day, and cleaning is done in the evening, all by the owner. The owner probably neglects areas of the business they don't know much about, such as book keeping. Neither do they get any time off. Crucially, they don't sit down and think where the business is heading (strategy).

Gerber argues that most of these people need to let their inner entrepreneur blossom. They need to own the business, rather than the technical work that goes into product manufacture. They do this by having a vision of the future of the company, and shaping the company to it, rather than shaping the future by what routine dictates. As they grow the company, they need to impart this vision to their new employees, and begin to make that vision a reality by taking on more of a managerial, and less of a technical, role. Part of this, Gerber, argues, involves documenting all the processes (e.g., how to make pies) that go on in the business, in order that the owner no longer has to check up on every step of production done by his/her employees. The result is a business that is easy to franchise.

Whilst this all makes sense for a business that produces something tangible, how can we apply it to software startups? Whilst not having a huge experience in this area, I thought I'd have a go at answering this question.

Firstly here are some of the differences I can see between the two situations:

• The capital cost of writing software is relatively small, unlike the initial investment required to rent a retail unit for a shop, or build a factory. This means that non-software businesses have to go and find funding, which normally means other people will take a look at their business plan before the business is set up. If you're spending life savings then it's different, but if you're writing software you're doing that too (just to keep food on the table)
• One doesn't tend to want to franchise software production. Outsource, possibly, and certainly bring new developers onboard. But the procedures that the startup uses won't be set in stone by the owner: they'll change as the company grows. What revision control system you use, or bug tracking software, or code format only needs to be specified at a later stage than what recipe is used for pies in a bakery.
• The cost of modifying software is very small. The cost of changing every widget that you have in stock because there's a flaw in it is at least linear in the number of widgets, so you'd better get it right first time. With software you can "plan to throw one away" (Fred Brooks; see my post The Mythical Man Month: Still Applicable Today).
• If a software product is intended for mass market, it's likely that its users will not understand how it works, and can't easily reverse engineer it to find out how. This is very different from most tangible products: most people understand vaguely how a pie is made, or have a mental model of how a car accelerates from standstill.
  

(I'm sure there are more: comment and let me know!)

I do think that technical people are as susceptible as any others when it comes to "working in their business rather than on it" (Gerber). But what exacerbates the issue is that software startups don't need initial cash, and hence owners aren't obliged to have anyone looking over their shoulders! Add to that the ease of (radically) changing their product, and suddenly the software startup is one where it's far more acceptable to have no real vision or idea of what you're doing. It's therefore very easy to waste time and then fold.

Software engineers are highly technical. In my experience, many dislike having to explain to a customer how a product works, and would hate to provide a dreaded technical support helpline. Instead, they argue that software can be made good enough that no support is needed, or those that do need support are evidently so lacking in intelligence that they don't deserve it. Yet this is crucial to getting the product sold to a mass market! Customer service is perhaps most needed in this business, and yet the software engineering stereotype is the worst-placed to provide it!

Linked to the previous point is the observation that performing market research is difficult. For a pie shop it's pretty easy: "Do you like apple pie, or would you prefer blackberry?" Software isn't as easily understood by the man on the street: "Would you like to buy my new super-fast sorting algorithm?" doesn't mean much. It requires the software engineer to divorce themselves from the beauty of the technology, and concentrate on its use by potential customers.

Another interesting issue with the low cost of modifying software is the speed at which new technologies (languages, tools, plug-in modules) become available. Unless a lone entrepreneur has a strong vision and will, it is very easy to frequently change to the newest technology, in the belief that this will create a better product. Of course, sometimes it does. But change has a time cost, which is much harder to quantify than the capital cost of buying a new piece of hardware, say.

Finally, as noted above, documentation of processes is far less important (in my opinion) for a software startup than for widget production. Gerber argues that documentation means practically anyone can read the "manual" and then achieve good results. I would argue that software is different in that it requires excellent people, as code quality can only be influenced by procedures to a small extent. In addition to good software engineers, there is a real need for one person with an overall view of what the aim and uses of the product are: they can then ensure that all the developers work in concert towards the vision of the company.

If You Get a Little Better at Sales, You'll Be Way Ahead of the Market

In my dealings with fellow Computer Scientists, I've noticed that many don't see the point of sales and marketing. Instead, they focus on technology. That is not to say that they are all totally unaware of sales/marketing, but if they do see the point, they see it as someone else's task, definitely not one for them to get involved in. In another excellent presentation from the Business of Software 2008 conference, Paul Kenny (of Ocean Learning) talks about how to be a better salesperson. Crucially, he dispels many of the myths that technical people hold about the role, addressing those in startups in particular. Here's the video, with my notes below it.

• If you have a bad opinion of salespeople, it's likely to be because you have experienced the "bad apples", rather than sales being a terrible thing in principle.
  
• Myths
  
• Products "sell themselves". (False, though great products can sell themselves to an extent.)
• Our customers "don't like being sold to". (Actually, they don't like being sold to badly!)
• Techies don't "get" sales people. (Not true! You sell to VCs, to your friends/family supporters, to your first employees.)
  
• How many of the people who, say, view your marketing video, call you for a demonstration? If it's only 5% (likely!) then you need a person to follow up: normally it's not something wrong with the product that stops someone buying it; it's other things getting in the way.
• The people who have the need for your product are probably not the people with the money. You need a salesperson to go and talk to the people higher up, to make them feel the need.
• Talk about specific uses/users, not the science/how the product works. If you can convince your buyer that a user they know personally will benefit from it, that is a powerful sell.
• Users have "needs behind needs". People will tell you that the reason they buy an SUV is because they like the 4WD or stability. In practice they actually like SUVs because they make their families safer when driving, or for the feeling they get when they are able to look down on other drivers.
• Be prepared to go one-to-one with customers to understand their particular situations and what features they will use.
• Sales are very dependent on the emotional impact of your product. You need to position your product in people's minds. Trade-off between perceived cost and perceived value. Note that it's perception that matters, which can be managed by a salesperson.
• If you want a salesperson, don't recruit a stereotype! Start with what you need them to do: fast response (cheap product), or in-depth service (expensive product, high risk for client). They require different skills.
• What is your company culture? Will the salesperson you are recruiting exude that culture? Don't stitch customers up.
  
• Don't worry about admitting that your product isn't suitable for a customer's needs; they will remember you, as you'll probably be the first person who was honest with them in that way.
• Don't hire experience, hire attitude first (then experience!). You can't train attitude into someone. If a candidate hasn't researched your company much at all, or is lax in some things, don't hire them: they will be the same about your customers.
• Skills: self-starting/self-motivated, intelligent in questioning/listening, sounds/looks like they mean it, can deal with resistance, persistent.
• Sales take huge amounts of energy: have a dedicated person, rather than combining with other jobs. If you can, have more than one salesperson to spread the load, and motivate each other.
• If you have no dedicated person, and all of you in the company do some sales, come together and do it at the same time.
  
• Don't just reward deals: that will result in salespeople who don't care about the customer. Instead, reward contact with customers, and show interest in those skills.
• Sales can be boring: how can you vary your salesperson's job, on a regular basis?
• Train your salespeople regularly. They will go off the boil otherwise.
• For high-value salespeople, bonus them over 6-12 months, as such sales take a long time. Low value sales are different, probably bonus over short term.
  

Ultimately, show your salespeople that they are hugely important to you, motivate them, and ensure that they develop relationships with customers.

Why £10,000 Isn't Enough For Good Teachers

The UK government has recently announced a measure to encourage teachers to work in underperforming schools. They will be paid a £10,000 lump sum if they work in one of said schools for three years. "Brilliant," you say, "that means that we'll get good educators where they're most needed!". Well, yes and no.

Firstly, let's note that for 3 years, that's only £3,333 a year, hardly a huge pay rise. If you then note that the (minimum) starting salary for teachers in inner London is £19,827, rising to a minimum of £26,000 in the second year, then you're talking about a salary of around £30,000 for a teacher in their second year in inner London. For a teacher in the Midlands, this works out at about £24,000. (I'm using minimum figures mainly because I don't have any others, but also because I doubt most under-achieving schools are paying radically higher salaries.) Forgive me if I sound doubtful as to whether you'd be encouraged to go and be a teacher at £24,000 (in a difficult school, to boot). The inner London salary sounds more plausible, but then if you worked in the City you might get £50,000 in your second year... Will someone please explain to me how we're encouraging the best to teach?

Secondly, it turns out that government only funds 50% of the £10,000, so schools have to find the other £5,000. Admittedly I'm no expert on how much control schools have over salaries that they offer, but it seems to me that if they had extra £5k cheques lying around, they'd already be using them on salaries? Hence I can't see where the money is magically going to appear from.

Thirdly, what happens after the third year? Do the teachers leave? Are salary increments in the third, fourth, and fifth years going to amount to a total of £3,333 (equal to 12% of 2nd year salary in London, or 16% in the Midlands)? That would mean a rise of 3.8% per year in each of the three years in the Midlands (2.9% in London), which seems unlikely if the government wants public sector pay to rise at 2% per year.

So will it work? I doubt it. Far better to think about how to give teachers a sustained increase in pay, so that they can, for example, afford to live close to the schools they work in. Thomas Friedman has it right when he says that the US should give teachers a tax cut. That has the advantage that it doesn't involve increasing the budget for education, but instead squeezing tax revenue somewhat. If the UK wants to educate its children, that might be a good start.

The Mythical Man Month: Still Applicable Today

I recently read Fred Brooks' "The Mythical Man Month" 20th anniversary edition. It's a collection of essays on software engineering, mostly from a management perspective, on topics such as what sort of teams work well for writing software, what management mistakes tend to be made, and what hope there is for speeding up the process of writing software. Definitely worth a read.

Although most of the essays were written in the 1970s, I came away with some interesting conclusions which are still applicable today. In particular:

• Adding man-power to an already late software project will just make it later (otherwise known as Brooks' Law, this effectively expresses the non-equivalence of men and months).
• Constructing programs for commercial release takes about nine times as long as for private use, because of adding generality, integration, and testing.
• Teams modelled on surgical teams work well. One lead programmer, supported by a subordinate programmer, both of whom know all the code in their module. They are supported by administrative and QA staff. This means that in a team of up to 10 (perhaps fewer now?) only two are really programming, the remainder take care of all the rest.
• Architecting software and implementing software should be separate. This allows the architect to think clearly (and cleverly) about the design, and the implementer to intelligently make that design reality. Both are hugely important and demanding roles.
• Ultimately, there needs to be someone in control for the system to be architecturally sound as a whole: hence there is a tree-like chain of command. However, socially (for communication) relationships should be more of a network, not having to pass through intermediaries in the tree.
• The second system built by a team is likely to be bloated.
• Ensure that architectural decisions are communicated to all the team. This includes telephone/e-mail clarifications made to implementers (use a wiki?)
• Documentation writing for the entire system should be the work of just one or two people, to ensure consistency.
• In a team, the roles of producer and architect are unlikely to both be assigned to a single person. The former is a project manager (finance, schedule), the latter is the technical director.
• Giving teams CPU cycles/memory bytes/bandwidth allocations for their modules avoids overall bloat.
• Flowcharts for software are only useful for the most high-level of view points.
• Plan to throw one interation of software away, i.e. be prepared to construct a pilot, show it to the customer, and then re-write from scratch.
• Technical and management staff should have career ladders that have rungs of equal status (office size, salary, administrative support...)
• Get an outside group (not the developers) to analyse the initial specification for holes.
• Have a schedule with well-defined milestones. This avoids developers deceiving themselves as to whether an ill-defined milestone has been reached.
• Have "scheduled" dates and "completion" dates. The former is what the plan says, the latter is what the developer team's manager says is likely to be date of completion. The boss needs to avoid trying to do the team manager's job by suggesting changes to the implementation in order to change the completion date.
• Documentation needs to give a wide overview, then zoom into the detail.
• No silver bullet: it is unlikely that there will be a significant advance in software engineering that reduces the complexity of the process by an order of magnitude, any time soon.

Brooks evaluates the above 20 years later (1996?), finding that they still hold true. They also sound very relevant to me now!

Does Congestion Have a Cost?

Many of the costs of driving are fixed (see the AA's driving table of driving costs...). However, that doesn't change the fact that they exclude some people from owning/driving a car (as does a congestion charge, i.e. it's not really any more of a social discrimation factor than other motoring costs). As regards whether they influence whether people use their cars or not, if we do want to discourage car use then more of these costs must be made variable, i.e. if one drives less one pays less. Some steps have been made towards this, e.g. pay as you drive insurance (Norwich Union being one example). If road tax were also usage-dependent (as well as on emissions and vehicle weight) this would further encourage people to carefully consider each car journey.

Does congestion itself have a cost? I would say "definitely". Before listing a few example costs, one interesting point to consider is the price people are willing to pay to avoid congestion (which hence puts a value on it). Clearly people do place a value on getting round congestion, as evidenced by people using toll roads (e.g. the M6 toll) instead of alternatives. What costs does congestion have? A few are:

• Longer journey times, which means less time at work, or with family. Either results in lower productivity and hence lower incomes. For some businesses, such as multi-drop deliveries, more congestion means more vans/drivers are needed.
• Air quality is considerably worse with large numbers of cars idling, then continually undergoing stop/start transitions (as in congested cities). Higher levels of pollution cause long term health problems (asthma, probably lung cancer...), which then cost the tax payer via the NHS.
• Journey costs are increased to the driver themselves, as congested conditions will mean less efficient fuel burn, plus extra wear and tear on the vehicle due to continual stop/start behaviour.
• Congestion has been linked to higher incidents of vehicle collisions, which both increases health costs and insurance/repair expenses.

All of these costs have significant values (hence the £12bn/year estimate I gave in the post titled "Road Pricing & Delivery Vehicles"). This is both in costs to individuals and to society as a whole. However, clearly these costs aren't ones that the average driver considers when planning a journey (e.g. every time I go to the shops I don't think about the tiny increase in the probability that I'll get lung cancer). Moreover, such costs are paid for by everyone, regardless of whether they drive. It seems fairer to charge those who are causing such costs accordingly.

Further details of the costs of congestion can be found in section 5.5 of VTPI's "Transportation Cost and Benefit Analysis".

A congestion charge could indeed be used to raise tax revenues. However, there is nothing to stop a government, in principal, committing it to be spent on transport. This has been the case in London, Bergen, and Stockholm. Such revenue hypothecation is one of the characteristics of successful congestion charging schemes (if only the UK government would learn that).

In terms of high fuel duty not affecting congestion, that is correct: it simply increases the costs of driving, regardless of when or where (apart from using more fuel in congested areas). A congestion charge (particularly time-variant) provides an economic disincentive to people from travelling in congested areas at peak times (i.e. causing congestion). Petrol prices do have an effect on how much people use their car, as was seen in the USA recently when prices were particularly high (estimate of 58 billion fewer miles travelled in first seven months of 2008). However, that just penalises everyone wherever, whenever.

Overall a government needs to be clear on whether they want to reduce congestion, which is discouraging people from travelling at certain times in certain places, or to reduce total vehicle miles, which can be achieved by increasing the proportion of the total cost (but not necessarily the total cost!) of running a vehicle that is distance-dependent. Of course, we probably need to do both, (carbon dioxide emissions now being hugely significant will require us to cut down total vehicle miles; congestion costs us all, as described above).

So: does congestion have an economic cost? Yes, definitely. But do people really take that cost into account at the moment? No.

(Cross-posted from the thread on congestion charging over at the Cambridge Network social network.)

Does Road Pricing Force the Poor Off the Roads?

The short answer to this question is "yes".

The long answer is more interesting. I agree that road pricing/congestion charging might price some people out of using the roads at rush hour. But the same could be said of petrol prices, or road tax, or insurance... The key point is that roads are not free to use for any motorised vehicle now. The aim of a charge is to make road users (effectively) pay the economic cost of the congestion they cause: yes, this means that the rich can cruise in more quickly than before. But today the rich can use their private car versus having to use the (cheaper) bus service. The poor have less choice.

If the charge is set correctly, and there is a viable public transport alternative, the (really) less well-off in society end up with a more affordable and efficient public transport service than at present. The issue is that congestion is damaging to a country's/region's economy as a whole, and the only way to reduce that is by reducing the number of vehicles on the road at rush hour (i.e. somehow people are forced to change journey timings or move on to public transport).

Jon Davies makes another interesting observation: if a congestion charging scheme is made revenue neutral (i.e. total revenues raised by government are the same as currently under road taxation), then it might in fact become cheaper for the less well-off to drive at certain times (e.g. midnight). That might mean some people could afford to use the road who cannot at present.

For some facts and figures on cost/benefit of cordon-based road pricing, see the results of the Stockholm trial. The last page details benefits of reduced journey times, cleaner air, etc..

Ultimately, is being able to afford to use a car a "right" or a privilege? If we had good public transport I think I'd regard it as more of a luxury... Thoughts?

(Cross-posted from the thread on congestion charging over at the Cambridge Network social network.)