recent posts related to software development best practices

Deming’s 14 Points for Management alvin October 30, 2017 - 4:18pm

Way back in the late 1970s and early 1980s the U.S. economy wasn’t doing very well, and Dr. W. Edwards Deming wrote about his 14 Points for Management as a way to improve the economy. (The image shown comes from that link at

Focus on the road, not the wall alvin September 16, 2017 - 11:06am

“When someone learns to drive a race car, one of the first lessons taught is that when you are going around a curve at 200 mph, do not focus on the wall; focus on the road. If you focus on the wall, you will drive right into it. If you focus on the road, you follow the road. Running a company is like that.”

~ Ben Horowitz, The Hard Thing About Hard Things

How I make very early software cost estimates (Part 1) alvin September 15, 2017 - 9:14am

Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.

The problem

Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.

The solution

I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:

The “reduce, reduce, reduce” mantra applied to writing alvin February 23, 2017 - 3:31pm

One philosophy I have about writing technical material is that I want to condense the material as much as possible, to the point where I want people who use yellow highlighters to mark most of what I write. I am one of those people who use yellow highlighters, and I look for that property in books that I read.

This isn’t necessarily true for blog posts that I write, because for these I usually write them pretty fast. But for books, I take the time to review them and look for this quality. This follows the design mantra, “reduce, reduce, reduce.”

An intense curiosity about how things are done alvin January 29, 2017 - 9:13am

In his book, The Universal Tone: Bringing My Story to Light, Carlos Santana writes about hearing other guitar players, and wondering with an intense curiosity how those other people got their guitars to make the sounds they made. As I thought about this I thought it was a good attitude to have in programming. For instance, if I look at an application where someone has done something really cool I try to understand, “How did they do that?”

Software best practice: Never say “X% done”

Note: This is a post from 2007 that I just updated a little bit because I think there’s still some value in it.

A lot of people have written to say that it’s unfair that I think developers should never say “I’m 75% done,” or “I’m 90% done.”

So, to explain myself, here’s why I think you should never use a phrase like that:

One thing a business analyst should ask about any requirement alvin October 22, 2016 - 10:49am

As a business analyst (or any person interested in writing software requirements and quality), there is one thing you should always ask yourself whenever you write a business requirement:

Is this software requirement testable?

I’ve seen some business analysts write some crazy things and call them requirements, but IMHO, if you can’t test it, it’s not a requirement.

Quotes from Clean Code

I just finished reading the book Clean Code by Robert C. Martin, and in an effort to keep that book alive with me a little while longer, I decided to make my own “Cliffs Notes” version of the book on this page.

Writing clean code

Here's a short collection of quotes from Clean Code, with my comments added after each quote.

“Later equals never.”

Four things I've learned from Jonathan Ive interviews alvin November 11, 2012 - 7:52am

With Apple's iPad 3 announcement coming tomorrow (March 7, 2012), I took a few minutes last night to reflect on various Jonathan Ive interviews I've read over the years. Here are a few notes on what I learned by reading those interviews.

Software development process standard operating procedures alvin August 30, 2011 - 9:48pm

Some long time ago I was working on a software development project, and I wasn't happy with either the quality or the velocity of our programming effort. So one night I sat down and tried to work out an activity diagram to show what our software development process needed to be, to improve both speed and quality. It turns out that a lot of this is just common sense, but for some reason or another team members would try to circumvent the process, which always led to more pain for everyone involved.