Why Good Developers Write Bad Code: An Observational Case Study [pdf] • Hacker News Board

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#11

Post by Delmania » Mon, May 18, 2015, 5:56 PM UTC

ExpiredLink wrote: post #6

PaulRobinson wrote: post #3

TL;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.

Really? Let's review: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. That's essentially a retrospective.

- In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. Role of the scrum master to remove impediments.

- Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parties. Previous bullet point.

- Make sure that testers are involved when negotiating with a third party for a potentially vulnerable software component. Testers are stakeholders in this, they should be there.

- Plan organization-wide process reviews to detect isolated processes and to promote information flows between processes. Removal of impediments.

- Planned special budget items to support long lasting corrections or corrections that are likely to benefit many modules. Got me on this one.

- 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

These last four are key elements of Scrum - managing the burn down, be flexible, and ensuring chickens can not interrupt the pigs.

Agile does not mean there is no process or formal rules. It's not a free for all, agile is about the ability to quickly respond to change.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#12

Post by sbov » Mon, May 18, 2015, 5:57 PM UTC

hinkley wrote: post #5

PaulRobinson wrote: post #3

TL;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.

I'm a fan of whys. Even for yourself. I have code I have to maintain that I wrote 10 years ago.

But it can make for long commit messages. Why also includes what alternatives you considered, and why you didn't use those.

I also like to have a digital "worksheet" for each change I do, where all my thoughts and research goes. So if all else fails, I can reference that. But no-one else can, so I like to transfer as much knowledge as possible to the commit message. At the same time, some of these go on for 5 or more pages. They also tend to be very messy. I'm not sure if it's all appropriate for a commit message.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#13

Post by x3n0ph3n3 » Mon, May 18, 2015, 5:57 PM UTC

tomswartz07 wrote: post #8

hinkley wrote: post #5

Earlier quoted context omitted.

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?

fixed indentation updated to pass new code linter

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#14

Post by amyjess » Mon, May 18, 2015, 5:57 PM UTC

tomswartz07 wrote: post #8

hinkley wrote: post #5

Earlier quoted context omitted.

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?

I could see the latter being something like "Apply coding standards", where somebody went in and fixed all the lines that went over the right margin or had wonky whitespace.

Of course, we can debate over and other whether mass-correcting existing files is actually helpful (one unofficial rule we have here is "only use the auto-formatter on code you've personally worked on or have taken over responsibility for", because it affects the blame history).

Also, I changed my name last year, and when I did that, I ran a mass find-and-replace to correct my credit in every Javadoc I'm credited on (I particularly detest my deadname, and I want it dead and buried), with the commit message being something like "Correct my credit to match my new name".

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#15

Post by pacaro » Mon, May 18, 2015, 5:59 PM UTC

tomswartz07 wrote: post #8

hinkley wrote: post #5

Earlier quoted context omitted.

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?

Guilty as charged. Or maybe 'nolo contendere'. I just dropped 5kloc, 6 weeks work, into a repo with the message "Initial commit"

I'm currently working on the changes that will actually document what is otherwise a walk of code.

The road to hell is paved with good intentions.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#16

Post by tomswartz07 » Mon, May 18, 2015, 6:02 PM UTC

pacaro wrote: post #15

tomswartz07 wrote: post #8

Earlier quoted context omitted.

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?

Guilty as charged. Or maybe 'nolo contendere'. I just dropped 5kloc, 6 weeks work, into a repo with the message "Initial commit" I'm currently working on the changes that will actually document what is otherwise a walk of code. The road to hell is paved with good intentions.

I could see that. Initial imports and all that.

However, my example was a project that was around for about 3 years at that point, and it was basically just labelled: "Upgrade to version 2.0".

Face → Palm

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#17

Post by mindcrime » Mon, May 18, 2015, 6:03 PM UTC

kyllo wrote: post #7

ExpiredLink wrote: post #6

Earlier quoted context omitted.

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.

> Standardized processes defined by committee like CMMI-ACQ and ISO12207 are pretty much the exact opposite of Agile, so, yeah.

Meh. All the Agile Manifesto really says about process is:

Individuals and interactions over processes and tools and Responding to change over following a plan

Nothing says you can't (or shouldn't) use a pre-defined process, or have a plan. If anything, the core of what "Agile" is, is about being flexible and responsive to change. As long as your process allows for that, it can be implemented as an Agile process even if it was created by a committee.

That's not to say that most firms using things like CMMI aren't doing it in a way that is far removed from Agile principles, but I blame that on the implementors more than the process. YMMV.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#18

Post by PirateDave » Mon, May 18, 2015, 6:03 PM UTC

tomswartz07 wrote: post #8

hinkley wrote: post #5

Earlier quoted context omitted.

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?

This just reminded me of whatthecommit. IIRC they get these from actual commit messages; if they do, there is no hope. :-)

[0] http://whatthecommit.com

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#19

Post by amyjess » Mon, May 18, 2015, 6:06 PM UTC

pacaro wrote: post #15

tomswartz07 wrote: post #8

Earlier quoted context omitted.

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?

Guilty as charged. Or maybe 'nolo contendere'. I just dropped 5kloc, 6 weeks work, into a repo with the message "Initial commit" I'm currently working on the changes that will actually document what is otherwise a walk of code. The road to hell is paved with good intentions.

I can one-up you there: one of my "initial commit" messages was a dedication to my cat, who passed away a couple of days before I checked the code in. Better yet, we released that project as open-source, so that commit message is still floating around Assembla for all to see.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#20

Post by amyjess » Mon, May 18, 2015, 6:08 PM UTC

PirateDave wrote: post #18

tomswartz07 wrote: post #8

Earlier quoted context omitted.

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?

This just reminded me of whatthecommit. IIRC they get these from actual commit messages; if they do, there is no hope. :-) [0] http://whatthecommit.com

I once saw a coworker commit a reshuffling of a project's directory structure with the message "YOLO". We made fun of him for a while for that.

(edit: He made this change after a lot of discussion with a bunch of people, and he also sent out a mass email describing the changes to the structure, so he wasn't totally being irresponsible there.)