I've been releasing the Building Better Software Better series of books for the last 3 years. Four are currently available. Another will be released in early 2016, and two more will follow. I'd like to briefly describe the origins and content of the books.

Writing lots of software

My first job, at 16, was pressing sweaters in a knitting mill during the summer for minimum wage. It was a motivating experience. Later in high school, I started programming computers. Before graduating with honors from Harvard College, I wrote code for oil refinery optimization and the ARPA-net. I then wrote code for compilers, composition systems, operating systems, DBMS internals and applications, large scale financial transaction processing, document processing, workflow and more. You can find details in my LinkedIn profile.

I was hands-on at each job, writing lots of code. I was often dragged into management, but struggled to rise to the level of mediocrity. I did fine interacting with customers and creating marketing stuff. And of course writing code.

Being on the Investor Side

I started working in the technology side of venture capital in the early 1990's. After helping to generate good returns for the fund, I became a GP at Oak Investment Partners in 2000, where I worked to improve the outcomes of our computer-based investments, from infrastructure and tools to the consumer internet. I saw lots of companies we didn't invest in, and of course spent lots of time with the ones we did. I concentrated on health care and financial technology investments with the Oak HC/FT fund, where I was a GP.

Like everyone else, I wanted our investments to succeed. But unlike most everyone else, I dove into the products and services, the code behind them, and the people who built the code. Sometimes the code made little difference. But other times, it really mattered. Regardless of its impact, I got to see how things went with the software and the business, sometimes over a period of many years.

Noticing the patterns

As I matched my own experience with that of the companies we invested in, I started to notice patterns. I first discussed the things I noticed with people in the companies. I found that writing them down was useful, so I put them into long e-mails. As the e-mails grew, they evolved into private-circulation papers. I made many additions and corrections based on feedback and new experience. I started posting about the ideas at my www.blackliszt.com blog. I'm finally releasing the material as the Building Better Software Better series of books.

The book series

Building Better Software Better describes how winning software people actually do what they do. It is often contrary to widespread practice, what is believed by many professionals, and what is taught in computer science and business school. In all too many organizations, failure to build the right software, quickly and well, is a major impediment to business success. Using even some of the methods described in these books can make software into a major driver of business success.

Wartime Software

Building bridges for civilian use takes years and thousands of people. Building bridges in wartime takes hours – and it’s done under enemy fire, and the load and quality requirements are higher. Most software is built the way bridges are in peacetime. Some groups screw up building bridges in peacetime, and their bridges fail, typically because they don't follow the established methods. Some groups -- those who are “under fire” or just don’t have time or money to do it the “right way” -- build software using wartime rules – software that is better than peacetime software. They do this not by cutting corners, but by following a different set of rules and methods.

Best to start: http://www.blackliszt.com/2012/03/bridges-and-software-in-peace-and-war.html

http://www.blackliszt.com/2014/02/lessons-for-software-from-the-history-of-scurvy.html

General posts: http://www.blackliszt.com/warfare/

Book: http://www.amazon.com/Wartime-Software-Building-Matters-Better-ebook/dp/B00CUGHDT8/

Project management

The title is the Disease of Software Project Management, because it has in fact been a disaster for software. The idea that software development should be managed by project management techniques is accepted nearly universally -- the only disputes are about which of the many minor variations to choose. This book is an extensive deconstruction of project management, its origins and its application to software development. If phrases like "that will probably take us three sprints to get done" spring from your lips without sarcasm, you need to read this book. The core idea is that all forms of project management optimize for expectations, while in wartime you optimize for speed.

Best to start: http://www.blackliszt.com/2010/10/software-project-management-dates-are-evil.html

http://www.blackliszt.com/2013/03/software-comparing-waterfall-and-agile.html

http://www.blackliszt.com/2012/10/software-project-management-book.html

General posts: http://www.blackliszt.com/project-management/

Book: http://www.amazon.com/Disease-Software-Project-Management-Disaster-ebook/dp/B009RQ6PUC/

Software QA

Things are done faster in wartime, but that's only possible if they're done differently. QA is one of the key areas of difference. There are core ideas to understand, and detailed methods that are different, involving different skill sets than are normally involved in QA.

Best to start: http://www.blackliszt.com/2012/04/a-simple-framework-for-software-quality-assurance.html

http://www.blackliszt.com/2012/10/software-quality-assurance-book.html

General posts: http://www.blackliszt.com/software-quality/

Book: http://www.amazon.com/Software-Quality-Assurance-Building-Better-ebook/dp/B009TAMNHA/

People

Managers tend to apply the same templates to managing software people that they apply to everyone else. They foolishly think they can manage people who are doing something they don't understand and can't even see. This book covers some of the things that are unique to software people.

Best to start: http://www.blackliszt.com/2014/10/joe-torre-and-software-development.html

http://www.blackliszt.com/2015/03/software-people-book-just-published.html

http://www.blackliszt.com/2014/01/who-makes-the-software-decisions.html

http://www.blackliszt.com/2013/11/people-and-substance-in-software-management.html

General posts: http://www.blackliszt.com/people/

Book: http://www.amazon.com/Software-People-Human-Building-Better-ebook/dp/B00VDIFP3U/