Writing a New Book

I had years ago written 2/3rds of a book for a publisher under contract, and in the end aborted the project due to lack of available free time. Then about 3 years ago I started writing a second book, and have about 10 chapters complete. This magnus opus however has about 20 chapters to go. It was also why I started working on Phos in the first place. This book was designed to teach kids how computers worked by building one in their web browser.

My new book is going to be much shorter. (the lesson I've learned since then is serialize). It is also being written on a narrow practical topic (web software QA). And finally, I am targetting a very small market segment (one person). The idea for the book came about when a friend of mine sent me a text message asking how my new job was going. We both jumped ship within a week of eachother at my last employer and found more appropos pastures for us to ply our trades. He is heading up a test automation lab at his new gig, and I am building a new large scale cloud architecture for advanced web applications. I could really use someone who knows test automation on my project, who do I know with years of QA experience? Hrmmm...

While thinking about the discussion on Meet the Pess yesterday morning (while stuck on an aircraft), it struck me that the Denmark retraining model is critical to a viable flatworld economy. Since most highly paid thinking jobs can be done well enough from just about anywhere in the world (I telecommuted for 7 years), being able to compete on a global scale means adapting to the rate of change. Since our society is not capable of making use of all available labor (see current unemployment and under-employment rates), we as individuals have a responsibility to ensure our personal viability. My personal exit strategy in this regards is bartending and cooking pub grub (something you can't offshore effectively).

I got to thinking about what if I could train someone with a background in QA from another industry to work in mine? Software as a Service (SaaS) is here to stay, as it provides companies a way to monetize their capital investment in software development over multiple lifespans of the product. All of the Open APIs in the world won't solve the fundamental business problem of risk associated with vendor migration (merely lower the risk associated with vendor bankruptcy). So SaaS defines a sort of best fit compromise between software vendors and their partner businesses. And they really are partners, as both must continue to invest in the platform to extract the desired gains. How do we on the production side ensure there are enough skilled QA techs who can validate the specified behavior of the system?

I know, I thought, I'll write another book. And then get my wife to do it.