software

How I make very early software cost estimates (Part 1)

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:

MacOS screen annotation/presentation software

I was going to write a little application to let me annotate my MacOS screen during presentations, but the Ink2Go product looks like it does exactly what I was thinking. As I’m creating a video presentation, such as when showing how to write some Scala or Android code, I want to be able to draw on the screen, such as writing text, arrows, circles, and boxes to highlight parts of the screen. Ink2Go looks like what I want.

The karma of bad software documentation

Tried to use someone’s software library.
Documentation was bad, couldn’t get it to work.
Used someone else’s.

#haiku-ish

MacOS softwareupdate command (how to ignore updates)

I just learned that MacOS has a softwareupdate command, and further learned that it has a --ignore option, which may or may not let you ignore useless updates. For example, my Mac prompts me daily to update Keynote, Numbers, and Pages, which I rarely (rarely!) use, so I don’t want to bother updating them. I’m hoping the a softwareupdate command will help me with this.

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:

Balancing development desire with product goals

This oreilly.com article about balancing quality and product features (from the perspective of a CTO/CIO) is a good read. The editor’s note states, “This is part of a series exploring the trials and tribulations of first-time managers. Camille Fournier, former CTO at Rent the Runway, is often asked for advice on how to make the transition from an individual contributor to a manager.”

Software bugs help doom Japanese black hole satellite alvin July 7, 2016 - 1:28pm

In another example of a high-profile software quality problem, Gizmodo reports that a Japanese satellite that was meant to observe black holes was doomed by poor software quality:

“It was only up there a month when something went wrong. A series of unfortunate events caused by both human errors and software flaws sent the satellite spinning out of control.”