Hello all,
To wrap up this series about programmer/user chasm:
- Software is fundamentally easy to write. The skill consists in managing the complexity that arises from having a huge number of simple parts. (more)
- As a result, the knowledge to be transferred from user to programmer is much more than, say, from swordsman to blacksmith. (more)
- It’s largely because of this complexity that traditional project management methodologies don’t work well in software. (more)
- It’s also largely because of this complexity that traditional requirements-based contracts and time-based contracts create tension between client and contractor. (more)
- I’ve given an example of one of the things programmers do to work around these problems—measuring of “story points” and “team speed”. (more)
I could go on with the last point, but my purpose isn’t to write a treatise on good programming methodologies. It is only to give an example of things that need to be modified in traditional contracts. For this to happen, the contractor needs to understand the difficulties and the methodologies, and the client needs to be willing to step out of his “that’s the way we’ve always done it” habit of working with traditional contracts.
Regards,
Antonis