How do I find cheap freelance hardware and software developers?

The question was, "How do I find cheap freelance hardware and software developers?"

I warned the questioner to be very careful about what he was asking for:

First of all, you don’t want “cheap” developers; you want inexpensive developers.

Second, the expense of developers is not their hourly or daily rate. It’s the total cost of building and delivering the software and hardware you want.

In my experience, the least expensive developers have much higher rates than the more costly ones. The deliver what you want, the first time, in less time, with less trouble.

However, a high hourly rate doesn’t guarantee an inexpensive product. Freelance developers can charge anything they want, so price doesn’t necessarily indicate value.

Instead, speak to references about any developer you’re considering. Find out first hand what you’re going to get for what you’re paying.

And, by the way, don't think you'll save money by hiring individual developers. Your best bet will generally be to choose a team, perhaps an Agile team, but in any case, a team that has a history of working well together.

The Tenth Law of Pricing

The question was, "What can be said on the topic of generating revenue in a solo consulting practice?" You may not think of yourself as a consultant, but if you are an employee, you still have the problem of generating revenue, so this essay applies to you, too.

As a reply, I suggested reading my book, The Secrets of Consulting. The questioner then asked if I could supply a sample, so I provided a little sample from the book. In the chapter on pricing, I give my ten Laws of Pricing—laws that have made numerous consultants rich. I won’t explain them all here (or else I won’t get rich from sdelling my books), but I’ll give a summary along with the section about the tenth law:

FEE AS FEELING: THE TENTH LAW OF PRICING

The previous nine laws may sound overly analytical, but I don't perform this balancing act in any particularly analytical way. I just lay out several prices in a range and than imagine myself in a situation in which I'm turned down and am sitting at home, or the situation in which I've accepted and I'm doing the job. As I imagine myself in each of these situations, I notice my feelings. I find these fantasy feelings a particularly reliable guide to how I'm going to feel in the actual situation. Based on where I feel best on all sides, I set my price.

If the procedure sounds fuzzy, you may want to review the pricing laws:

1. Pricing has many functions, only one of which is the exchange of money.

2. The more they pay you, the more they love you. The less they pay you, the less they respect you.

3. The money is usually the smallest part of the price.

4. Pricing is not a zero-sum game.

5. If you need the money, don't take the job.

6. If they don't like your work, don't take their money.

7. Money is more than price.

8. Price is not a thing; it's a negotiated relationship.

9. Set the price so you won't regret it either way.

If you examine these laws, you'll realize that they don't talk about rationality, but emotionality. In other words, underlying all the other laws of pricing is The Tenth Law:

All prices are ultimately based on feelings, both yours and theirs.

It's important to note other feelings, such as how strongly the clients feel their need, and what they feel they can pay. It's especially important to understand what they feel you're worth. But most important is what *you* feel you're worth.

Oscar Wilde once said that people know the price of everything and the value of nothing. Since Wilde's time, however, things have gone downhill. Now people don't even know their own price. Not consultants, anyway. There may be some consultants in the world who never wonder whether they've set the right price on their heads, but I've never met any. I've concluded that, in the case of consultants, Wilde was wrong. Consultants have so much trouble talking about prices because they know their value only too well. Or, they secretly fear that they know.

So, if you're having problems setting a price on your head, take a good look at your deep feelings of self-worth. You're probably not worth as much as you hoped. On the other hand, you're probably worth a lot more than you feared.

How Can A Developer Earn More Money?

The question on Quora was, "What is the best career advice for a software developer to earn a higher salary?

There were many logical answers, but in my experience the best way to earn a higher salary is to go to work for a badly managed company with lots of legacy code that they can’t get anyone to maintain. 

The managers of such an organization are usually desperate for a way out of the mess they've put themselves in, but being bad managers, the only idea they have about getting out is to buy their way out. They think that if they pay ridiculously high salaries, they can induce some foolish programmers to come and bail them out.

So, if maximum money is your only concern, find a company like this and work there until you can't stand it any longer, then take your money, leave, and find some other badly managed company.

Don't stay too long. The company may go bankrupt and not pay what they owe you. Warning sign: when they tell you your paycheck will be delayed, leave immediately.

If you want to know how to recognize badly managed companies, take a look at my 

Quality Software Series.

Eventually, you may grow tired of this strategy and decide there are more things in life than maximum money. When that time comes, quit and look for a well-managed company, following some of the good advice in the other answers to this question on Quora.

The Write Stuff 2016 Bundle

Curated by Kristine Kathryn Rusch

Hundreds of writing books get published every year, and most of those books are written by people who have written…a book on writing. I kid you not. These people have a method or a scheme or they teach a writing class—even though I have no idea how they get those gigs. (Okay, I do. They get an MFA, which universities seem to think is more important than actual writing experience.)
Those writing books have nothing in common with the writing books in this bundle. Together, the authors of the books in The Write Stuff 2016 Bundle have more than two-hundred years of writing experience, and have contributed more than five hundred award-winning and bestselling books (fiction and nonfiction) to the world of literature.
We know writing, the writing life, and what makes a writing career. And we want to share it all with you.
Even though the books in this bundle discuss craft, including one of the classic writing books of all time, most of the books you'll find here explore the career killers, things like how to put butt in chair on a regular basis, how to organize your business career, and the all-important (at least to me) how to make a living as a writer.
So if you are a writer, or are simply dreaming of becoming a writer, this bundle is for you. – Kristine Kathryn Rusch
The initial titles in the Write Stuff 2016 Bundle (minimum $5 to purchase) are:

• Weinberg on Writing - The Fieldstone Method by Gerald M. Weinberg
• How to Negotiate Anything - Freelancer's Survivor Guide by Kristine Kathryn Rusch
• Stages of a Fiction Writer by Dean Wesley Smith
• Business For Breakfast Vol 2.: The Beginning Professional Publisher by Leah Cutter
• The Rational Writer: Nuts and Bolts by Mindy Klasky

If you pay more than the bonus price of just $15, you get all five of the regular titles, plus five more:

• Creating an Online Presence for Writers by Cat Rambo
• How to Make a Living With Your Writing by Joanna Penn
• Heinlein's Rules - Five Simple Business Rules For Writing by Dean Wesley Smith
• Writing the Novel from Plot to Print to Pixel by Lawrence Block
• The Writer's Business Plan: A Plain English Guidebook by Tonya D. Price, MBA

The bundle is available for a very limited time only, via http://www.storybundle.com. It allows easy reading on computers, smartphones, and tablets as well as Kindle and other ereaders via file transfer, email, and other methods. You get multiple DRM-free formats (.epub and .mobi) for all books!
Read more.

My Earliest Computers

My father gave me a slide rule when I was about 7 years old. I used it to compute baseball batting averages, which was what motivated me at that time in my life. I still have that slide rule. It's a small, cheap slide rule, made from bamboo with plastic (or maybe ivory) faces. He bought them in quantity to give to the young ladies who computed customer bills for Sears, when my father worked for 20+ years, improving processes. The slide rules were used to check their multiplications, preventing enormous numbers of errors that had previously been sent to customers.

The next interactions were with tables of sines, cosines, and logarithms, used for more precise calculations, mostly in math classes and personal experimenting with numbers for fun.

At age 11, still in Chicago, I read a magazine article about computers, then familiarly known as "giant brains." By this time, I had been label as s "brainy" kid, and I longed to learn more about brains. I determined that computers were what I wanted to do with my life—and they turned out to be. I didn't know anyone who had ever seen a computer, let alone used one.

I watched and waited for signs of a computer, but went all through high school without seeing one.  Well, not exactly. I had a summer night  job in a large bakery computing recipe requirements for the following day's orders. I used a Monroe adding machine.

When I entered college at 16, I told the counselors I wanted to work with computers, but none of them knew anything about computers other than they had something to do with electrical engineering and physics. They decided I should major in Physics, because I was good in math, which would be "wasted in EE." One day, I saw a notice for a "computing course" using Monroe adding machines, given by the Monroe company. I was a short course, and I already knew most the material better than the instructor. But I passed, earning a certificate that I've lost somewhere along the way. It's the only computing course I ever took, and the only "degree" in computing that I ever earned.

My next encounter with a computer was when I looked in the mirror. I got a job in the Physics department as a "computer"—that was my job title. I was shown a Friden electromechanical calculator, which I used along with pencil and paper (and eraser) to invert 10 by 10 matrices for faculty members.

I graduated with honors in Physics, Math, Philosophy, and English, then went to Berkeley to study graduate Physics. I was perhaps two months from a doctorate in Physics (exams passed, thesis experiments finished and waiting to be written up), but I read an IBM ad in Physics Today looking for problem solvers. The ad described the work I had dreamed of since age 11, so I wrote to IBM and was hired as an Applied Science Representative—on June 1, 1956.

I was given no training, but my first assignment was to teach a programming course to three other new Applied Science Representatives who were to join IBM in San Francisco two weeks later. (I had a wife and 1.66 kids by then, so I needed the two-weeks pay, so I started early.)  The first machine I encountered was an IBM 607, which was a wired program machine with 20 wired program steps (this was the expanded version) and one signed ten-digit number of data storage. In my first week, using the library of manuals, I mastered that machine plus a bunch of older punched-card machines.

I spent the next week learning to program the IBM 650, a stored program machine that kept programs and data on a magnetic drum, but had wired control panels for input and output formatting. This was all theoretical, as there was no IBM 650 anywhere in San Francisco yet. When one finally arrived shortly thereafter, it was the first stored program machine I had ever seen.

While waiting for the 650's arrival, I earned a reputation as a "whiz kid" (the term "programmer" wasn't yet in use) by making the 607 do tricks. My most impressive trick was turning on all the lights on the 607 control panel, which won me a dollar bet.

When the 650 arrived, I immediately tried out a program I had written to compute tables of sines, cosines, and logarithms. With the arrival of computers, such tables were now totally useless, but I was in nerd-heaven. I was being paid $450 a month for playing with the world's greatest toy, a job I would gladly have paid $450 a month to do—though I wisely didn't tell IBM that.

Downgraded to Testing

Here's a letter I got from a friend overseas. I've altered any identifying information, for obvious reasons. I'm going to intersperse some comments as if I were conversing with Nicolai face-to-face.

Nicolai's Letter
One thing I still like to know from you about "Perfect Software and Other Illusions About Testing". Are there metrics or measurement criterias with which you can measure the success of Testing in the software development life cycle (SDLC)?

I am in a struggle with my employer to change my position from a system developer (am working for the auto parts industry / manufacturing planning and execution) into a software tester. I made that decision after I recognized that this job much more fits to my personality type than doing the implementation.

Jerry
That recognition is an excellent starting point for solving your problems. Many people don't really know consciously what they really would like to do.

Nicolai
But let me come back to my main concern nowadays. My problem now is that in my country and especially in my company, this issue of Testing is new. My boss's understanding of it is low and hence he wants to reduce my salary around 10%.

Jerry
Sorry, that's not why he wants to reduce your salary. That's his excuse for taking advantage of your wish to change jobs. He simply sees an opportunity to save some money at your expense. Yes, if he understood anything about testing, he should raise your salary by 10%—or more.

Nicolai
That's in contrast with the huge losses we have because of NOT using Testing at all in our processes.

Jerry
Oh, my. Your company is at Level 0 when it comes to Testing. Oblivious! That is definitely not the place to be if you wish to make a career, long or short-term, in Testing.

Nicolai
Anyway I will not stay long there anymore.

Jerry
That's the wisest thing you've said so far.

Nicolai
I will try to setup my own company (industrial import export trading consultancy).

Jerry
That's an ambitious goal, and probably long-term. You cannot afford to stay any longer in this unbelievably bad company with this even more unbelievable manager.

Nicolai
But in the meantime I have to feed my family and I need an advice from how I can measure the success of Testing. Based on such criteria, I can improve my salary negotiation and make Testing much more tangible to everyone even myself. Once I have the criteria or indicators, I can make a some percent part of my salary depending on the success of implementing Testing into the SDLC. I think that is fair enough.

Jerry
Your boss has demonstrated he has no interest in "fair enough." And no interest in your career or your family. Your approach is all wrong. You should first find yourself a job in an organization that already values Testing, at least slightly.

In my experience, an organization like yours is never (at least in your working lifetime) going to value testing enough to value you, or pay you what you're worth to them. Nor will it be a good place to learn the profession. All you will learn is what I'm telling you now: that is, you shouldn't stay in this job a moment longer than you must in order to see that your family is fed. (For example, if your wife works, see if you can simplify your finances so you can live on her income, at least for a short time.)

But, in any case, you should immediately begin searching for a new job, in a much more compatible place. (And do it without letting anybody know. The kind of boss you have will not react well to news that you're seeking a new position. Let him know when you're saying goodbye, when you've already been hired by the new place.

Nicolai
What would be such indicators of a successful integration of Testing into the software development life cycle (SDLC)? I know you use the FFR, but this says something about the quality of the software development team. What would be indicators that say something about the quality of the software test team?

Any hints from you are very welcome.

Jerry
What you need now is one or more ways to put a cost on the software errors that are already reaching your users. (For example, you can use methods described in Quality Software series of eBooks—particularly Volumes 3 and 4: How to Observe Software Systems and Responding to Significant Software Events.)

Use these methods to arrive at average and extreme costs of each software bug that leaves your development group. And a count of how many bugs you ship with how much software. Then you can produce a report that says, "If our Testing is X% efficient at finding bugs, and if our developers are Y% efficient at fixing them before release, then we can expect to save Z-dollars by having a Testing group."

If you really do no Testing now in your SDLC, you can expect Z to be a very large amount. (And if it's not a very large amount, then Testing is really not important there, and you shouldn't be working there.)

Even if you're already in a Testing group, you should make such measurements, so you can get the support you need. And be appreciated.

I hope this helps.

References

Responding to Significant Software Events

How to Observe Software Systems

"Smashwords vs. Kindle?" Are Your Lights On?

Yesterday, Don Gause and I posted out book on problem definition, Are Your Lights On?—a book many have called a "classic."

Today, I ran across a perfect example of why the lessons in the book are so useful. On one of the writers' forums in which I participate, a reader posted a query entitled Smashwords vs. Kindle? Here it is:



Gemma, a writer, asks:

Can someone tell me what the benefits or advantages of publishing on Smashwords might be when Amazon, the number five most visited site in the USA, (according to Alexa.com) provides such a successful solution and so much higher traffic? To compare, Smashwords ranks 2,751 in terms of daily traffic. Amazon's "query popularity" is 86 out of 100, versus only 38 out of 100 for Smashwords. Amazon visitors spend an average of eight minutes on the site and view 8.8 pages while Smashwords visitors spend six minutes on the site and view 6 pages.

Still, I have found the folks on this list to be a savvy bunch, so I suspect there must be some hidden advantages or benefits of which I am unaware. Can anyone who has published on Smashwords help me out by sharing some benefits? I am about ready to put up some titles on Amazon and had decided to stick exclusively to that platform and to B & N, but maybe I am cutting off potential sales by not posting on Smashwords.

Perhaps someone else has the answer already:

One of the things Are Your Lights On? teaches is to use all the information you have. In this case, I had an earlier answer from another author, "Linda."

Linda offered this answer:

Yes, Amazon offers worldwide traffic, but Smashwords offers retail eBook outlets that we do not get at Amazon.  My books are directly at Amazon Kindle.  And then I have also added a number of my books and my husband's at Smashwords to take advantage of the retail outlets they distribute to.  At Smashwords I opt out of Amazon, and will continue to do so.  But Smashwords has not only their direct website, but the books are sent to the ebook retailers-- Kobo, Nook, Diesel, IPad, etc.  I love being able to check daily on my Kindle sales and be paid monthly by Kindle.  Royalty payments and sales via the Smashword's distributors are slower, depending on the retailer.

So the advantage is having more retail distribution (and hopefully sales) by putting your books at Smashwords, in addition to having them at Amazon Kindle.

Even good answers may not be complete.

Are Your Lights On? teaches:

"If you can't think of at least three things that might be wrong with your understanding of the problem, you don't understand the problem."

Well, I really liked Linda's answer, but applying the Rule of Three, thought about how it could be improved.


Jerry adds to Linda's answer:


First of all, listen to Linda. She and her husband use exactly the same strategy Dani and I use. [Note from AYLO: Answers don't just have to be right, they have to be convincing. Supporting Linda's excellent answer is the first job a consultant has to do to be effective in this case.]

So, my first answer to Gemma is this: You've done your research, and done it well, but the data you've gotten happens to be irrelevant to this problem. The traffic each site receives doesn't really matter. What matters is selling books. Suppose Site A receives 1000 hits/day, and the average stay is 10 clicks, and they sell one book per day. Site B receives 10 hits per day, and the average stay is 1 click, and they sell two books per day. Which is better for you, the writer, A or B?
The answer is "none of the above." Why, because you don't have to choose. You can put your book on both A and B's sites, and sell three books.

On to the details:

Once you have the right problem definition, the solution is often trivial, as above. Since I can't verify my assumptions about Gemma's problem definition, I can add some other facts to support various definitions, such as,

1. A book sold at Smashwords gets a higher royalty than the same book sold at Kindle. For each $7 of Kindle royalty, the same sales on Smashwords earn $8.

2. Smashwords, as Linda says, distributes to many retail outlets that would be a pain to reach individually, and perhaps not worth the small sales they generate. Through SW, I reach them with zero extra effort.

3. In addition to extra retailers, I reach readers who don't use Kindle. As Linda says, SW formats automatically for just about every eReader known to humanity, again, at zero extra effort.

4. I don't know how many SW sales I would have through Amazon if SW weren't available, but I do know that through SW, I earn about 2/3 of what I earn through Kindle, so instead of, say, $1,000 through Kindle, I earn about $1,666 through the combined offering. (plus another $100 or so through Barnes and Noble, which you should also use.)

5. SW has a "coupon" feature that Amazon doesn't offer. That allows me to offer special price deals for a day, a week, a month, or whatever period of time I wish, for whatever price I wish. Very useful for marketing, and for reviewers. On Kindle/Amazon, a price change takes about three days to start, and three days to remove, and is seen by the whole world. On SW, the change takes place instantly, and can be removed instantly. I can offer it to one person, or 10, or 100, or to the entire internet world. My choice.

6. And, if you offer a book on SW, you can pull the book(s) any time you want. So, if it turns out you don't like something about SW, you're out of the deal instantly, whenever you want--not cost, no fuss. It's totally under your control.


Bottom Line

Yes, the book-selling business can be complicated, but this one's probably a no-brainer when you have all the facts—if I have the right problem definition. In a real consulting situation, I'd be able to talk with Gemma and verify that I understand her problem. Since I don't have access to her, I'm guessing that her implicit problem definition is wrong from the start.

Gemma, I think it's not "Smashwords vs. Kindle," but "Smashwords and Kindle" (and Barnes and Noble, and any other sites you wish, as long as they don't restrict your publishing elsewhere).

Perhaps the definition would have been better stated: "How can I achieve the best sales results for my eBook?"

P.S.

You can sample Jerry's books on Smashwords, including Are Your Lights On?, then buy them there or at any other site you might prefer. See and sample all my books on Smashwords (more going up all the time).

The Universal Pattern of Huge Software Losses

What Do Failures Cost?
Some perfectionists in software engineering are overly preoccupied with failure, and most others don't rationally analyze the value they place on failure-free operation. Nonetheless, when we do measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software. In Responding to Significant Software Events, I give five examples that should convince you.

The national bank of Country X issued loans to all the banks in the country. A tiny error in the interest rate calculation added up to more than a billion dollars that the national bank could never recover.

A utility company was changing its billing algorithm to accommodate rate changes (a utility company euphemism for "rate increases"). All this involved was updating a few numerical constants in the existing billing program. A slight error in one constant was multiplied by millions of customers, adding up to X dollars that the utility could never recover. The reason I say "X dollars" is that I've heard this story from four different clients, with different values of X. Estimated losses ranged from a low of $42 million to a high of $1.1 billion. Given that this happened four times to my clients, and given how few public utilities are clients of mine, I'm sure it's actually happened many more times.

I know of the next case through the public press, so I can tell you that it's about the New York State Lottery. The New York State legislature authorized a special lottery to raise extra money for some worthy purpose. As this special lottery was a variant of the regular lottery, the program to print the lottery tickets had to be modified. Fortunately, all this involved was changing one digit in the existing program. A tiny error caused duplicate tickets to be printed, and public confidence in the lottery plunged with a total loss of revenue estimated between $44 million and $55 million.

I know the next story from the outside, as a customer of a large brokerage firm:
One month, a spurious line of $100,000.00 was printed on the summary portion of 1,500,000 accounts, and nobody knew why it was there. The total cost of this failure was at least $2,000,000, and the failure resulted from one of the simplest known errors in COBOL coding: failing to clear a blank line in a printing area.

I know this story, too, from the outside, as a customer of a mail-order company, and also from the inside, as their consultant. One month, a new service phone number for customer inquiries was printed on each bill. Unfortunately, the phone number had one digit incorrect, producing the number of a local doctor instead of the mail-order company. The doctor's phone was continuously busy for a week until he could get it disconnected. Many patients suffered, though I don't know if anyone died as a result of not being able to reach the doctor. The total cost of this failure would have been hard to calculate except for the fact that the doctor sued the mail-order company and won a large settlement.

The Pattern of Large Failures
Every such case that I have investigated follows a universal pattern:

1. There is an existing system in operation, and it is considered reliable and crucial to the operation.

2. A quick change to the system is desired, usually from very high in the organization.

3. The change is labeled "trivial."

4. Nobody notices that statement 3 is a statement about the difficulty of making the change, not the consequences of making it, or of making it wrong.

5. The change is made without any of the usual software engineering safeguards, however minimal, that the organization has in place.

6. The change is put directly into the normal operations.

7. The individual effect of the change is small, so that nobody notices immediately.

8. This small effect is multiplied by many uses, producing a large consequence.

Whenever I have been able to trace management action subsequent to the loss, I have found that the universal pattern continues. After the failure is spotted:

9. Management's first reaction is to minimize its magnitude, so the consequences are continued for somewhat longer than necessary.

10. When the magnitude of the loss becomes undeniable, the programmer who actually touched the code is fired—for having done exactly what the supervisor said.

11. The supervisor is demoted to programmer, perhaps because of a demonstrated understanding of the technical aspects of the job. [not]

12. The manager who assigned the work to the supervisor is slipped sideways into a staff position, presumably to work on software engineering practices.

13. Higher managers are left untouched. After all, what could they have done?

The First Rule of Failure Prevention
Once you understand the Universal Pattern of Huge Losses, you know what to do whenever you hear someone say things like:

• "This is a trivial change."

• "What can possibly go wrong?"

• "This won't change anything."

When you hear someone express the idea that something is too small to be worth observing, always take a look. That's the First Rule of Failure Prevention:

Nothing is too small to be unworthy of observing.

It doesn't have to be that way
Disaster stories always make good news, but as observations, they distort reality. If we consider only software engineering disasters, we omit all those organizations that are managing effectively. But good management is so boring! Nothing ever happens worth putting in the paper. Or almost nothing. Fortunately, we occasionally get a heart-warming story such as Financial World telling about Charles T. Fisher III of NBD Corporation, one of their award-winning CEO's for the Eighties:

"When Comerica's computers began spewing out erroneous statements to its customers, Fisher introduced Guaranteed Performance Checking, promising $10 for any error in an NBD customer's monthly statement. Within two months, NBD claimed 15,000 new customers and more than $32 million in new accounts."

What the story doesn't tell is what happened inside the Information Systems department when they realized that their CEO, Charles T. Fisher III, had put a value on their work. I wasn't present, but I could guess the effect of knowing each prevented failure was worth $10 cash.

The Second Rule of Failure Prevention
One moral of the NBD story is that those other organizations do not know how to assign meaning to their losses, even when they finally observed them. It's as if they went to school, paid a large tuition, and failed to learn the one important lesson—the First Principle of Financial Management, which is also the Second Rule of Failure Prevention:

A loss of X dollars is always the responsibility of an executive whose financial responsibility exceeds X dollars.

Will these other firms ever realize that exposure to a potential billion dollar loss has to be the responsibility of their highest ranking officer? A programmer who is not even authorized to make a long distance phone call can never be responsible for a loss of a billion dollars. Because of the potential for billion dollar losses, reliable performance of the firm's information systems is a CEO level responsibility.

Of course I don't expect Charles T. Fisher III or any other CEO to touch even one digit of a COBOL program. But I do expect that when the CEOs realize the value of trouble-free operation, they'll take the right CEO-action. Once this happens, this message will then trickle down to the levels that can do something about it—along with the resources to do something about it.

Learning from others
Another moral of all these stories is that by the time you observe failures, it's much later than you think. Hopefully, your CEO will read about your exposure in these case studies, not in a disaster report from your office. Better to find ways of preventing failures before they get out of the office.

Here's a question to test your software engineering knowledge:
What is the earliest, cheapest, easiest, and most practical way to detect failures?

And here's the answer that you may not have been expecting:

The earliest, cheapest, easiest, and most practical way to detect failures is in the other guy's organization.

Over my half-century in the information systems business, there have been many unsolved mysteries. For instance, why don't we do what we know how to do? Or, why don't we learn from our mistakes? But the one mystery that beats all the others is why don't we learn from the mistakes of others?

Cases such as those cited above are in the news every week, with strong impact on the general public's attitudes about computers. But they seem to have no impact at all on the attitudes of software engineering professionals. Is it because they are such enormous losses that the only safe psychological reaction is, "It can't happen here (because if it did, I would lose my job, and I can't afford to lose my job, therefore I won't think about it)"?

(Adapted from Responding to Significant Software Events )
http://www.smashwords.com/books/view/35783

A Code of Work Rules for Consultants

I frequently meet a consultant who is deeply troubled by the implications of the work of a consultant. What we do today may affect the lives of thousands or millions of people for many years to come.

Moreover, most of those people we affect won't have any way to relate a discomfort in their lives to what we are doing today.

They will, perhaps, sheepishly accept the explanation, "That's the way the computer must do it," or the even more insidious, "that's the way things are."

Some consultants I know, particularly those working in shops where nobody ever looks at anybody else's work, salve their conscience by sabotaging their client's information systems.

In many cases, it's difficult to tell whether this is intentional or unintentional. In other cases, there is no doubt.

Many programmers, analysts, and consultants have complained to me that their work holds no meaning for them. They don't know what is being done with the piece of design or specification they work on, or they know and don't approve.
Their response is to stay on the assignment, draw their fee, and badmouth their client at every safe opportunity.

I think it's time we stood up to be counted. We have an enormous responsibility to the people whose lives will be impacted by the organizations we work for.
If we don't believe in what our client is doing, or we don't understand it, then why are we working there? To draw a fat fee? Then what does that make us?

For some years now, I've been giving a set of principles to consultants who are seeking a new assignment, or are considering changing their present assignment because of such doubts.

In recent years, as the job market shrinks, the number of such doubters seems to be increasing so I thought that many professionals would like to see these principles written down:

1. I will not work for an organization whose goals are not consonant with my beliefs.

2. I will not work on projects whose goals I do not understand, or cannot agree with.

3. Before becoming part of a project, I must first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.

4. I will not work under measurement schemes that pit one person's performance against another's. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.

5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.

6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.

7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

Over the years, I've found that people who ask these questions and set those conditions don't wind up in jobs that make them miserable. Sometimes, when they ask them honestly they leave their present position for something else that makes them happier, even at a lower fee scale.

Sometimes, a client manager is outraged at one of these conditions, which is a sure indication of trouble later, if not sooner.

Many of us lost souls need some guidance, and it might have been easier to have a set of principles when the job market wasn't so tight. But over the years, I've learned that consultants following these principles are more successful at landing good contracts–ones that make them richer and, more important, happier.

Why Do You Charge So Much?

Randolph's Tough Question

Randolph is one of the sharpest technical consultants in my network. Until yesterday, I'd have bet a hundred bucks that no client could stump him with a question - but I'd have lost.

When Randolph called for a bit of meta-consulting, he was so nonplussed I had to spend three whole minutes in idle chitchat, which wasn't Randolph's usual no-nonsense style. Finally, I couldn't stand the suspense, and I asked, "What's the matter, Randolph?" (Nobody calls him "Randy" more than once. It's Randolph all the way.)

"Why do you charge so much?" He blurted so quickly I didn't believe I'd heard him.

"Say what?"

"Why do you charge so much? That's what he asked me!"

"Who asked you?"

"My client. The new one."

"So what did you tell him?"

Pause. Sigh. Longer Pause.

"Randolph? Are you still there?"

Pause. Finally a weak voice said, "I didn't know what to tell him. That's the problem."

I recognized the problem and tried to reassure him. "Randolph, you're not the first consultant who's been stumped by that question. And you won't be the last."

"But I've got to go back there tomorrow, and I don't have an answer. I need help."

Turning the Question Around

Well, yes, Randolph did need help, and perhaps you do, too. Do you hesitate and stammer when your client asks this dreaded question? Are you ashamed to explain to your employee friends who make one-third of your hourly rate? Do you feel guilty that you make so much more than your spouse, who works much harder than you? And how do you handle yourself when the IRS asks you the same question? Well, I'm your meta-consultant, and unlike your IRS agent, I'm really here to help you.

First of all, I'm going to advise you to meet this question head-on by turning it around. Instead of emphasizing how much you're getting, emphasize how much they're getting. Many clients are unclear as to just what they get in return for your fee. This is not surprising, as your fee covers a wide range of intangibles. That's why you need to break out the various components, which I've done in simple ABC format so you can remember next time you're put to the question:

A. Attention. I suspect my clients would be astonished to discover how much time I spend thinking about them and their problems when I'm not "at work." I might be hiking in the woods, or reading a magazine, or taking a shower, and a thought comes to me about something that will help my client. For example, I was driving back from Los Alamos last week and suddenly realized that I'd spent the whole distance from Jemez Springs to Corrales working out a transition plan for a client in Ohio. I could have been enjoying the enchanting scenery - and perhaps I was. But most of my conscious mind was in Cleveland, developing the plan. Supper had to wait until I had the details in my Mac.

And that's just conscious attention. I don't know about you, but I often dream about my clients' problems, often awakening in the middle of the night with solution ideas. This happens so frequently, I keep paper and pencil handy on my headboard, where I've mounted a high-intensity lamp that won't awaken Dani when I'm scribbling away at three in the morning.

B. Barring Competition. While working with one client, I won't work with a client who competes directly with them in the area I'm working. This exclusivity sometimes reduces my opportunities for paying work, but clients may take this service for granted if I don't point it out to them.

C. Celebrity. As my reputation has grown, I've noticed that my clients are quite willing to use it to sell their product or programs within or without the company. They may not be aware that this use of my reputation creates a risk for me. If they make a mess, some of the dirt rubs off on me.

Ah, I've now run through ABC, but there are more items in this alphabet.

D. Dexterity. My clients unconsciously expect me to be on call, not only for the planned activity, but also for unexpected emergency jobs, incidental questions, idle speculation, and all sorts of administrative work such as rescheduling at their convenience. Moreover, unlike their employees, I get neither sick days nor vacation days. When I say I'll be there- and sometimes when I haven't said - I'm there. Even when I'm not there, I've implicitly or explicitly restricted my other activities so I'll be able to respond to their needs in a reasonable time.

Moreover, although I don't get sick leave, and I don't participate in their health benefits, I'm often expected to work under pressure, at odd hours, in inaccessible locations - all the while operating at top efficiency.

E. Education. Speaking of top efficiency, my clients don't pay directly for all the education I bring to the job - not just my formal education, but, for example, the thousands of hours I spend reading in related fields. I figure that in a typical year, I read the equivalent of two books a week, perhaps more. Very few of their employees devote this kind of personal time to their own development. And, when they take a seminar or attend a conference, their employer pays for them - but not for me. (Well, sometimes they do, if it's directly related to their problem and nobody else's.)

F. Flexibility. My clients can release me in a minute if they no longer need my services. Even in these days of downsizing, they don't have this cheap kind of flexibility with their employees.

G. Gratuity. Although I may charge clients for out-of-pocket costs, such as transportation and hotel rooms, I don't charge for meals, supplies, reasonable phone calls, faxes, mailing, and so forth. All these gratuitous expenses save paperwork for my clients, and they're lumped in with my other overhead - my own office space, utility bills, computers, software, network services, professional services, and the like.

H. Honesty. The work I do for my clients can sometimes literally mean the life or death of a project or campaign. This is a grave responsibility, and I accept it fully and do whatever is necessary to give full value. And, unlike an employee, I offer my clients a money-back guarantee of satisfaction with my work.

I. In-house Labor. Nowadays, most consultants/contractors are paid by the hour, or sometimes the day or week. This method of payment tends to emphasize a single tangible component of what my client is getting - my face time toiling on their premises. If they look at me as simply another grunt, grinding away in their office, no wonder it's hard for my clients to understand why my apparent rate is larger than that of their typical employee. They're missing all the other letters of the alphabet.

ZZZZZ. Sleep. Of course, I do have to sleep once in a while - and, unlike some of their employees, I'm not charging them for this. Even when I dream about them.


So there you have it, my Abecedarian cheat sheet that will prevent both you and Randolph from ever again being stumped by a client's question.

50 more ways to improve your business

Wolfram Arnold writes:
Here are the points I've transcribed from the meeting today. At some point I lost count as to which one was odd and which one was even and I just recorded them all (touch-typing helped :-):

---------------------
Jerry Weinberg 8/20, 50 things to improve business

2. back up everything

4. Rule: do nothing, revised with 3 caveats: a) don't do it if there's someone that can do it better; b) don't do it if there's someone that can do it adequately; c) if it makes me really happy, do it anyway; d) if someone can do it 85% as well as I do, let them do it; e) anything not worth doing is not worth doing right; f) if in doubt charge for sales trips

6. make them pay something, with their time, their money -- if they don't pay for it they don't value it

8. if it's not on paper, don't do it

9. listen to what other people are telling you

10. don't communicate to somebody, but communicate with somebody

11. always have an exit strategy

12. make them feel like your client has a part in the final outcome; make sure they have their fingerprints on it

13. listen for what they're not saying

14. listen to the "music", body language, intonation

15. always be ready to sell your product

16. if you find yourself reluctant to sell your product, there's something wrong with it

17. any successful services company has some fixed priced product to sell

18. given them entry points that they can buy

19. recurring revenue model, e.g. via contract maintenance plans, or follow-through

20. have a follow-through clause in contract so you can know how you're doing

21. charge more money if they don't want you to come back after some time, e.g. 3 months

22. if you just build it they probably won't come

23. manage expectations, book: Managing Expectations, by Naomi Karten

24. Time spent in reconnaissance is time well spent

25. You can observe a whole lot just by watching (Yogi Berra)

26. Go hard or go home; fully commit all resources needed, or kill it mercilessly

27. Commit enough to learn what you have to learn to find out whether it's worth pursuing or killing

28. People who work in an Agile/iterative way often fail to do the discovery

29. Ideas by themselves aren't as valuable as you think they are; don't guard them too closely

30. Nothing is as dangerous as an idea, esp. if it's the only idea you have

31. Never rest on your past successes; there is always something more you could be doing; if you're not learning, you're dead

32. Sharing competitive advantages brings 10-fold rewards; give it away, it comes back

33. Being able to say 'no'

34. Research clients as if you were hiring them

35. Recognize that every client is unique.

36. You don't have to remember everything to succeed.

37. It's ok to let a client go if it's not the right fit; you should organize your business such that it's ok to let a client go, i.e. don't be over-dependent on any single client

38. The best way to build a business is to stay in business; stay around, build a reputation and credibility

39. Actively solicit feedback from clients; actively extract the feedback, e.g. watch the audience

40. Don't be alone in your work; have someone to talk to

41. Honor the people who are your sounding board and bring feedback, e.g. life partners, friends, ...

42. Anything that's annoying or repetitive should be automated or stopped

43. Track your budget & cost every month

44. Don't make mistakes over your budget or your cost.

45. Don't spend your money on office decoration, esp. if your clients don't come to your office

46. Always try someone out before you hire them

47. Don't fall for the big lies: "we're just about to get funding" "our data is clean" "your check is in the mail" "we're going to sign it next month, just keep working" "don't worry about the contract" ...

48. Preventing any one of these mistakes will pay for this conference

49. Double your reading speed

50. Choose not to read a lot; don't read stuff that's not worth reading

51. Stay off Facebook & Twitter

52. Sometimes you can save money by spending money; and sometimes the reverse. Learn to tell the difference

- Thanks for the great job, Wolfram

50 Ways to Improve Your Business

At last week's BizConf, I ran a session based on an idea from Dwayne Phillips, where a bunch of independent businesspeople brainstormed 50 small ways to improve your business. The ideas flew fast and furious, so I assigned two participants, each to capture alternate ideas. Even so, it was hard to keep up with the flow. The lists were quite overwhelming, so I'll present them in two separate blogs. Today, it will be Jason Seifer's list. Jason said, "I wound up just logging everything, because I touch type like in your first rule."

So, here's Jason's list:

1. Learn to touch type.
2. Back-up everything. Every day.
3. Keep as much stuff online as possible.
4. Do nothing. Don't do something if someone can do it better. Don't do it if someone else can do it adequately. Do it anyway if it makes you happy. Don't do it if someone else can do it 85% as well as you.
5. Anything not worth doing is not worth doing right.
6. If in doubt charge for sales trips. If they're not willing to pay for it they don't value it.
7. If it's not on paper don't do it. If there's money involved it has to be written down. Never agree to money over the phone. If on phone, confirm in writing.
8. Listen to what other people are telling you. Instead of communicating to somebody, communicate with somebody.
9. Always have an exit strategy.
10. Make your client feel like they have a final part in the outcome. Make sure they have their fingerprints in it.
11. Listen to what they're not saying. Listen to body language and tone of voice.
12. Always be ready to sell your product if they're interested. And if they're not.
13. If you're bashful about your product, there's something wrong with your product.
14. Any successful services company has some fixed product that they sell. Have a ladder leading to your ultimate product. Don't make one big leap to the final product.
15. Make sure your contracts have some kind of follow-through so you can see how they actually came out. You won't know if you're doing well if they don't come back.
16. If you just build it they probably won't come. Alternately: if you build it be prepared to wait.
17. Manage expectations.
18. Time spent in recon is time well spent. But you have to be watching. "You can observe a whole lot just by watching."
19. Go hard or go home. Fully commit the resources to make something work or mercilessly kill it. You may not always know when it's time to kill it.
20. Ideas by themselves are not as valuable as you think they are. Ideas aren't worth anything so don't guard them too closely. "There's nothing as dangerous as an idea if it's the only idea you have."
21. Never rest on your past successes, there's always something more you could be doing. If you're not learning you're dead.
22. Sharing competitive advantages brings back advantages ten-fold.
23. Be able to say "No" to a potential client.
24. Research your clients as if you were doing the hiring.
25. If you're in the services business every client is unique. "We're different" "You are, just like everybody else."
26. You don't have to remember everything to succeed.
27. It's always ok to let a client go if it's not the right fit any more.You should organize your business so it's ok to let any one client go at any time.
28. The best way to build a business is to stay in business. Build your business so that you hang around. You may not make a lot of money but you build your reputation.
29. Actively solicit feedback from clients.
30. Actively extract the feedback. There's a lot of feedback you may not pick up on.
31. Make sure you're not alone in your role. This way someone can be honest with you.
32. Anything that's annoying and repetitive should be automated or stopped.
33. Track your budget/cost every month.
34. Don't make sampling mistakes about your budget and cost. One of the major mistakes that people fail at is expecting that income will stay the same. You might land a big client this month but might not have one next month so don't overspend.
35. Don't spend your money on office decorations. Very few of us are in a business where clients come to your office. You don't want your customers to think you're spending their money on their office furniture.
36. Make sure you've worked with someone before you hire them (if possible).
37. Learn the big lies you get from clients.
38. Double your reading speed.
39. Cut down on what you read.
40. Stay off facebook and twitter unless you can relate it to your business.
41. Sometimes you can save money by spending money.
42. Sometimes you can save money by not spending money.
43. Everyone who wants to sell you something will tell you it saves money.
44. The examples might not always teach what they're supposed to.
45. Many minds can do a better job than single minds. But not necessarily so.
46. You have to be organized.
47. Know your own limitations.
48. Learn quickly whether or not you want to work with someone.
49. If you see an organization with no enthusiasm for what they're doing they probably don't have enthusiasm for what you're offering.
50. If an organization doesn't care enough to organize, nothing is going to happen.
51. Don't mistake a solution idea for a problem definition.
52. People want a recipe but no recipe works for every organization.

So, that's Jason's (half) list. Each one could probably be a blog entry, at least, so if you want clarification, or to clarify, add a comment. I'll post Wolfram's (half) list when the traffic on this one dies down.

eNovel Store: First Month Report and Lesson

It's been about a month since I opened my eNovel store. After a snappy first two weeks, activity slowed to zero, and I thought nobody would ever buy another novel of mine, let alone put me over the tipping point where the novels would take off like Harry Potter.

I learned that worrying over day-to-day or week-to-week sales is a futile wasted of time. After one dry week, sales picked up again. If they stay at this level, I'll earn a small but welcome addition for my charities each year.

Will I be satisfied? I don't know, but at least I won't worry day-to-day. I've learned my lesson.

It's a worthwhile lesson for consultants in all phases of their business. By its nature, independent consulting is a highly variable business. As I wrote in The Secrets of Consulting, there are, theoretically, three states a consultant's business can be in: A: too much business; B: not enough business; and C:just the right amount of business. But no individual is ever in state C.

So stop worrying and do something about it. Me, I'm asking everyone I know to take a look at my book store.

The Consultant's Money-Back Guarantee

On LinkIn, recently there was a question about what a client had to do to hire a consultant who wouldn't rip them off, just taking money for no measurable result. In my response to the question, I wrote:

I make this easy for my clients by two principles of my consulting business:

1. At the end of every consulting visit, I ask them to evaluate the worth of my contribution. If it's not worth more than they paid me, we either adjust what I'm doing or we terminate the relationship.

2. If they don't feel what I've done is worth what they've paid, they can have their money back, no questions asked. I make sure they know this up front--though I've never had to give back their money.

If a consultant doesn't give you both these things, don't hire them.

Why Give Their Money Back?

Pradeep Soundararajan wrote, in response:

While anything that any human does is a heuristic, why should a consultant want to give back the money for the client not happy with what the consultant influenced?

For instance, I go in as a Consultant to solve a problem. At the end I help the client understand that there is more investment he ought to do in order to ship the product. The client feels unhappy because he hired me thinking that I would help him ship the product with existing budget.

Maybe what I did is what other good consultants might have done, so should I return his money back because he feels disappointed?

Why? Because it's your job to satisfy the client. That's what they pay you for. If you buy a laptop from Apple or Dell or HP and when you try to use it, it doesn't work, don't you expect to get your money back? If you don't, would you ever buy a computer from Apple or Dell or HP again? So, one reason to offer a money-back guarantee is to develop future business with that client.

Another reason is to keep that client from spreading bad news about you to 16 other potential clients. (That's what people do when they feel they were cheated by a vendor. When they feel they got a good value, they tend to tell only three other people.)

The Steering Wheel and Brakes

For my consulting assignments, this guarantee acts like a combination of steering wheel and brakes. It guarantees that the client and I will pause periodically and see if we're going in the right direction. If we're not, we can use the steering wheel to change course, or in extreme cases, just apply the brakes and end the assignment.

Would you drive a car without a steering wheel and brakes? Then why would you want to take on a consulting assignment without them?

I guess maybe you wouldn't want them if all you wanted was a runaway car, one that somehow kept paying you as it careened away toward a fatal crash. If cash flow is the only reason someone is in the consulting business, I hope they hit that wall as soon as possible. People like that give my profession a bad name, and thereby hurt a great many ethical and effective consultants.

Don't get me wrong. I think money is a fine reason for being a consultant, but not if it's the only reason. I want to get paid for my work, but only if I'm actually helping people. I don't want to be a fraud.

What Is Value?

But perhaps the most important reason to offer this guarantee is to force them, and you, to think about what value means to each of you.

Pradeep goes on to say: I think such traps have to be cleared before a Consultant gets in by asking questions like, "What value means to you?" and "Can you think of things that you'd be disappointed to know at the end of this assignment?" and "Do you have insight about any kind of information that could cause you nightmares?"

Well, yes, of course you want to clear this up before you go in, but that's not always possible. People often don't know in advance what they want. They only know when they see it. Many of my clients ask for one thing when I come in, but through my consulting learn that they really wanted something else that was more valuable.

To take an extreme case, at one client, the man who invited me in to help with strategic planning learned that his alcoholism was tearing his own organization apart, and what he needed to do was fire himself and go into treatment. That wasn't what he asked for at the beginning of the assignment, but by the end, he knew that this result was far, far more valuable. I asked him if he wanted his money back (he was part owner of the company) and he said no. In fact, he wanted to pay me more--but I refused. I did my job (helping his company improve), and I earned my pay. That was enough for me.

What If Every Consultant Did This?

Pradeep then says:

Not every consultant would want to return back the money and that could be a good marketing stint or building credibility or a distinguishing factor but if every consultant does that ( which is not an easy thing ) then it might end up causing confusion of whom to pick.

Pradeep is right. It's not an easy thing. In fact, it's so unlikely that it's not worth worrying about.

But, if a lot of consultants used these principles, maybe there wouldn't be so many derogatory jokes about our profession of consulting.

Intelligence Isn't Enough

Pradeep then concludes:

An intelligent client picks an intelligent consultant and that's a heuristic, too.

Well, yes, that's certainly a heuristic, and a necessary one. But not by any means a sufficient one. Intelligence without ethics is like a biological weapon in the hands of a terrorist. Very powerful, to be sure, but you'd much rather not have it on your premises.