recent posts related to software development best practices

Apple design secret: Workplace, attitude, and productivity

Summary: An Apple design secret - the connection between attitude and productivity.

Unfortunately you need a subscription to read the content over at, but they had a nice article a while ago on "The Secret of Apple Design." I really like a quote they had about a person's attitude, and the relationship of that attitude and the impact on their work:

Apple's Tim Cook on quality versus revenue

Summary: This article shares a quote from Apple’s Tim Cook about products, quality, and revenue, and how it might help your business to think the same way.

I don’t remember exactly where I read the following quote from Tim Cook of Apple (it may have been at AppleInsider), but I made a note of it, and just ran across it again:

Business Analyst: How to write accurate software requirements

When you're working as a business analyst, the words you write are what you get paid for. Just like the author of a book, when you write software requirements, you shouldn't be loose with the words you write.

While working on a recent project, I started thinking about software requirements again, and was reminded how vague a requirement can be, even when you think it's well written. What made me think about this today was running across this performance requirement I found in an a requirements specification:

How to know when a software requirements specification process is done

Summary: How to know when a software requirements specification is complete by using Function Point Analysis techniques.

I've written dozens -- maybe hundreds -- of software requirement specifications over the years, and at one point in my career I learned an important little secret about knowing when the process of gathering requirements for a software requirements specification was really complete. Here's my secret.

If you could see bad code it would look like this

I was talking with a friend the other day about what bad software code ("smelly code") looks like, but I found it very frustrating. I ran into that a lot in my consulting career; it's hard to describe to a non-technical Project Sponsor or Project Manager why their existing code er ... isn't in great shape.

After that discussion, my friend -- who is an engineer and former electrician -- forwarded the following pictures to me, and asked if this is what smelly code looks like. I could only laugh and say yes, that is exactly what it looks like.

A software self healing pattern (part 1)

Over the last 18 months I've been working with a 24x7 manufacturing group, and no matter what I say, they always have the same two requests/demands:

  1. The software system must not fail, and
  2. If it does fail for some reason, it needs to be able to recover properly from the failure.

Simply put, (a) the machines must keep moving, and (b) nobody wants the phone call in the middle of the night when the machines stop moving.

Software metrics: A Tufte-inspired graph for software development projects

I couldn't sleep last night so I started reading Edward Tufte's "The Visual Display of Quantitative Information", and I started thinking about software project metrics that might be useful to the team members on a software development project (including developers, business analysts, domain experts, and stakeholders), and how I would show these metrics in simple but data-filled Tufte charts and graphs.

IT Managers - Why bad programmers are expensive

Dear Mr./Ms. IT Manager,

As the former owner of a very successful software consulting firm, here are several "truths" that you should know about the real costs of employing bad software developers (programmers):

Basic software development best practices

Software development best practices FAQ: Can you share some "software development best practices" you learned as the owner of a computer programming consulting firm?

Sorry, I don't have a lot of time for discussion today, but here's a brief list of the most important "software development best practices" I know, both for a software development organization, and your personal programming career: