Going on three decades ago, Eli Goldratt wrote "The Goal: A Process of Continuing Improvement", which is fundamentally a book about operations research.

No, no, don't fall asleep - he brought in Jeff Cox, a novelist, and made an actual story, about a real plant manager, struggling to keep his plant open despite intense competition, some of it foreign, some of it with serious pay disparities.

The book was one of a kind.

In his second edition, Goldratt tells the story of trying to get his book published.  He said that his most interesting rejection note came from McGraw-Hill.  They told him that if he wrote a love story, they would publish it, and put it on the romance shelf of the bookstores.  If he wrote a business book, they'd publish it, and put it on the management shelf.  The problem was that Goldratt had written a love story about business -- and they didn't know what to do with it. 

They took a pass, but the book was eventually published by North River Press, and is still in print today.  (So there, McGraw-Hill!)

Where is the love story about software testing?

Time passes ...

In 1997, Tom DeMarco writes his book "The Deadline: A Novel About Project Management."

The goal was a little different - it was a project management textbook wrapped around a story of a project manager hired to run projects for a certain small eastern European nation.

Ok, that's pretty much the same.

I guess the best distinction I can make is that where "The Goal" is a novel that taught you principles of The Theory of Constraints, "The Deadline" is a textbook that appears in the format of a Novel. 

In any case, the are both far, far better reads than any textbook I can recall short of advanced classes in graduate school where the students picked the books and wrote papers and rotated through teaching the class.

But I digress.

So far we have a novel about operations management novel, and a textbook on project management in the form of a novel.

Where's the testing novel?

Well, I'm hoping my astute readers will correct me and make a big list at the bottom, but I do have one to add: John Donelley's Gold, a novel written by a tester, Brian J. Noggle.

Brian's been doing freelance testing and technical writing for years; we've had him on the podcast to talk about testing, and if you don't follow @QAHatesYou on twitter, gosh, you're missing out.

And he finally wrote that novel - for which I spent a fair amount of last week, frantically turning pages.

No, this isn't a heavy-handed book about testing with cardboard characters who exist to demonstrate "Laws of Software."

It's a real novel, with real characters.

It's just, well ... for us.

The characters are in the (mostly) technical ranks at a DotCom just after the crash of 2011.   The company has had it's first cash crunch; we meet them the characters on layoff day.

It's not huge spoiler that they are headed for the hatchet man's axe, nor that the CEO is incredibly well-off, golden parachute in hand.

What is surprising is that in the heyday of the company, the CEO, John Donnelly, bought a gold bar to symbolize the prosperity and success of nTropics.com.

Our friends decide to steal it.

This is an Incredibly Good Book

No, it's not a morally bankrupt premise.  No, it's not a silly action tale.

The thing that drew me in the most was the characters; I wondered what Michele saw in Kevin, and hoping she'd get together with Edward -- yes, this book turned me into a fifteen year old girl. (Metaphorically.  C'mon.)

We also get to see Kevin develop as a person, learn a little bit about John Donnelly, see how great testers think -- and, of course, there are a few D&D jokes thrown in.

Plus just enough typos (perhaps three in three hundred pages) to make it feel like a treasure hunt, not a slog through something that wasn't copy-edited.

If you test software, if you do technical writing, tech support, or programming, in North America in the early 21st century (especially if you are a dotCom survivor), this book is for you.

If you don't want to risk it, check out the Kindle version, that costs all of one dollar.  That's right, a buck; it's cheaper than a couple of hershey bars or that 20 ounce bottle of Mountain Dew.

Plus, you can get a free kindle reader app for the iPod or iPad, too.

No heavy-handed textbook here, but you might pick up a few pointers about risk.

What can I say?  I read the book, it made my day.  I liked it.

I suspect you might like it too.

I know, I know, the Turkey has all been eaten, the presents all unwrapped, one neighbor has thrown out his tree and the other is taking down his lights.  The holidays, as they say, are over.

Or are they?

Did you know that in the classical calendar, the Christmas season actually begins on December 25th, where it goes on for twelve days, ending with the visitation of the Magi (the "three kings who traveled so far") on January 6th?

December 1st-24th are not supposed to be days of running around, buying gifts, but instead days of, well ... waiting.

It's December 27th, and the wait is over, but the gifts are not supposed to end.

In the spirit, I have two for you.

First - a whole new conference!

I'm not sure if you've noticed, but the entire Software Test Professionals Spring 2012 Conference Brochure is out - and it's awesome!

Take a look, for example, at the STPCon Schedule at a glance. There are five different high-end tutorials on Monday, including Doug Hoffman's Day of Exploratory Test Automation and Anne Marie Charrett on Career Management for Testers.  Tuesday brings Jon Bach, presenting on a keynote-level reply to the "test is dead" movement along with Ben Simo coming out of presentation semi-retirement to talk about Cloud Testing at GoDaddy.  (Ok, Ok.  I don't actually know if Ben was in presentation semi-retirement, or what that even means exactly, really.  But I do know I haven't seen the dude since 2008, and, to be frank, I get around to these things.)

On Wednesday, Scott Barber and Dawn Hayes team up to run a keynote on presenting feedback and I'm running a panel session on Tough Questions About Agile Testing -- and Agile Conversions, and "Agile" Compromises, and Fragile Development, and ScrummerFall ... take your pick.

And there's more.  Lynn McKee, Robert Walsh, Jason Huggins, Lanette Creamer, and still more experts about software testing and development. 

So, if I may be so bold, please allow me to offer you a suggestion.

Most people spend Christmas "break" doing nothing.  If they aren't on vacation, and by some miracle come into the office, people spend the time on research projects, long coffee breaks, infrastructure stuff, and maybe, just maybe, a little work.  It's a time of year where, by it's very nature, there is a little bit of discretionary time -- time you may use as you see fit.

My suggestion is to use that discretionary time to invest in yourself.  Think of one goal, one thing you'd like to get done, and assemble the resources you need to do it.

If the goal is to attend STPCon, well, print out the schedule at a glance.  Schedule the tutorial you'd like to attend, and map that back to your teams tactical needs or the company's strategic growth plan. Print out the hotel information; go to kayak.com and price the cheapest airfare. 

In other words, if you'd like to go to STPCon but know that budget will be a problem, you might use that discretionary time to prepare yourself for the uncomfortable conversation.

It doesn't have to be STPCon, of course.  It could be anything else -- the point is to stop wishing and take action.

In fact, that's my second gift.

A Predisposition for Action

Years ago, when I was a project manager, I found that in any conversation, there were at least three ways of doing thing.  We could keep talking about option A, sure, or we could keep talking about option B, or we could pick one and actually do something.

I found that when we actually did something, we tended to actually get somewhere.  Even if we guessed "wrong", we would get feedback that would allow us to change the decision, make a better one, and get to the finish line faster.

Meanwhile, the talkers would still be sitting around, talking.

Yes, when I do that, I want to make a smart choice, so I tend to make decisions that are small, cheap, fast experiments that will yield results quickly -- the kind of thing that keeps our options open, instead of closing all options but that one decision.

This value system of mine has consequences.  Some things, like writing a book or earning a medical or law degree, take a sustained, long-term investment. If you live this value system, it's likely that you end up like me, publishing a hundred articles before getting a single book out.  But is that really such a bad place to be?

As I said, I'm predisposed to action.  Just do something.  Many people find an outlet in twitter, blogging, writing or presenting, but that might not be your bag.  For you, it might be volunteering at a local user's group, or investing some more time in reading, or, hey, putting the time in to golf or mountain biking or running to take things to that next level.

We don't all need to be software geeks.

I'm not doing this idea justice, but there is someone who has - Seth Godin has a great little book on the subject called Poke the Box.

So here's the deal:  I am going to give away five copies of Poke the Box, free, to the first five people that email me a request, no strings attached.  My email is Matt dot Heusser at gmail dot com.

This offer may apply to North American Customers only.  If you ask, and you are one of the five, and you are outside of North America, and the shipping is a reasonable cost, I will go ahead and order it for you.

This offer is not sponsored by anyone, it's just little old me.

The book is free and yours for the asking ... if you just see the opportunity and seize it.

Merry Christmas!

UPDATE - 12/28/2011

I'm afraid all five of the give-away books are spoken for; Amazon is currently in the process of shipping books to Phil Kirkham, Sigurdur Birgisson, Steven Vath, Dan Panachyda and Duke Kalra.  
Duke gets special bonus points because he is based on the Indian Sub-Continent of Asia, and came up with the idea of getting a kindle edition to save shipping.  Way to overcome, Duke!

Though there was no sponsor strictly speaking, my friend Mark Tomlinson recently sent me an Amazon Gift card as a Christmas-ish gift.  I thought that was a neat thing to do and decided to 'pay it forward' a bit with the Christmas book offer.  I hope you liked it.

More to come!

The focus of this blog, explicitly and without apology, is on software test and quality issues. 

One way to achieve software quality is to slow development to a crawl. 

Say, for example, that you start with a team of 100 programmers and fire ninety-nine of them.  Now take all that money and hire ninety-nine people of different roles - testers, configuration managers, methodologists, version control experts, graphic designers, planners, project managers, analysts, technical writers, and so on.  

You may have better software - software that looks prettier, has fewer defects, and has a better user experience ...

... it's just that it's going to take you a year what you used to do in a week, right?

I'm reluctant to call that improvement, and I suspect you are too.  I suspect with most companies, the 'right' answer for how to staff 100 people lies somewhere in the middle.

That said, here's a story for you ...

A Christmas Carol (Sort of)

Imagine for a moment that you are a programmer (or tester, or whatever) at XY Corp,  medium-sized business in the United States, with a software development group of, say, fifty people.  The business folks email your whole team with a request -- a report to pull data out of the database and display it on a web page, maybe with a parameter or two.    One of the old programmers, now a director of IT, wants to be be helpful and replies with the basic SQL for the query.

Joe, the intern, gets the email and immediately starts coding.

"Woa, woa, woa, Joe, you don't understand", you say.  "We need to get this request into our story-card system and have a kick-off.  We need to identify success criteria up-front."

And you do.  You hold the meeting and get conditions which will lead to what outcomes, the create an executable specification in a tool like Cucumber or Fitnesse.  The developers wire up these conditions and see red bars (no output), then go off to design the system.

Geek party time. 

The developers go off to design models, each representing a customer, a row of the output.  The models will be pulled from the database through an object-relational mapper.  They will design the models test-first, using unit-testing tools like jUnit or nUnit.

The objects will be pulled from a self-aware list that has a connection to the database; the programmers will also build that test-first.  The self-aware list will take the parameters, generate itself (well, not exactly, they will be generated by a factory), and then be passed by a controller to a view that will take the list and draw it on one screen.  It's all test-first.  It is a sight to see - it will only take a pair of programmers four or five days to kick this thing out.

There's only one problem.

Before you are done the kickoff meeting, Joe the intern drops by.

"It seemed simple to me; I hooked up the parameters to the SQL, did a for loop, and kicked out the results as an HTML table."

Let's see here:  The 'right' solution would take about two person-weeks, and the wrong one took an hour or two, right?

What Just Happened?

I'm not against object-relational mappers.  I'm certainly for TDD, and I've seen TDD done at the true unit level with mock objects work extremely well.  The Model View Controller (or MV Presenter if you prefer) pattern is established well, and I like tools like selenium or fitnesse

... yet Joe the intern was faster.

Yes, he was, really.  One thing we know for certain about all those extra practices is that they are just that: Extra.  They add drag to the project.

Now, there are certain advantages to all those extra practices.  Through those practices:

- We reduce the risk that we will build the wrong thing
- We reduce the risk that we build it, but it isn't quite right
- We make more clear communications with the customer and technical staff, so the developers know what 'done' means and the customer know what to expect
- We can increase the reusability of the components we are creating
- We increase the maintainability of the components we are creating
- We increase the extensibility of the components we are creating
- We decrease the testing time we will spend next time, after the next modification
... and so on.

For this project, none of those risks were very big.  It is very possible this is a one-time report that you write once -- or that modifications will still be extremely cheap and easy.

Then again, it is possible that this is the beginning of a reporting framework that will go  and the object-oriented approach I described above is more appropriate.  With the context describe above, we don't really know.

And that's the thing.  Different software development practices are appropriate to solve different kinds of problems. 

To some extent, this is an impossible problem - because some practices lead to code that is more extensible, malleable, and cheap to test, which will be valuable if we know we will experience churn, and knowing if we will experience churn is essentially predicting the future.

Yet in some environments, like Socialtext, where we touched all the code all the time and released every two weeks for two years, we know we will experience more churn then that time we produce that one report for the Customer Service Department.  (By the way, yes, I know, the intern took two hours, but we could train the department to do it themselves with a SQL reporting package.  You're getting ahead of me.  Hold on.)

So, while we might not have an accurate crystal ball, it may be possible to examine the factors involved in our problem and decide what kinds of solution is appropriate -- and those factors may cause the scope of the solution to scale up or down.  The reporting solution might just be a SQL reporting package; a one-time log reader and reporter might be a awk script we hack out. 

Now, if you want to take that same script and run it, piping the output to a database and reporting that output to the executives, you might want to re-write it test-driven in a language like perl, running it overnight as a scheduled task.  Want it to be real-time and we might look at a different approach.

What I'm saying here is that the context matters in software development.

We've know that for years in software testing, and even have a formal school of testing around it.

Many of the same principles hold for programming, software development, and project management.  We talk about the project management things, at least implicitly, when we talk about methodology design. 

Programming, not so much - or at least, not often enough in the circles I listen to.

If I'm listening to the wrong voices, please, help me plug into the context-driven software development community.

If those voices aren't out there enough, well, let's go make them.

What do you say?

In the coming year these are the top 5 concerns every business leader should consider if they are interested in success:

1)      Although it seems intuitive to “hunker down” and wait out the economy until it turns the corner, it is the worst thing you can do in a competitive business environment. While your company is stagnating a competitor is strategizing, developing, and implementing new products and services to improve their business. It could be a recently downsized employee (s), it could be a small firm not yet on your radar screen, or another business that decides to expand into a new sector of business where they see opportunity. While you “sleep” the competition is taking the business you are not serving while waiting for the economy to rebound. The rebound will happen but you may be in a very different position to take advantage of it if you have sat on the sidelines for too long.

2)      As the numbers get tight, many management teams start the uncomfortable conversations of reducing “headcount”. They are really people but management uses this term to feel better. The fatal blow comes not to the employee but often the organization. The most experienced, high paid employees usually are the most valuable as well. The knowledge and understanding of your products, services and customers is critical to future opportunities for growth, and experienced employees if utilized correctly can help drive a strategy to grow even in difficult economic times. They often can do multiple jobs compared to a junior employee and they are often the most loyal to a company when treated fairly. If you choose to downsize these employees not only will you hurt your ability to operate, you hurt your ability to survive the future. If you have to reduce people you need to do a comprehensive analysis of the people and positions from every department. You can’t say I need to cut 2 heads from every department, that’s crazy. You need to look at the workload and people to match them with skills and needs. Most likely that will mean keeping your most experienced and value based employees. And remember, most start-ups are founded by employees of organizations that let them go or allowed for disengagement to set in. These employees tend to know all of the warts of their previous employer and the most valuable and profitable customers.

3)      In a similar vein, the elimination of internal programs that support the employee’s ability to do their job more effectively is counter- productive. When the economy is tight and you need less people doing more work you should make sure you are helping these employees with some sort of training support. Be creative and let your teams come up with programs that work for them. At a time when employees are nervous about their jobs, getting them more involved will help reduce their stress level and become more engaged. The numbers are as high as 85% of workers are only staying where they are until the economy gets better. By getting them involved to be part of a solution you will be able to gauge employee interactions to know who is at risk and who is waiting for the economy to turn.

4)       Technology advances are happening at light speed and many of these advances can help increase customer engagement, employee engagement, improve efficiencies, increase revenue or all of the above. Do not make blanket policy to eliminate all technology upgrades or purchases. New companies to your market can take these new technology advances and implement them without the legacy systems more mature organizations often have to deal with. This can be a huge competitive advantage to the start- up firm. Every business leader must remain engaged with the technology vendors if only to understand what these technologies can do to make their competitors more successful. Leaders must be willing to fight for technology investments that keep them competitive and efficient no matter what the economic environment is. Companies with the best technology integrations will lead in 2012.

5)      Review all of your current strategic initiatives on a regular basis to insure the dynamics have not changed since you first decided on that strategy. Things are moving at light speed even in tough economic times. Don’t be lulled into doing nothing because you think everybody else is doing nothing. I will guarantee you there are many people plotting their success to take advantage of the economic malaise. Remember that some of the most successful businesses have started in the most difficult economic times. The leaders that are most aggressive and strategic in the worst economic times are going to be the leaders of the next Microsoft, Fed Ex, HP, Burger King, to name a few companies that started in recessions.

In 2012 the business climate will be blurred with the political realities of a Presidential election cycle. Executives can be easily distracted from the real economics and focus too much on the short term fluctuations of a very volatile period. Executive and managers must know their business sector and plan accordingly. The economy will not stop although it may be portrayed that way. People are still going to do business but they will be discriminating with all of the options they have. Mobile retail, social retail, insurance, transportation, energy, healthcare, government, consumer goods, are all going to continue to happen.

The question is: will you be ready to compete for the business in 2012?

Older Posts