Posts in the “best-practices” category

Business Analysis: One question 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.

Software best practice - Don't be a Pigpen developer


A lot of times I'm asked about software best practices, but sometimes it's easier to show a best practice by showing its opposite -- a "worst practice". With that, today I introduce you to a worst practice I call "The Pigpen Developer".

Sophocles: One learns by doing the thing

I was reading Dr. Dobbs last night, and they referenced this story about how quantity ends up producing quality, at least when it comes to humans creating things.

The lesson goes like this: A ceramics teacher divides a class into two teams, then tells one team they'll be graded by sheer quantity, while the other side has to produce one great pot. In the end the Quantity Team delivers all the best quality pots.

I've found this to be true with new programmers. All newbies want to learn about things like design patterns, but what they really need to do is just sit down and write a lot of code.

This reminds me of the quote, "One learns by doing the thing." I don't know for sure who said that — possibly Sophocles — but I remember reading it in a Thermodynamics book in college, and I've never forgotten it.

A software self healing pattern (part 1)

(Note: I originally wrote this article in 2010 or 2011, but I tend to like articles that I wrote while in the midst of a ton of design, programming, and testing work, and this is one of them.)

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.

Function Point Analysis resources (FPA)

As I was just cleaning up around the website lately, it looks like I never linked up to some of the software cost estimating and Function Point Analysis (FPA) tutorials and slide shows I've created. So without any fruther ado, here are some links to my free FPA tutorials and presentations:

For more information on Function Point Analysis, I recommend looking at the International Function Point User's Group (IFPUG) web site. IFPUG is the non-profit organizational body for the FPA industry, and provide certifications, such as my former Certified Function Point Specialist (CFPS) certification. (I let that expire, as I don't have an interest in counting function points in general, just for applications that I'm involved in developing.)

Focus on the road, not the wall

“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

While driving through the mountains in Alaska and Canada in the winter, you learn a similar lesson: Focus on the road, not falling off the cliff. :)

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 self healing pattern, part 3

Software healing component #3: The self healing program

In the first two parts of this tutorial I wrote about a worker program, and the functionality it needs to provide to support a self-healing architecture. In the second part I wrote about an open source program named Nagios, which can be used to monitor your worker programs. In this third part of the self-healing recipe, I will now write about what is necessary for the "healing" component.

Software self healing pattern, part 2

Component #2: The software monitoring program

The second piece of the self-healing architecture is to have a program that monitors your worker programs. You can write your own software monitoring program, as I did many years ago, but that's pretty old-school, and frankly, not a good idea any more.

Software rot, too much magic, and spaghetti code - the Kirk/Scotty syndrome

There is a disease I see so often in the software development industry that I've decided to give it a name. I call it "Kirk/Scotty Syndrome". This disease is related to the concept of "software rot" and "spaghetti code" inflicted by the management team. You'll know this disease when you hear it, because it will sound a lot like the following conversation, taken from most Star Trek episodes:

Relationship between software quality and the distance between programmers and users

In the software development industry, the physical distance between developers and users is an important, often-overlooked variable to the success of a project. I'm currently working on a project where my development team is several hundred yards away from our users, and we're also in another building. Because developers don't seem to like telephones, or perhaps don't like talking to other people that aren't developers, I contend that this 300 yards could easily be 30 miles.

Bad things happen when developers don't communicate

I was recently reminded of the danger of leaving less-experienced software developers alone to create new functionality in a technical area where they have no prior experience. For instance, suppose you have one or more good but less-experienced developers, and you ask them to work in a technical where they have no prior experience. These aren't totally inexperienced developers; they may each have at least five years experience. Given that their are other people on the team with experience in this area, how do you think this should be handled? Choices include:

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:

Using UML: The usefulness of UML diagrams

Following a speech two days ago, I'm struck by how very little we use the Unified Modeling Language (UML) on our software projects. Occasionally I'll create some activity diagrams to model how users get their tasks done, but that's about it. Typically when we create a software requirements specification this is what we deliver:

Software cost estimation

The last few weeks I've been looking at ways of estimating software development projects using "Use Cases". I'm all over Use Cases -- I think they represent a good way to document the flow of an app, but a significant problem with them is that your use case is not the same as my use case, even for the same subset of an application. This leads into many problems estimating how much it's going to cost to develop a software app.

The "freemium" business model - best practices

It's so rare that a CEO talks in detail about how their company generates revenue that I want to take a moment and share this TechCrunch link, which covers Evernote CEO Phil Libin's presentation at a meeting named Founder Showcase. Mr. Libin discussed some of the elements of making the "freemium" business model work.