15 ms·

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

173 points by danielalmeida 11y ago

vkjv 11y ago
Interesting, but for me, there's a key piece missing. What did they use to determine that a developer was "good" to begin with?
- acqq 11y ago
  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.
- Dewie3 11y ago
  It's an attempt at a catchy title by appealing to the 10X developer belief/archetype.
PaulRobinson 11y ago
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 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.
- hinkley 11y ago
  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.
  - tomswartz07 11y ago
    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?
    - x3n0ph3n3 11y ago
      fixed indentation updated to pass new code linter
      - hinkley 11y ago
        That's still a why. An irritating one, sure, but it at least tells me to look at the previous commit to find the real 'why'.
    - amyjess 11y ago
      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".
    - pacaro 11y ago
      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.
mpdehaan2 11y ago
Offhand and IMHO, some possibles can be: - fear or lack of understanding of a legacy codebase - fear or lack of understanding of a 3rd party component - time pressure - too many edge cases to handle - intra-team communication issues or stylistic differences - lack of domain experience to understand those edge cases - lack of time to build the correct design, or rebuild a design if it won't fit - project management pressure against big-design-up-front and to "start now" when making something more organized is required - unclear requirements - not interested in work or company anymore - lack of use cases representing all possible usage scenarios - it's actually not their code that was bad, but they are coupled to bad systems that are themselves bad/leaky/error-prone
user_rob 11y ago
To mitigate these problems I try to always completely finish the current task including doc updates etc before moving to the next thing. I do this pretty much always even under management pressure. It can be awkward at times.
paulhauggis 11y ago
I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneath, they often times don't see the difference and when they explain to the boss that they might lose money, it's almost always option #2. I hated being forced to do this so many times in my career, I started my own company.
- fragsworth 11y ago
  > I hated being forced to do this so many times in my career, I started my own company. It depends a lot on what your company is doing, but for the most part, you'll probably discover that cutting corners to save your short-term time is often the right thing to do.
  - arenaninja 11y ago
    This is definitely true in the interest of shipping anything. The problem is when new features are added to the thing that shipped, small refactorings should make it a manageable beast. Instead, <rant>you end up chasing bugs across six different files and fixing the entire thing will take a week and a half of your time because it involves moving things out and straightening the screwup that went on for three days before anybody noticed, so they insist you live on with the bug and keep chasing bugs down as they occur</rant>
  - mathattack 11y ago
    Indeed. Very frequently "getting it out the door" can mean enough money to hire a great developer vs just a good one. There are salespeople whose over-promising causes more harm than good, but it's not black and white.
  - s73v3r 11y ago
    Bullshit. Most of the time the corner cutting is done solely because shithead sales drones make promises without consulting engineering in the slightest. They get a huge commission for getting the sale and go home at the end of the day. We have to put in more late nights to cover for their asses, and we barely get anything for a raise because of that one time we weren't able to meet sales physically impossible promise.
deleted 11y ago
[deleted]
lifeisstillgood 11y ago
For me it's simple: 1. Lack of risk management 2. Poor project management 3. Allowing other to set my urgency (like deadlines but more psychological) 4. Not enforcing professional practises I know I should follow 3 and 4 are to all intents and purposes symptoms of 1 and 2
arohner 11y ago
An interesting article, and we need more like it, but I feel the author didn't go far enough in understanding the root causes of complexity. For example, they cite both schedule/budget pressure, and insufficient docs. The incomplete docs were "thousands" of pages. Does anyone really believe even half the team would read "complete" documentation, that are thousands upon thousands of pages? Would complete docs speed up development time? Would they speed up development time even taking into account the cost of producing and consuming complete docs? Is the size of module truly essential complexity, or is part of the problem that they're building on legacy code? The author mentions interop with other teams and third party software as a large source of friction. Why are other modules so large and complex that they're maintained by separate teams? Is that essential complexity, or was it caused by previous attempts to patch their way to release? Would the modules be more manageable, and hence, require smaller teams, if they used other practices/languages/tools? Access to test hardware, and managing the test personnel was another source of friction. What is the cost of buying more test hardware? In previous companies where I've worked, with manual QA depts and under-funded test hardware budgets, doubling the hardware budget would allow halving the QA salary budget (primarily because you don't need to hot-swap equipment several times a day), and shorten test cycles. Is that the case here? Further, how much manual test is truly necessary, and how much is caused by the developers not writing automated tests?
trhway 11y ago
your bad code is somebody else's good code.
- crpatino 11y ago
  I'd put it rather like... for any reasonable definition of "good code" and a sample that highlights the characteristic features of such good code, you will find a competent, intelligent developer that will consider it bad. Which is more or less the same thing, except that IMHO it does not suggest that every bad code shall be "good" for someone. There's such thing as code that is universally considered as awful (but for their creators, maybe).
brianpgordon 11y ago
Does anyone recognize which company this study examined?
munificent 11y ago
"The project was a second attempt to overhaul this complex Module. A first attempt was made between 2010 and 2012 but was abandoned after the fully integrated software did not work. Because this project was a second attempt, many specifications and design documents could be reused. Accordingly, the development has essentially followed a waterfall process, as few problems were expected the second time around." I love the sheer insanity of this. 1. Write up a plan. 2. Execute the plan. 3. Total project failure. Abandon it. 4. Decide to try again. 5. "It will be easy this time! We've got an existing plan we can use!" It's like using a treasure map, not finding any treasure, and now thinking it will be even easier to find the treasure now since you already have a map!
meapix 11y ago
Good code doesn't take more time than bad code. I think bad code takes more time than good code.

173 points by danielalmeida 11y ago

vkjv 11y ago

Interesting, but for me, there's a key piece missing. What did they use to determine that a developer was "good" to begin with?

acqq 11y ago
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.
Dewie3 11y ago
It's an attempt at a catchy title by appealing to the 10X developer belief/archetype.

PaulRobinson 11y ago

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

hinkley 11y ago
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.
- tomswartz07 11y ago
  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?
  - x3n0ph3n3 11y ago
    fixed indentation updated to pass new code linter
    - hinkley 11y ago
      That's still a why. An irritating one, sure, but it at least tells me to look at the previous commit to find the real 'why'.
  - amyjess 11y ago
    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".
  - pacaro 11y ago
    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.

mpdehaan2 11y ago

Offhand and IMHO, some possibles can be: - fear or lack of understanding of a legacy codebase - fear or lack of understanding of a 3rd party component - time pressure - too many edge cases to handle - intra-team communication issues or stylistic differences - lack of domain experience to understand those edge cases - lack of time to build the correct design, or rebuild a design if it won't fit - project management pressure against big-design-up-front and to "start now" when making something more organized is required - unclear requirements - not interested in work or company anymore - lack of use cases representing all possible usage scenarios - it's actually not their code that was bad, but they are coupled to bad systems that are themselves bad/leaky/error-prone

user_rob 11y ago

To mitigate these problems I try to always completely finish the current task including doc updates etc before moving to the next thing. I do this pretty much always even under management pressure. It can be awkward at times.

paulhauggis 11y ago

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneath, they often times don't see the difference and when they explain to the boss that they might lose money, it's almost always option #2. I hated being forced to do this so many times in my career, I started my own company.

fragsworth 11y ago
> I hated being forced to do this so many times in my career, I started my own company. It depends a lot on what your company is doing, but for the most part, you'll probably discover that cutting corners to save your short-term time is often the right thing to do.
- arenaninja 11y ago
  This is definitely true in the interest of shipping anything. The problem is when new features are added to the thing that shipped, small refactorings should make it a manageable beast. Instead, <rant>you end up chasing bugs across six different files and fixing the entire thing will take a week and a half of your time because it involves moving things out and straightening the screwup that went on for three days before anybody noticed, so they insist you live on with the bug and keep chasing bugs down as they occur</rant>
- mathattack 11y ago
  Indeed. Very frequently "getting it out the door" can mean enough money to hire a great developer vs just a good one. There are salespeople whose over-promising causes more harm than good, but it's not black and white.
- s73v3r 11y ago
  Bullshit. Most of the time the corner cutting is done solely because shithead sales drones make promises without consulting engineering in the slightest. They get a huge commission for getting the sale and go home at the end of the day. We have to put in more late nights to cover for their asses, and we barely get anything for a raise because of that one time we weren't able to meet sales physically impossible promise.

deleted 11y ago

[deleted]

lifeisstillgood 11y ago

For me it's simple: 1. Lack of risk management 2. Poor project management 3. Allowing other to set my urgency (like deadlines but more psychological) 4. Not enforcing professional practises I know I should follow 3 and 4 are to all intents and purposes symptoms of 1 and 2

arohner 11y ago

An interesting article, and we need more like it, but I feel the author didn't go far enough in understanding the root causes of complexity. For example, they cite both schedule/budget pressure, and insufficient docs. The incomplete docs were "thousands" of pages. Does anyone really believe even half the team would read "complete" documentation, that are thousands upon thousands of pages? Would complete docs speed up development time? Would they speed up development time even taking into account the cost of producing and consuming complete docs? Is the size of module truly essential complexity, or is part of the problem that they're building on legacy code? The author mentions interop with other teams and third party software as a large source of friction. Why are other modules so large and complex that they're maintained by separate teams? Is that essential complexity, or was it caused by previous attempts to patch their way to release? Would the modules be more manageable, and hence, require smaller teams, if they used other practices/languages/tools? Access to test hardware, and managing the test personnel was another source of friction. What is the cost of buying more test hardware? In previous companies where I've worked, with manual QA depts and under-funded test hardware budgets, doubling the hardware budget would allow halving the QA salary budget (primarily because you don't need to hot-swap equipment several times a day), and shorten test cycles. Is that the case here? Further, how much manual test is truly necessary, and how much is caused by the developers not writing automated tests?

trhway 11y ago

your bad code is somebody else's good code.

crpatino 11y ago
I'd put it rather like... for any reasonable definition of "good code" and a sample that highlights the characteristic features of such good code, you will find a competent, intelligent developer that will consider it bad. Which is more or less the same thing, except that IMHO it does not suggest that every bad code shall be "good" for someone. There's such thing as code that is universally considered as awful (but for their creators, maybe).

brianpgordon 11y ago

Does anyone recognize which company this study examined?

munificent 11y ago

"The project was a second attempt to overhaul this complex Module. A first attempt was made between 2010 and 2012 but was abandoned after the fully integrated software did not work. Because this project was a second attempt, many specifications and design documents could be reused. Accordingly, the development has essentially followed a waterfall process, as few problems were expected the second time around." I love the sheer insanity of this. 1. Write up a plan. 2. Execute the plan. 3. Total project failure. Abandon it. 4. Decide to try again. 5. "It will be easy this time! We've got an existing plan we can use!" It's like using a treasure map, not finding any treasure, and now thinking it will be even easier to find the treasure now since you already have a map!

meapix 11y ago

Good code doesn't take more time than bad code. I think bad code takes more time than good code.