Reminder: Our Goal is to Produce Software
I’ve been in situations where I’ve seen process used, underutilized, misused, and abused all on the same project. The appropriate amount of process varies widely based on the needs of the project; it can be impacted by things such as the size of the team, the skills of the team, and the cost of an error. How do you determine the right level of process for your project?
Here’s my quick reminder: Process should exist to support the production of good software. If a process is a cost-effective method of producing good software, use it. If it is not, abandon it.
Here’s my quick reminder: Process should exist to support the production of good software. If a process is a cost-effective method of producing good software, use it. If it is not, abandon it.
posted by Anonymous at 9/04/2007 10:56:00 AM
2 Comments:
A product is bought only if it improves performance, as in the production of work. This is the real goal, not producing software.
Since IT programmers don't sell, they may believe that their software isn't bought, but it is.
In either case, the software must produce a return on investment that generates some real dollars even in the face of the TCO. Unfortunately, the TCO doesn't really tally what software costs in an operational setting. If the negative use costs swamp the positive use costs, the ROI is a mirage. Worse, the costs being embedding an organization by its software can kill the organization.
So beyond producing software, programmers produce cost structure. Most of this cost structure is invisible, particularly when the functional requirements negotiate away the ability to do real work without the maintenance of secondary systems to meet the real needs of the users or workers.
Producing software is too easy. Software can create more work for the production worker, embed costs into the organization, and destroy meaning.
The negotiation of meaning can only be done by moving to the general, the generic. It's pretty clear thought that software requirements end up negotiating around details for the sake of integration. This integration destroys meaning.
When you destroy meaning, you destroy thinking.
The production of software is not so benign. The goal of any software should be to increase competitive advantage, meaning, and reduce costs. Otherwise, you are producing software for yourself, not the business.
As far as getting rid of processes goes, new hires will just put it back if they got out of school believing it.
Moved this to a discusson on the message board:
http://www.seilevel.com/messageboard/showthread.php?p=3126#post3126
Post a Comment
<< Home