best-practices

recent posts related to software development best practices

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

The “reduce, reduce, reduce” mantra applied to writing

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

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

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.

Four things I've learned from Jonathan Ive interviews

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 cost estimating - Cocomo model variables

Over time I hope to write more posts about software cost estimating, but for today I just want to list some of the software cost estimating variables from the model of the Cocomo II software application:

The magic of deadlines (Software best practices)

Wow, I've been reminded lately how important deadlines are.

I've been working on this website all summer, but at a moderate pace. Then recently I put together some goals for the end of the year, which, in turn, led to other short-term goals. Now, it turns out that my short term goals are hard to meet, but not impossible.