best-practices

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:

I've had some Function Point Analysis documents available here before, and recently finished converting those presentations into a better form for the internet. To that end I've gathered all these in a new Function Point Analysis Education Center, which contains those free documents and presentations.

These educational documents cover FPA, cost estimating, and even cost estimating for Agile software development projects.

If you've never read the book Use Case Driven Object Modeling with UML by Doug Rosenberg and Kendall Scott you're missing one of the most simple and important Model-View-Controller (MVC) diagrams in the software business.

In their discussion of Robustness Diagrams they introduce a figure called "Robustness Diagram Rules" that succintly tells you how to implement an MVC design in your code. In one figure they tell you:

Here are a couple of notes I just sent someone on how to get started writing a software requirements specification.

They may be a little vague, but I hope they show my intent, or perhaps my frame of mind, when writing a software specification.

Fred,

Here are two notes on my mental approach when writing software requirements specifications:

Here's a link to a Code Kata site. It discusses the importance of practice in the software industry. It seems like the basic theory is "If musicians and athletes believe that practice is extremely important, why don't developers (and organizations that develop software)?"

At the moment I'm not aware of any software organization that takes time out for skills practice, unless training on new products or languages counts ... and I don't think it does. Kudos.