Changes

(A short rant about eye-contact-based specifications.) In short, there is no such things as an eye-contact-based specification. And for a reason. While kicking-off of a project, we had a discussion with the customer about the change management approach, and specification detail.

Don’t you just love when users come up with new feature ideas at a microprocessor clock rate. Even before you finish developing one, five new requests pop up. This is a disease, and it’s called featuritis ! Featuritis doesn’t mean the features are just sporadically requested and developed ad hoc.

Methodology is a tough topic. There are good methodologies, there are bad methodologies, there are good methodologies gone bad. Methodology is not a silver bullet, it won’t just make any problems disappear, and is hardly ever the single source of success or failure. But a methodology can be a major contributor to success.

[Updated] I had to update this post a little bit, see below for the details, but the killer feature had to go 🙁 [/Updated] Remeber that tool “ Automated Version Management ” that I published here and on Mibuso five months ago? It has just got an update: version 2.0.

A few days back, while prototyping a new solution for a customer, one of the key users said: “But in our old software it didn’t work like that.” I was about to try to explain why the change, but then the user’s boss said: – We aren’t implementing a new solution so that everything can stay the way it was.