software development

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:

Three golden rules for giving code reviews

Three golden rules for giving code reviews, from this article on sofiacole.com: 1) Ask questions rather than give statements, 2) Limit personal preference, and 3) Check its purpose.

Regarding the second rule, I don’t know anything about it, as I’ve never been on a team that allowed “personal preference.” Each team (or company) agreed on coding standards, and used them.

Notes on Apple’s Swift open source development

These are a few notes on Apple’s Swift open source development project, taken from this mailing list post by Apple’s Chris Lattner:

- Open source is pretty great. It has been incredible to see such a vibrant community working so well together, and to see you come together practically overnight.

- Open source also brings challenges.  I think it is fair to say that “open design” is slower and less predictable than “closed design”. However, the end result is significantly better, and therefore the tradeoff is worth it.

- Software scheduling (particularly with open source) continues to be difficult-to-impossible to predict.

- It is *good* to have high goals, but we need to do a better job of communicating that “goals” are not “promises” so that people don’t feel misled.

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.