The Black Liszt

CTO + CFO = CFBCO

The CTO and the CFO aren't natural best friends in any organization. They are typically separated by a huge gulf of perspective; neither understands or appreciates what the other thinks or does. The best thing for any organization is when the two of them can truly take the other's perspective, and change what they do as a result.

CTO

What's the Chief Technology Officer (CTO) about? He or she had better be the best technical person in your organization. The one who understands the details, the big picture and everything in between. The one who actually understands all those computer acronyms, can sling them with the best, can pick the best and harness them for the good of your organization. At best, the CTO can rally the tech nerd employees to the cause and also convince the suits that everything is good.

CFO

What's the Chief Financial Officer (CFO) about? He or she had better be the best financial person in your organization.The one who understands every line of every statement and report, what's behind it, what led to it and where it's going. The one who understands how all that mass of detail relates to company tactics and strategy, and plays a key role it making them align. At best, the CFO can handle the big picture and the details, issues and people inside and outside the company, all to advance the company towards its goals.

CTO vs. CFO

When not at their absolute best, the CFO and CTO can have a chilly relationship.

The last thing the CTO wants is for some nosy bean-counter to mess with his stuff. Even simple questions are suspect: why is he asking? what's he looking to cut? Go away! Most CFO's seem like clueless idiots to even average CTO's. All they can possibly do is waste time and, through crass stupidity, make things even harder than they already are.

CFO's often see the whole tech group and the CTO in particular as being a bunch of whiney, spoiled, self-absorbed brats. They're anti-social, talk among themselves in their private language, get huffy or all-too-patient in response to even the simplest of common-sense questions, and seem perversely intent at avoiding anything that increases revenues or profits. They're perpetually late, reluctant to commit to anything, always complaining about lack of support, but still manage to have an attitude about pretty much everything.

CTO Fundamentals

Most of the thoughts I've had about computing that are worth anything took me years, often decades, longer than they should have to penetrate my thick skull. But one of the earliest realizations I had remains both true and rarely discussed: to the extent that computers are applied well, they cut jobs, and therefore (usually) costs.

This isn't the pretty way to put it. Most people prefer to think about how computers enhance people's efforts. And they do -- meaning you can get the same job done with fewer people. Or you can deliver more with the same people -- to deliver more without computers, you would have had to hire more people. Any way you cut it, the more widely and effectively computers are used, the fewer people you need to get a given job done.

Put all the gobble-de-gook aside, and what computers come down to is simple: cut costs, do more with less, get it done faster, etc.

Now what does this sound like? Could it, perhaps, sound like the kind of thing CFO's are supposed to worry about? Hmmmm....

The CFBCO

Maybe there's some middle ground here. At the heart of the matter, there is no skill set in an organization better suited to helping a CFO meet his goals than the CTO's. And when a CTO who is really good in nerd terms wakes up and realizes what his job is really about, there is no person better suited to be a company-maker than a bottom-line-oriented CTO.

Put in the most basic terms, a good CTO can make things happen:

• Faster
• Better, and
• Cheaper.

Faster, better, cheaper. That's computing in a nutshell, and when computing is applied to an organization to greatest effect, that's what happens to the organization. It does what it does faster, it does it better, and it does it cheaper. FBC. Wouldn't it be nice if we could have a Chief Faster-Better-Cheaper Officer?

Conclusion

In most organizations, there is a spectrum of leadership. At one end of the spectrum is the nerdy CTO. At the other end is the what's-your-handicap CFO. If you're very lucky and very deserving, maybe you have someone at the center of that spectrum who combines the best of both extremes in a single individual. The CFBCO. The CFBCO combines ultimate nerd-power with dollars-driven vision and insight, and makes the relevant numbers better in a way that even the dullest and most distracted board of directors can understand and appreciate.

Software Quality Assurance Book

I've written quite a bit about software quality over the years. In addition to quite a number of posts on this blog, I've written a short book about it. Currently, I just distribute it in PDF form to work-related people, but I'm thinking about releasing it on Kindle as an e-book.

Background

Anyone involved in software who's, like, alive, gets real involved with software quality. Many years ago, I discovered it was useful to follow up meetings I had with software groups with an e-mail summarizing the ideas. As common themes emerged, I found myself with a small library of e-mails, cutting and pasting them. Then the collection turned into a document, since the ideas were so inter-related.

I started giving the document to groups before meeting with them. I got feedback during and after meetings, everything from mistakes I'd made to important issues I had ignored. So the document grew as it went through at least 15 revisions.

The document/paper/book is pretty long and comprehensive, and I haven't been discovering new things to add to it recently. So it must be "done." I've even taken the time to throw together a crappy-looking cover:

Mainstream Thinking

There are literally hundreds of books on software quality. There are tools. There are certifications. There's a huge body of work out there. Why did I put this book together? Does the world really need another book on software quality? What more can there possibly be to be said?

First of all, let's notice that in spite of all the books, methods, quality software and certifications, software quality still stinks. It stinks in big, process-laiden corporations. It stinks in cool young web start-ups. It stinks all over this land!

So what's the problem? Do people simply ignore best practice? Do they not understand it? Do they try to apply it but screw up?

The answer is pretty simple: mainstream software quality methods are no good. They cost a lot, take a lot of time, slow down development and modification, and don't improve quality much to speak of. What's more, most people in the industry who aren't completely asleep at the wheel know it -- which is the origin of the typical complaint of quality groups, that they're understaffed, underfunded, and never given enough time to do their job the "right" way. This complaint is generally justified! And it's likely to stay that way, because whenever those groups get what they want, cost and time goes up and quality stays roughly the same.

So that's why I wrote what I wrote -- I wrote what you couldn't read elsewhere, about ideas and methods that were ignored by the mainstream. Who knows why? I've stopping caring.

Validating the ideas

I'm only comfortable talking about stuff I know personally. The origin of the book was a large software project, comprising over 7 million lines of code. It processed credit card transactions. I was CTO, and Y2K was rapidly approaching. It was too late to do things the "right" way. We couldn't afford it anyway. Doing nothing was not an option.

So I dredged up some methods I had used in systems software testing that I realized no one knew about in applications. Because there was no other option, everyone rallied to this one. We got the job done and passed Y2K with flying colors.

Later, as I became more involved with Oak companies, I noticed that the short cycle times of web development forced small groups of desperate programmers to re-invent a subset of the ideas I was beginning to systematize. When things were really bad in companies not already using the methods, I could sometimes get them to try them, and the ones that really shifted to the new methods found success. By "success" here I mean simply that they got higher quality software with less time and effort and shorter cycle times, with less "tax" on development.

For a few years, I thought it was important to keep this magic bullet secret. Hah! Glaciers will melt before most software development groups try anything that challenges the way they've done them for years.

The Down Side

There's a down side to pretty much everything. Down side to publishing the book? Can't think of one. Down side to using the methods? Definitely. Here are two big, fat problems that emerge when using the new methods, quoting from the book:

With no big, formless, unproductive but “necessary” QA group, there is no place to put weird new hires in hopes that they’ll get bored and leave. There’s also no place to send people who are just too stupid or lazy or socially skilled to make it as programmers, but you don’t have the heart to fire them.

There are no big, fire-breathing, invective-filled meetings populated exclusively with overhead jobs (managers and marketing) who argue about “pulling things in” and “risks” and what happened last time and “competitive pressures” and elaborate project management charts in 4 point type that someone made up last night but everyone makes believe actually have a relation to reality other than “not.” Meetings like this raise everyone’s heart rate way more than hours in the gym and supply anecdotes providing amusement and smarmy edification for weeks. They would be missed.

Conclusion

Will I push the "publish" button? Probably. I'm thinking about it. Update: I've thought about it. The button has been pushed. The book is here.

Software Quality Assurance Book now available

The book I threatened to release is now available on Amazon.

The Disease of Software Project Management

There are a lot of books on the market about project management in general and software project management in particular. More than 6,000 of them.

They all appear to think that software project management is a good thing -- at least the brand they preach.

I've threatened to publish a book saying that it ain't so. Giving details, arguments and examples. Sounds radical -- but it's not. Most sensible, productive software people know that software project management's effectiveness is best compared to the fineness of the emperor's new clothes:

In publishing this book, I'm not doing any more than the little boy in the story, who cried out "But he's not wearing anything at all!" In other words, I'm just saying what everyone who isn't blind already knows.

The book is now available on Amazon for Kindle. I even made a nerdy cover for it:

My hope with this book is to assure the people who know there's something deeply wrong with project management orthodoxy that they're sane people. but living in an asylum which the inmates have taken over. I hope the book will arm them with the concepts they need to make a break for it, so they can experience the fresh air and freedom they deserve.

Software Project Management Book

I've written a fair amount about software project management in this blog. I've also written a short book about it. Like the software quality book, so far I've only distributed it privately. But also like that book, I'm thinking of publishing it as a Kindle book.

Tid-bits on the blog

It's hard to be seriously involved with software and avoid run-in's (not to mention complete co-option) with project management. You can hardly start to think about writing some code without someone popping out with "how long do you think it will take," the question of estimates. If you resist or act uncomfortable, you're put on the spot. Everyone, you see, wants their software group to be as predictable as though it were a software factory. The people who talk this way clearly don't understand that dates are evil, but there are so many of them, it's like you live in a land of zombies.

Background

While many programmers resist it, they most often accept project management as a necessary evil, as something that they can't avoid. As they age, sadly, most programmers accept this perverse thought as though it were a natural accoutrement of adulthood: wild young programmers may resist the bridle, but mature ones accept that it's part of life.

I too resisted it, and I too came to appreciate some of the rhetoric of software project management. But then reality intervened.

A bit more than 20 years ago I ran a small software group doing pioneering work in document imaging and workflow. A new management team took over, and were appalled that we just wrote code. I was guilty of about the worst thing a manager could be accused of (in their eyes): running an out-of-control, seat-of-the-pants operation in which people just did stuff, without the comfort and support of project management.

Things changed. Expensive project management software got bought.
Expensive consultants came in and lots of formerly productive people sat in excruciatingly long training classes. For days! Then we settled into a regimen in which lots of reports and dense charts
were generated regularly, and we threw around terms like "critical path."

Well, we "got under control." And stopped writing much code. And fell behind the market.
As we became more predictable, we became more inflexible. Timelines stretched out so far that sales people lost heart. It was sad.

After that baptism by torture, which was followed by many more, I really began to think about what was going on when I got involved with Oak. I had a chance to see lots of companies producing software with varying doses of project management involved.

I noticed that the Indian Outsourcing companies were pushing project management big-time, and winning business with it. It must be a good idea, right? When you dove into the details, they did not win by being faster and more flexible. They were completely rigid and slower. But predictable and marginally less expensive. Here's the bottom line: they won business by costing less. They cost less because they paid their programmers only about one tenth of the equivalent programmer in the U.S. But their methods had so much overhead that they staffed every project so much that the final bill to the customer ended up being only about 30% less than doing it in-house. So, oddly enough, the Outsourcers with their devotion to project management proved the point of how bad it is.

On the positive side, I saw entrepreneurial companies doing more work with less, having more flexibility, less overhead, and shorter cycle times. Had they found clever new ways to implement project management? No. They just found better ways to develop better software with fewer bugs, more quickly. That's all!

Systematic Thought about Project Management

These experiences led me to try to understand what project management was really all about -- why everyone kept trying to apply it to software, why it never works (except if you don't care about time or money), and what the alternatives are.

It was a long journey, and I was surprised that I ended up with a short book. As I state in the book:

“Project management” is as effective at guiding software projects to success as hopping and grunting is at helping pool balls to drop in the intended pockets – it may be entertaining to watch, but it has no constructive impact on the outcome. More important, to the extent that we focus on our hopping and grunting technique, we fail to pay attention to what really matters – hitting the ball correctly with the queue. Similarly, in software projects, the more things get off track, the more we seem to focus on project management hopping and grunting activities, so much so that the shaking floor actually makes things worse.

Project Management needs to be taken down a few notches

Part of the problem is that it just doesn't work. Another part is that everyone with experience knows it doesn't work. The crowning part of the problem is that even people who know it doesn't work and put it to the side when they really have to get something done, continue to kow-tow to it. This is illustrated by a story I personally experienced that I tell in the book.

 I recently spent some time with the seasoned, non-technical leader of one of our portfolio companies, and some of his lead technical people. We discussed one of their most successful products. The CEO described how he got involved with a couple customers who had a problem that no one could solve, how he promised them a solution and got his programming team to throw something together that sort of worked. They then scrambled, fixing problems and coming out with a flurry of new releases, always listening to the customer and evolving their code until things settled down, the customer’s needs were met and the company had a new product line.

“Of course,” said the CEO, glancing over at his technical people, “that was the wrong way to do things. Later, we settled down and got back to proper project management.” Of course – the CEO had to intervene and make sure something important actually got done. Later, “project management,” i.e., doing very little but trying hard to do that little on time and on budget, could be allowed to return.

Conclusion

Again, I'm thinking of pulling the trigger on the Project Management book. But first I need to finish formatting it.

Update:

Trigger pulled. Book available.

There are Lots and Lots of Books on Software Project Management

There are an amazing number of books on software project management, each promising to tell you how to "manage" your way to software success. Amazon lists over 6,000 of them! There seems to be no end of books that claim to do it "better," or claim mastery over some sub-specialty.

Here are some books listed on Amazon. There are books (of course) for dummies:

Books from major publishers and computer societies: 

Here's one emphasizing numbers, from a major publisher and a big specialist consultancy:

This one appears to be a hit -- it's got over 30 reviews on Amazon, most favorable. It's from a major publisher, about a particular flavor of software project management:

This project management thing is serious stuff -- my next example is in its tenth edition(!), and is one of the books you need to read to be certified as a Project Managment Professional:

Oh, and about that exam -- you don't want to flunk it, do you? You better pick this up to help you succeed:

And now, we've gotten all the way to item 30 in a list of 6.225 items, just skimming the highlights of about one half of one percent of the list!

What can possible have gone un-said about that deep subject of software project management?

How about that it's a pernicious disease, and does more harm than good?

 

 

Fundamental Concepts of Computing: Counting

Most fundamentals of computing are simple and so is this one: If some aspect of your software counts, count it!

Computer Fundamentals

People who are accomplished software engineers tend to be pretty smart and hard-working. They show mastery of difficult concepts and technologies that are beyond the grasp of most people. It's natural that people like this, when presented with a problem, would tend to dive right in to the tough stuff, both solving the problem and showing how smart and accomplished they are.

But the fact is, computing, like many other fields, benefits from regular re-visiting of the fundamentals, the software equivalent of "blocking and tackling," or even more basic, physical fitness. There is no better way to achieve great results in software than to revisit and re-apply the fundamentals on a regular basis.

Fundamental of Computing: Count it

Even though he was not a specialist in computing, I can't think of anyone who "gets" this concept better than Count von Count.
This guy really knows his counting. From Wikipedia:

The Count has a love of counting; he will count anything and everything, regardless of size, amount, or how much annoyance he is causing the other Muppets or human cast.

The Count also knows that the earth revolves around the Pun, not the other way round:

The Count mentions 2:30 at any chance he can get and often makes jokes about it. This number may represent an inside joke ("Tooth Hurty"). During the afternoon, his segments of the show always come on at exactly 2:30 p.m. or during the "fashionably late" segment, which airs at 2:31.

Counting How Big and How Often

There are many opportunities to find out how big something is. Whenever I hear about a bunch of data, I immediately go to the fundamentals and find out how big it is. I often find out that the number isn't as big as people are acting as though it might be. At this point, I won't do anything more than mention "Big Data" for fear of ruining my mood.

The way you do this is pretty simple: find out how big the average thing is, how many of them there are, and multiply. Not tough! That leads you to think about how you're going to store it. When you do, you find that the typical software methods people use are they same as a decade ago, when capacities were tiny compared to today. It's worth re-thinking storage methods!

There's nothing wrong, for example, with keeping a complete working set in an in-memory secure data store, everything including logs and history in a disk-based DBMS or flat files, and a historical set of data in a data warehouse organized for retrieval and analysis.

The important thing is that counting how much leads you to the fundamental architectural decisions that determine so much about how much work it takes to create and maintain a piece of software.

Counting How Many and How Long

Counting how many and how long are things I think the Count would also approve of. For example, consider the fundamentals of web site design.

Even before the user has a chance to get an impression of whether they find the site to be attractive, there's the issue of how long they have to wait for it to come up. How long you have to wait is the overwhelmingly most important factor in web site design. If a great-looking design is just too slow, the users will go elsewhere.

Second, count the keystrokes and clicks it takes to accomplish a given task. Sound trivial? Yes, of course, just like most of the fundamentals of computing. However, "trivial" factors like whether what stands between a consumer and his goal is 5 clicks or 3 clicks turns out to make a huge difference. Every "extra" action you require the user to take is an opportunity for that user to decide that his goal is one bridge too far, and he's got better things to do with his time.

Conclusion

Count von Count may be irritating, but he's nearly always right: count it!

Oak Investment Partners in the 2012 WSJ top 50 VC Companies

Oak Investment Partners backs 4 of the 50 companies in the 2012 WSJ list of top VC-backed companies. This isn't the first time Oak has been well-represented in that list, or in other important lists. But it feels great every time.

Venture Capital and VC-backed Companies

There are a very large number of companies backed by VC's, and a similarly large number that aspire to that backing. For this list, 5,900 companies were considered, so the list is what the WSJ considers the top 1% of all such companies. An elite list!

As to VC firms, there are also quite a few. The NVCA gives a couple definitions; depending on the one you prefer, there are between 460 and 791 venture firms in the US. This means that most venture firms probably have no companies they back on the WSJ list.

And our companies aren't just any old companies. Last year, our company Castlight Health occupied the number one spot. We've got the number one spot again by backing Genband.

The Companies

As I've done in the past, here's a quick summary of the companies:

#1 Genband. This is a rapidly growing, complex company that provides products and services deep in the innards of networks. The simplest way to understand them is experts in implementing the long evolution of fixed networking and communications systems to ones that are IP-based, for example VOIP.

#25 SmartDrive. SmartDrive has been on the list before. They're pretty much the same thing as they were, except they've clawed their way higher in the list this year, as they richly deserve. They still help drivers of commercial vehicles drive more safely and use less fuel. The market has rewarded them by installing their service on more than 10,000 commercial vehicles.

That's 10,000 vehicles that are safer, more fuel efficient and more cost effective than there were before, something which benefits everyone.

#27 Movik. Movik is deep inside the mobile networks. Most people don't think about what happens when they talk on their mobile phones while walking or driving, and they don't need to, because of the astounding web of complex systems that make it all happen. But we all know the mobile networks aren't flawless, in spite of the billions of dollars spent to upgrade and maintain them. This is where Movik steps in. With their deep insiders' knowledge, they have constructed a kind of real-time "big data" application with analytics and automated responses. They get a flow of information from the various internal systems and decide, for example, that a person walking and talking is connected to a local cell tower that is becoming overloaded, and there's a nearby one that he's walking towards that has excess capacity -- and gets him switched. It's cool stuff, and creates a win for customers and the carriers.

#46 Keep Holdings.I'm having a lot of fun working with Scott Kurnitt and his ace team, based here in NYC, as they rapidly evolve their way from good ideas and implementations to great ones. Starting with AdKeeper, they've now added a service

to enable consumers to get back control over their in-boxes from commercial messages, seeing offers when and how they want to. They're also rolling out a "social commerce service"

that plays in the intersection of e-commerce, social networking and consumer curation of products.