In favor of asking hard questions

I am in favor of asking hard questions. A lot can go assumed. No stone should be left unturned. It’s wise to think ahead and it’s the professional who makes sure that there are measures in place for anything that can go wrong.

Still, there’s friction to fight when asking hard questions. The person who asks hard questions might be seen as a troublemaker. Or less insidious, it’s easy to hurt other team members’ feelings. Someone who put a lot of work into a feature only to hear questions about it might not appreciate that.

Sure, I don’t want to rock the boat. I also don’t want anyone on my team to feel bad. But more than all of that . . .

Cloud-cliparts-free-clipart-images

The cloud is just other people’s computers

When you read the word “cloud” you should just mentally strike it out and insert “other people’s computers.” For example, AWS has a page titled, What is cloud computing? with the following definition:

Cloud computing is the on-demand delivery of compute power, database storage, applications, and other IT resources through a cloud services platform via the internet with pay-as-you-go pricing.

line_squall_35323_md

This should be rewritten as:

Cloud computing is the on-demand delivery of compute power, database storage, applications, and other IT resources through a cloud services platform other people’s computers via the internet with pay-as-you-go pricing.

The value of the “cloud” doesn’t come out of the idea of using other people’s computers, though. The real value is from the tooling built into a given cloud platform. We don’t get much benefit just from using other people’s computers. But if we can use other people’s computers only when we need them, that’s valuable. That’s how a company can meet demand elastically. It’s how they can keep their site up for all the shoppers on Black Friday without spending millions the rest of the year for infrastructure that is sitting idle.

Handy guide to Classic / Waterfall Software Teams in the Real World

So, you’ve graduated with your computer science degree and now you landed your first job! You’ve joined an aerospace, government, or financial industry firm, which means you’re going to be doing waterfall. You might be wondering who is responsible for what on your new software team. Let me just translate that textbook understanding you now have a little bit to the real world, so that you can understand who is who when you see them.

Waterfall software team according to textbooks…

Handy guide to Agile Software Teams in the Real World

So, you’ve graduated with your computer science degree and now you landed your first job! You’ve joined a true software industry (Silicon Valley?) company, which means you’re going to be doing agile! You might be wondering who is responsible for what on your new software team. Let me just translate that textbook understanding you now have a little bit to the real world, so that you can understand who is who when you see them!

Agile software team according to textbooks…

northern_lights_iss_20131009

Why software teams that are on time and on budget probably suck

Many people in the software industry are bad at their job. Probably more than in other industries. Plenty of data shows the abysmal results of software projects, but you can simply ask your nearest software professional for plenty of horror stories. I have more than ten years of experience “on the inside” of the software industry and I have found bad software teams everywhere I look.

Bad managers have a disproportionately high impact on software because bad managers build bad teams, but the individuals on the teams themselves—even the good ones—are, more often than not, complicit in and even the cause of bad software. But what is most surprising is that bad teams are almost always rewarded for their incompetence. They “meet deadlines” so they are considered to have delivered “results.”

And what’s wrong with delivering results? . . .