Thursday, June 30, 2016

The Most Important Aspect of Software Testing

On a public forum, the question was, "What are the most important aspects of software testing?"

A number of good answers were given, but all tended to emphasize finding errors. To me, that's a limited view of testing. I would say, instead, that the most important aspect of software testing is to provide information about the state of a software product. That is, not just errors, but what's good and bad about the product. And, by the way, what's just mediocre.

For instance, the speed of the product might not be in error, but could be good, bad, medicre, or perhaps acceptable to some or all possible users. It's the tester's job to document that.

Or, there may be a feature that works okay, but is not so easy to use. Is that an error? Who knows, but in any case, it's a fact that the sponsor of the project will usually want to know about, and providing that information is the tester's job.

One more example: if a tester merely finds and reports errors, small wonder that developers feel that testers are nattering nabobs of negativity. Test reports should describe what's good—what's wonderful—about a product, and testers must never forget that part of their job.


You can read more about important aspects of testing in my book, Perfect Software And Other Illusions About Testing.

Thursday, June 16, 2016

What's something I can do right now to increase my productivity?

I was recently invited to answer the question in the heading. There were already 99 other answers, some of them very interesting. I tried reading all the answers, but gave up after the first two dozen or so. All that stuff about lists and apps and schedules and methods with trademarked-names might have been okay for some folks, but they didn't do much for me. I don't really use any of them, but I’ve been an incredibly productive person all my life.

I've published around a hundred widely acclaimed books, plus hundreds of articles. I've invented useful things and won a handful of awards for my writing. More than ten thousand people follow my tweets and my workshops are filled with people from all over the world. While doing all these things, I've also found the time and energy to support many volunteer causes.

My secret? I can do all these things because I apply just one principle:

Do what you love doing.

If you love it, you won’t need any of this tricks and tips. You might use some of them or make your own if they help you do what you love, but if you’re not doing what you love, no tricks will help much.

But, you say, "there are just some things I have to do, whether I love them or not." Well, first of all, re-examine those things and make a NOT-TO-DO list, to remind you to stop doing things you hate and don’t really have to do. And if there are still things left that you think you must do, experiment.

For instance, stop doing them for a few days or so and see if it matters. I remember when I had a job where we were supposed to put out a daily report for our manager’s manager’s manager. I started doing it every other day, and nothing happened. I switched to once a week, but again nothing happened. I cut down to once a month. Nothing.

After seven months, this senior manager finally came raging into my office demanding his daily report. I calmed him down and showed him what it had cost to do it daily when he only needed it maybe once a year. We negotiated a deal where on the day he needed it, I would drop everything and produce it in about two hours. That gave him what he needed and saved me two hours a day, 199 working days a year. Now, that’s productive.

But you may still have to accomplish a task that’s really needed, so your experiments don’t work. In that case, examine HOW you accomplish the task and use your imagination to find a way to do it that you really enjoy. For example, you can make a game of the task.

For instance, I once had a rather dull report I had to write regularly so I started each time by picking ten words at random from a large dictionary. Then I challenged myself to use all ten words somewhere in my report. Not only did this make the report into fun game, but I improved both my writing and my vocabulary. And, oh yes, people told me they enjoyed reading those reports, so maybe it made them more productive, tool.

If you enjoy doing a task, you won’t procrastinate, and you’ll do it with gusto. Voila! You’re now the most productive person around.

Not only does this principle work for you, but you can teach it to those who work with you, principally by example. When you do this, you're practicing a powerful form of leadership, helping all those other people be more productive. Think of it this way: It's the opposite of the dreaded micro-management. Instead of telling people how to do things your  way, you're encouraging them to find their was to do things so they'll be a productive as you are.

(You think I’m making this all up? Well, how many people do you know who have accomplished what I’ve accomplished. You can check my website (www.geraldmweinberg.com) and then find some other people with a comparable history and ask them if they enjoy what they do, all day. I don't think you'll find many of them who spend their day making lists—unless they've made it into a list-making game.

Monday, June 13, 2016

5 Ways Writing a Book Builds Your Consulting Business



If you're a consultant, or want to be, you need to read this blog by my colleague, Tonya Price: 

5 Ways Writing a Book Builds Your Consulting Business


I agree with all of Tonya's 5 points, and I'd like to point out one other way writing a book helps you become a successful consultant. Writing a book is not a one-way street, sending ideas from you to clients and prospects. Writing a book is a way for you to learn new ideas and new ways of expressing your ideas.

In my experience, if I want to learn some new material, the best way to do that is to write a book about it. Even if I never publish the book—even if I never even finish it—and don't achieve Tonya's five benefits, I still benefit by becoming a better consultant.

So, even if you're afraid that you don't write well enough to be a successful author, you ought to start writing a book about something you'd like to better understand. And, a good first step is to take advantage of the Write Stuff 2016 bundle of ebooks.

 5 ways to a book helps your consulting

Wednesday, May 25, 2016

The Write Stuff 2016 Bundle

Email-logo
Bundle_103_cover
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.

Tuesday, May 24, 2016

What is the truth about 10x programmers?

Way back when I wrote The Psychology of Computer Programming, I pointed out the wide variation in programming skills. Years later, people began labeling this phenomenon 10x programmers.

On the Quora website recently, a participant asked "What is the truth about 10x programmers?"

Most of the answers there were good, but misguided. Many of today’s critical programming tasks are simply too big and complex to be handled even by a 100x programmer (not to speak of maintaining what a 100x programmer produces but does not want to be bothered maintaining).
For many years now, we have understood that the programming job is not really a job for individuals, but for teams. (Yes, an individual can produce a fine small program, such as a game. I have done that myself, many times over 60 years in the business.) So what we really want is a 10x leader/teacher of programmers. If you can’t pass on you 10x abillities to others, you’re not what we want for those enormous programming tasks.
That’s why I now concentrate on teaching 10x programmers to be 10x programming leaders, as in my Problem Solving Leadership workshops and my books such as Becoming a Technical Leader.

Sunday, May 22, 2016

How can I be a faster programmer?

Recently, "Tommy" posted the following question on Quora, a question-answer site with lots of good stuff (and some really cheesy stuff) on a variety of topics:

How can be a faster programmer?

Tommy received a goodly portion of excellent answers, with lots of details of tips and techniques—great stuff. Reading them over, I saw that a few of the answers offered some good high-level advice, too, but that advice might be lost in all the details, so I decided to offer a summary high-level view of what I've learned about speedy programming in my 60+ years in the computer business.

First of all, read all the great answers here on Quora and incorporate these ideas, one at a time, into you programming practices. In other words, to become faster or better in some other way, KEEP LEARNING. That’s the number one way to become faster, if you want to be fast.

Second, ask yourself, with each job, “Why is programming speed so important for this job?” Often, it’s an unskilled manager who knows only a dangerous amount about programming, but can always say “work faster.” So ask yourself, what’s an appropriate speed for this job, given that speed and error are tightly related.

Third, ask yourself, “Do I really need a program for this problem?” If you don’t have to write a program at all, that gives you infinite speed. Sometimes you don’t have to write a program because one already exists that will do an adequate job. Sometimes you don’t have to write a program because a back-of-the-envelope estimate will give all the answers needed. Sometimes you don’t have to write a program because there’s no real need for the function you’ve been asked to implement.

Fourth, don’t skimp on up front work because you’re rushing to produce code. If you’re working with the wrong requirements, any nifty code you write will be worthless, so any time you spend on it will be wasted. If your design is poor, you’ll write lots of wasted code, which means more wasted time.

Fifth, when you finally have a good design for the right requirements, slow down your coding in order to go faster. We say, “Code in haste; debug at leisure.” Take whatever time you need to think clearly, to review with your colleagues, to find solid code you can reuse, to test as you build incrementally so you don’t have to backtrack.

Sixth, develop in a team, and develop your team. If you think teammates slow you down, then it’s because you haven’t put the effort into building your team. So, in fact, we’re back to the first point, but now at the team level. Keep learning as a team. Your first job is not to build code, but to build the team that builds code.

Many of these principles are developed in much more detail in my many books on software development, so if you want to learn more, take a look at my Leanpub.com author page and make some choices among about fifty books and a bundle of bundles of books. Good reading!

Monday, May 16, 2016

Why Agile Projects Sometimes Fail


The gang was enjoying a BBQ Pig Out at Rudy's. It was a magical moment until Rusty and Millie started to argue about Agile software development.

Rusty started it all by saying, "Agile is magical."

Millie banged on the table with a half-chewed pork rib. "That's ridiculous. There's nothing magical about it."

"Sure there is." Rusty pulled a Sharpie out of his pocket protector and printed "AGILE" on a paper towel (which passes for a napkin in Rudy's). "There are just a few things management has to provide—like MONEY." He sketched a capital M on the towel, making MAGILE.

"Money's not enough," said Millie.

"Of course not. Management has to eliminate environmental interference.' With one smooth stroke, he crossed out the "E."

Millie frowned and shook her head, but Rusty took no notice. "And they need to Cooperate, and not just occasionally, but All the time." He added the C and A, finally producing "MAGICAL."

"Cute," said Millie, her tone sarcastic, but she was clearing struggling not to smile. "But successful projects require more than waving a Sharpie wand and pronouncing 'AgileCadabra.'"

We all knew that Rusty was pulling our legs. Millie, of course, was right. If you want to succeed with an Agile approach, you need more than magic rituals. Not only that, you need to avoid quite a few rather common mistakes that lead to failure.

Common Mistakes in Building New Things

In my experience, these common mistakes are not unique to Agile projects, but will kill Agile projects just as easily as they kill Waterfall or any other approach:

1. Committing to a schedule or cost without having any relevant experience with this type of project.

2. Using the experience on a similar but smaller project to commit to an estimate on a larger project.

3. Extending requirements to "optimize" or beat unknown competition.

4. Failing to recognize signs of impending failure and/or act on them to extend schedules, reduce costly requirements. (like those that diminish velocity by creating more frequent failed tests).

5. Failing to recognize limits of the environment or process or recognizing them but being unwilling to change them.

6. Simply undertaking too many simultaneous tasks and perhaps failing to complete any of them.

7. Not recognizing both changes and opportunities presented by a new technology.

8. Not asking the customer, out of fear, or lack of customer surrogate contact.

9. Not asking anyone for help (fear?).

10. [I invite my readers to contribute more failure dangers to this list.]

The Underlying Failure

Beneath each of these failure reasons, and others, lies one generalized failure. I explain that failure in the remainder of this article, posted as a chapter in my book, Agile Impressions.