Why Good Developers Write Bad Code: An Observational Case Study [pdf]
1–10 of 85 posts
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#2Interesting, but for me, there's a key piece missing. What did they use to determine that a developer was "good" to begin with?
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#3TL;DR key recommendations:
- Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented.
- In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams.
- Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parties.
- Make sure that testers are involved when negotiating with a third party for a potentially vulnerable software component. 
- Plan organization-wide process reviews to detect isolated processes and to promote information flows between processes.
- Planned special budget items to support long lasting corrections or corrections that are likely to benefit many modules. 
- Projects with strict deadlines are risky, and should be carefully monitored to avoid last minute unplanned activities.
- Team members should maintain a careful balance between the flows of information within formal development processes and informal human interactions.
- Team members should make sure that knowledge is appropriately distributed amongst them. For example, pair programming is a practice which can promote knowledge sharing.
- Any intrusion into the team dynamics by outsiders should be done very carefully.
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#4Interesting, but for me, there's a key piece missing. What did they use to determine that a developer was "good" to begin with?
If you read the text you can see that it's not even important if the developers are "good," the internal policies limit what even the best developers can do.
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#5TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…
I get really crabby about bad commit messages because on some projects, the commit history is the only 'Why' you ever get.
Scratch that, on MOST projects that's the case.
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#6TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…
That doesn't sound Agile.
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#7TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…
That doesn't sound Agile.
Standardized processes defined by committee like CMMI-ACQ and ISO12207 are pretty much the exact opposite of Agile, so, yeah.
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#8TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…
I get really crabby about bad commit messages because on some projects, the commit history is the only 'Why' you ever get. Scratch that, on MOST projects that's the case.
There's nothing worse than a project full of bad commit messages.
There was one project I saw that had a two line commit message, and there were 29,000 changed lines across 44 files. Who does that?
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#9TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…
That doesn't sound Agile.
[deleted]
Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]
#10TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…
That doesn't sound Agile.
I don't have enough context to determine your tone. Are you saying that the above suggestions are not Agile, and so are not compatible with Real Software Development (or at least default to that state)? Or that the above list brings into question the Agile methodology? Or something else entirely?
I'm very interested in the processes of developing good software so I hope there is some good discussion around this paper.