The Mysterious Hidden Languages of C++

C++ is old enough to have teenaged children (like Java, conceived when C++ was itself a wild teenager). Some lucky developers have spent virtually their whole career writing C++. But while C++ grew and solidified, the world of programming languages bubbled and foamed around it. Languages and language ideas came and went. Lexical styles changed and changed again. In these modern days of Hascell, python and Javascript, it can be hard to remember that the folks who originally designed C and C++ learned to program in BCPL.
 

The Secret Expression Language Inside C++

An expression language is a language where every executable statement produces a value. The vestigal expression language embedded in C++ includes individual expressions, sequences, blocks, if/else, and function call, but not iteration, alas.

x = 1, y = 2, z = x + y is a sequence. It sets the values of variables x, y, and z, and produces the value 3.

(rand(), 0) is a block. It calls the function rand(), and produces the value 0.

x == 1 ? y : (z, 0) is an if/else statement. It evaluates the boolean condition x == 1. If x and y have the values set in the previous expression, it produces the value 2. If x is not equal to 1, it produces zero.
 

C++ Has a Shiny New Functional Language Too

Here's the old syntax for a function.

int foo(int x)
{
    return x*x-1;
}

Here's the same function as a lambda. Return value in a different place. Syntax for associating a name with the function different. New rules to remember about the difference between lambdas and function pointers.

auto foo = [](int x)
{
    return x*x-1;
};

Lambdas have a whole new scheme (ouch, pun) of type deduction rules. Someday they are going to be special. But today they are mostly syntactic sugar, for people who grew up with Javascript or some exotic functional language so they can pretend that C++ is trendy too.

Aphorisms for Work

Here are some aphorisms that I think upon, usually during meetings with grumpy managers.

It takes the same time to do a project right as to do it wrong

You just spend the tine in different places. You can rush through coding without any planning, but you will spend a lot of time in front of the debugger, and maybe have to throw your code away and start over when you understand the problem better. Or you can do thoughtful design, code at a deliberate pace, run your unit tests, and be done. It comes down to a lifestyle choice.

The most dangerous thing in the world is a half-understood Harvard Business Review article 

There's an HBR article that says, essentially, "All other things being equal, getting software done sooner results in greater revenue." This one paper is the cause of so much misery for development teams. Managers love to use this article as an excuse to pry the software out of development and jam it into production before it's finished. They never read the "all other things being equal" part of the article. 

There is an HBR article that says, "Pay is not what motivates employees the most." There are managers who read this article and think they can overwork and underpay their employees. They don't read the part about what does motivate employees, like empowerment, recognition, and work/life balance.

The most pain is inflicted when the manager hears a summary second-hand, and doesn't even know he has only half the advice. He thinks, "There's an HRB article that says you should ship the project as early as possible", or "HBR says employees don't care that much about pay."

When everything is important, nothing is

Ever have your manager tell you on Monday to work on this, because it is the most important thing, and then tell you on Tuesday to work on that, because it is the most important thing. And then you ask him to choose which is most important, and he says they both are? That is what a weak manager does when he doesn't want to make a decision. There must be a most important thing, the thing to finish first. 

If everything is important, if everything is an emergency, then nothing is really important, because your manager will blame you for what you didn't choose, no matter what you did choose. If your manager behaves in this way, it's a good time to get your resume updated and start looking for work.

The 90/90 Rule: The first 90% of development takes 90% of the time, and the last 10% takes the other 90% of the time

Oh, how many times has a developer said he was 90% done in one month, only to spend a second month on that last pesky ten percent? You're 90 percent done with the part of the task you know about. Generally that's about half the task. It's a very mature organization indeed that can correctly estimate completion percentages. Your best chance is to estimate things using a consistent process, and then consistently record how your estimate matched reality. Then you can de-rate future estimates until your estimation process matures.

Software Quality: A Race to the Bottom?

Another Old Hand, whose opinions are based on very relevant experience, says that the software industry is trapped in a race to the bottom in software quality.

The trap is that investors' needs are divorced from software companies' mechanisms for producing value. Investors want the stock price or corporate valuation to improve in every reporting period; every year, every quarter, every month, every day. Investors are entirely uninterested in what a company did last month. They invest today to reap profit in the future. Companies, on the other hand, can only demonstrate their ability to produce value by completing projects; shipping disks, posting content, publishing interfaces. But it is hard to encode much value into a software product in a day or a month.

To impress investors, a company must ship, soon. Since investors aren't interested in what the software does, there is a strong incentive to ship early, but less incentive to ship complete or useful code. For a startup which has never shipped, it's all about who has the value story with the most zeros on the end of it and the shortest time to delivery.

To impress partners and customers, a company must ship. Customers are largely uninterested in what a company plans to do. They want products now. If a potential customer wants functionality, and there are competitors, the one who ships first wins the customer. Having won, it's a relatively smaller problem to keep the customer. Customers are used to defective software.

Thus, according to my friend, what wins is crazy, caffeine-fueled speed. Quality doesn't matter. By the time the customer finds out the product is imperfect, the sale is made, the money paid.

This reasoning depresses me. I hate what it means for my profession. Yet I can find no flaws in the argument, only small exceptions; established quality brands; software products (databases, kernels) that can never work in the marketplace if they aren't reliable; special customers who know what they need and write quality into their purchase agrements.

Reading Your Own Press Releases: A Management Antipattern

To customers, a new company is an unknown. A new company has no reputation. A new company must focus on providing innovative or cost-effective solutions to customer problems, because it's the only story they have to tell. Nothing wrong with that.

Well-established companies have more to say. In addition to presenting their latest product's features, they can tell customers about their previous products, their many years in business, their reputation for quality. Nothing wrong with that either. It's easy for a customer to choose an established company versus an upstart competitor, even without doing a bunch of homework, because the established company is a known quantity.

But sometimes, an established company loses its way. They begin to tell themselves about their reputation for quality, their years in business, and their leadership position. Their executives tell their product teams that they can charge a premium price because they are the "Cadillac brand", regardless of the strength of competitive products. If they say this often enough, it becomes received wisdom within the company. I call this behavior reading your own press releases.

A company that is reading its own press releases is already past its prime. When a company starts reading its own press releases, it stops worrying about solving customer problems, or being better, faster, and stronger than the competition. They may even get away with this for a few years if they really were market leaders. But eventually, they find themselves sidelined by their hungrier competitors, and their position of advantage evaporates.

I've worked for two companies who had this problem. One is now a division of a conglomerate, who fixed the problem by replacing complacent managers. The other annoyed its partners so much with slow product delivery that the partners made the company irrelevant. Last I checked, this second company was still in business, but they shed three quarters of their staff in a paroxysm of downsizing, and never recovered their former greatness.

I bet you can see some obvious examples in the news of large technology companies who have been reading their own press releases. Where are their new products? Missing in action or underwhelming critics and customers. When your division manager starts talking this way, tell them to wake up and smell the innovation.

Smartest Guy in the Room: An Organizational Anti-Pattern

Every software developer thinks they're smart. Heck, I think I'm very smart. But organizations seem to go badly wrong any time they anoint one person (or a few people) as the guy(s) to make all the smart decisions, and demote everyone else to code monkey.

I worked in a big organization where several senior developers convinced management to take them out of their business units, and put them in a special R&D cost center. They were going to do user interface research that would inform the next generation of products. Now, if this had been Bell Labs, and these guys had all been PhDs, they might have discovered the Cosmic Microwave Background or something. But these were just guys. When the team I was on asked these special devs to do some user interface research for our next product, they said, "Oh no, we can't be tied to a particular product." As far as I know this group never produced so much as a PowerPoint presentation. They were disbanded after a couple of years.

A company where I worked purchased a startup that found itself out of money and on the market for cheap. Their fast-talking CTO was a former employee of my company. He talked my company into putting him in charge of all development in our division, singing the following siren song. "You've been spending way too much time and money on carefully designing and architecting your products. At my company, what we did was just built 'things' and put them in a pile. Once a year or so, I would reach into the pile and pull out enough 'things' to make a shippable product." This strategy had worked so successfully for his last two companies that one had been folded into the other, and the survivor sold to us. It worked so well for us that he went through two years and six million dollars without producing a single product. Our division was shut down and everyone laid off, including the fast-talking smart guy, but not the two managers responsible for hiring him.

At another company, a smart team was created to write a big Windows editor to solve our very complicated configuration problem for a variety of products. They spent 18 months working (not too successfully) on a universal data input editor. But they never considered the complex problem of compiling the input data for each of several rather different products into usable files. They had in fact no idea how to solve this problem. So they never showed a single working version. They built a rather elaborate castle in the air, starting from the fancy gabled roof downward, hoping they would have an inspiration for how to build the foundation when they got to that point.

Moral: The smartest guy in the room needs to be managed just as much as the most ordinary. Otherwise they are liable to go off course and waste a bunch of time and talent, just like anyone else.

NASA's "Decline" is America's Triumph

On the day I was born, the only thing orbiting the Earth was the moon. By the time I was 5, however, the two most advanced nation-states had gotten men into orbit. This culminated, when I was twelve, in a manned moon landing. I recall very clearly how the entire world seemed to stop and take a collective breath as terrible, grainy TV pictures and prosaic radio traffic chronicled mankind's greatest technical achievement.

Fifty years on, only one more nation has launched men into orbit, and a coalition of european nations can send hardware into deep space. But the United States no longer launches men and women into orbit. We retired the Shuttle fleet after demonstrating that this task, while risky and expensive, could be performed routinely.

NASA has lost its way, some people say. America has lost its will, some people say. Another symbol of decline, say some.

I don't think so.

An American company called SpaceX, with only 1,100 employees, has learned to reliably launch payloads to orbit. Manned launches are close, held back mostly by concerns that their safety be more thoroughly demonstrated. A couple of other companies are close. Their cost per kilo to orbit is a fraction of that charged by the defense giants who assemble rockets for governments.

This result is astonishing. It means, here in the U.S. at least, we don't need the government to fund commercial activities in space. They fund themselves. It is a triumph of capitalism, almost unheralded. What it means is, the United States wasn't sitting on its hands for the last fifty years. We were investing in materials science, electronics, software, and all the things that actually make up a space mission. We were making launch capability reliable enough that companies would risk nine-digit bankrolls on activities in space. In the language of business, we built a reliable supply chain to space. This was something NASA knew we needed to do way back in 1980.

And where is NASA? Right where they should be, reaching out for another planet that we cannot yet grasp. Probably all other planets by the time we put boots on Mars. This year (2014), there isn't one part of a Mars mission that we really know how to do; keeping human beings healthy and strong on a long voyage; soft-landing a big payload on Mars; building a rocket on-site for the return to Earth. Some of these problems can be solved by brute force and expenditure of treasure. That's what NASA is for. And right behind are the entrepeneurs and their engineering teams, looking to finesse these problems to make it economical.

To those who say we should forget about space and spend NASA's budget to end poverty and hunger, I have this to say. Poverty exists by definition. It can't be eradicated in a society that rewards achievement. And NASA's budget could not banish hunger from the world for as much as a single day, especially where and when evil men wield hunger as a political weapon. President Kennedy had it just right when he said we do things like exploring space, "not because they are easy, but because they are hard." Mankind needs something to strive against, in order to make progress. What Kennedy didn't mention was that the problem of going to Mars is actually more tractable than the problem of ending hunger.

And to those who say manned exploration is frivolously expensive when robots can do it better, I say this. Who cares if there is an ocean on Titan if we will never stand on its shore? Why return pictures of Mars' dusty, cobbled plains if we will never walk them? Expanding mankind's reach is the only reason to visit space. We should only use robots where we cannot yet venture.

Mankind's conquest of orbit is nearly complete. The geeky men and women who will design, build, and fly the first manned Mars mission are in high school right now. They grew up in a world where manned space launches were so routine they only made the news by being so dramatically photogenic.

I expect to watch the Mars landing in beautiful hi-def color before I die of old age. Maybe on my wall-sized flat screen, maybe on my wristwatch. The men who landed on the moon were my father's age. The men and women who land on Mars will be my childrens' age.

So stop wasting time reading this and get to work!

One-Man Code Review

How do you do a code review if you are working alone? You obviously have already read your own code and found it beautiful. Code review fits into the development process as one means of getting feedback on the quality of the code you are writing. Basically, you increase use of all other tools that give the same kind of feedback.

• Turn the warning level of your compiler all the way up. Do a release build if you're using Visual C++ because the release build reports more errors.
• Install and run a static checker. CppCheck is a free static analysis tool. Coverity is a paid tool. LLVM has a static checker, or so I hear. If you have an expensive version of Visual Studio, there are static checkers, but I've never gotten to use one.
• Memory checking tools that find frees of invalid or already-free storage are built into visual studio and available for free for linux, and there's always valgrind if you're patient. 
• Write and run a set of module tests.
• Profiling tools produce results that may cause you to rethink your interfaces. Writing module tests forces you to use the API's you create, which often causes you to change things.