The Cloud Shouldn’t Be Scary, Either…

Posted by Robert Merrill on March 18, 2013 under 100 Words | Be the First to Comment

Here’s what cloud computing means, in layman’s terms. You can go to Amazon Web Services and literally put computers in your shopping cart and they’re ready to use within a couple of minutes. When you’re done with them, you give them back.

So what? In layman’s terms, this isn’t like having a new laptop appear on your desk, ready to use. These cloud computers are servers, meaning they’re for other computers (increasingly, tablets and smartphones) to use, not for you to use directly. A techie has to make them useful. And there’s the problem. Read more of this article »

Making Software Better, Step 2: Get Serious About Internal Quality

Posted by Robert Merrill on March 11, 2013 under 100 Words, Agile Methods, Waterfall (SDLC) | Read the First Comment

One frustrating evening years ago, when I was a professional scientist and a self-taught programmer, I blurted, “Programming takes longer when I’m in a hurry than it does when I’m taking my time!”

Graph of Unit Cost against Quality; unit cost decreases with increasing quality for typical business software, and then cost rises sharply for the level of quality required for life-critical software. Due to a lack of internal quality, most organizations have higher software costs than necessary.I had stumbled upon what is sometimes called the Law of Software Quality.

Whoever said “Fast, Cheap, or Good—pick two!” started a dangerous lie. Unless it’s extremely simple software, to be used by its creator, once, and then deleted from the computer, improving quality makes the software less costly, not more.

OK, this isn’t true if you’re writing software where people could die if there’s a single bug (mistake) in it. That level of quality costs extra.

But for typical business software, there’s a sweet spot of quality, and most organizations aren’t there. Unless you have intentional quality measures in place, you can probably double your productivity by doing a little extra work of the proper sort at the right steps in the process.

So, why are effective quality practices not universal?

  • To uninformed outsiders, everything but typing looks like Extra Work. Budgets with tasks (as opposed to features) as line items invite cutting quality measures to save time or money (but it doesn’t work in the end). Feature-based budgets are better because they drive conversations about feature value and scope when “cutting to fit.” But if your organization has separate groups that do quality-related tasks, task-based budgets are hard to avoid. Many big shops are organized this way.
  • The most cost-effective quality measure, formal Inspection, isn’t as fun as programming. Lesser forms of requirements, design, and code review, while not as anal-retentive as Inspection, are less effective and still not as fun as programming. “The only problem we have around here is not enough meetings,” said no programmer, ever. Startups begin with just programmers (and maybe UI designers) and it’s easy to establish an inefficient code-and-fix culture and lay down a foundation of low-quality code that makes it hard for the business to pivot or scale up.

The first “quality measure” most firms introduce is Testing, in order to keep External Quality at an acceptable level. (External Quality is essentially, “does it work?”) The problem is that testing can only detect mistakes, not prevent or fix them, and then it can only detect certain kinds of mistake. Software can have high External Quality but still be made of Magic Spaghetti—poor Internal Quality.

Improving Internal Quality is where the payoff really happens. The reason why the quality curve looks the way it does is that tracking down mistakes in software is the most time-consuming form of Extra Work there is. It’s also hard to predict. Quality measures other than manual post-coding testing pay off because they detect mistakes relatively soon after they’re made, when they’re still easy to find.

Although I believe it’s easier for most teams to create high-quality software using an Agile method (I’m assuming this means automated testing, one of the Load-Bearing Walls of Agile), quality isn’t the main reason I prefer Agile. Regardless of methodology, introducing the right quality measures is a sure win.

Waterfall shops tend to use more formal requirements, design and code reviews, while Agile shops tend to use refactoring, supported by automated testing. Coding standards, especially naming conventions, are a good idea anywhere, provided they don’t trigger a religious war. Most languages have one or more de facto standards. Pick one and use it. Pair programming is the Agile form of code review. It catches a lot of mistakes but drives cost accountants crazy, unless they believe the quality graph. The most common review mistakes are reviewing too late and reviewing too much at once.

Another term for poor Internal Quality is Technical Debt. Like financial debt, it bears “interest,” in the form of extra time spent changing, enhancing, repairing, and upgrading a system that’s full of Magic Spaghetti and therefore hard to understand and change without making another mistake.

So whenever I have to help a firm Make Software Better, I first help them get a grip on their commitments. That frees up some time for them to introduce some quality measures. Those take time to gain traction. The longer the cycle time (time from gleam in the eye to feature in use), the longer it takes for the low-quality work in progress to clear the development pipeline and—gasp!—enter production, where it will continue to drive higher-than-necessary costs until remediated.

Making Software Better, Step 1: Get Control of Your Commitments

Posted by Robert Merrill on March 4, 2013 under 100 Words, Estimation, Process Improvement | Be the First to Comment

I’m writing for a typical client of mine—a software team of a half-dozen people, and the firm that pays them to do projects of a few months to a year in length. Let’s assume it’s you.

You want to get better at making software. You know that change is difficult and that there are no silver bullets. But you also know that you could be twice as good as you are now. (If you’ve never intentionally tried to get better at making software, I can almost guarantee it).

You’ve looked at “Software Process Improvement,” and your head is spinning. Where do you start? You may not even have a software development process. (Correction—you may not have an intentional software development process. The fact is, everybody has a process for everything they do, whether it’s making software or taking out the trash. It’s whatever they do now).

You want to make some simple (but not simplistic) changes, and you need to understand why they will probably work. (You will see below why this is important).

So you hire me and ask me what to do. Read more of this article »