Sussman attains enlightenment reads:

In the days when Sussman was a novice, Minsky once came to him as he sat hacking at the PDP-6. “What are you doing?”, asked Minsky. “I am training a randomly wired neural net to play Tic-Tac-Toe” Sussman replied. “Why is the net wired randomly?”, asked Minsky. “I do not want it to have any preconceptions of how to play”, Sussman said. Minsky then shut his eyes. “Why do you close your eyes?”, Sussman asked his teacher. “So that the room will be empty.” At that moment, Sussman was enlightened.

As with artificial intelligence, there is little point presupposing what a real intelligence will or won't think. To know what a person is thinking and what motivates them, it is helpful to ask. Then, observe their actions to see where the words and actions hold together or where they take different paths.

If management rewards lines of code for the sake of lines of code, then the programmers will gladly produce the lines of code the management requested. This is not the programmers gaming the system. This is the programmers producing what is asked of them.

If the management asks for high bug fix rates, they will be provided buggy software with lots of bugs to fix. This is not the programmers cheating the metric. This is the programmers giving management what management requested.

If what the management really values is small, maintainable, minimally buggy code then management should damn well ask for small, maintainable, minimally buggy code. Then management should allow developer and tester time to the task of designing, developing, refactoring, reviewing, and testing code. Make sure the developers and testers feel safe to criticize one another's work and more importantly feel safe to have their work criticized.

Let me take a particular agile framework as an example. I feel the reason Scrum works so well has less than the progenitors of it think to do with the regularity or exact length of the meetings, although touching base together briefly and regularly is a great thing. I think the biggest factors they got right are the self-managing team that answers as a single unit and having that unit submit their work to a single vision. A good product owner who can stand in the gap between the customer and the development team, and who accepts the work of the team to present to the customer for their acceptance is the secret ingredient in the sauce.

I've seen some complaining around the net about Scrum as having a high overhead. Well, that's true compared to some small teams but it buys a great deal of value for that overhead. One needs to communicate frequently to be truly agile and adjust frequently. One needs to have an at least partially fixed spec for a while to produce something of value without confusion, even if that spec is a bit nebulous and only stays fixed this two-week iteration. The team needs to lean on one another and mentor one another to prevent fortresses of individual skill and knowledge. Those fortresses fall hard when the team is realigned, and can bring down projects or even companies. It is best to prevent them.

Agile development is about getting the minimum work done to meet a quality and completeness goal as quickly as possible. There's a maxim we should all know by now: "Fast, cheap, good: pick two". There's no way to get good software fast without a little overhead cost. Scrum I think balances the cost to the benefit pretty well.