
Why Good Developers Write Bad Code: An Observational Case Study [pdf] - danielalmeida
http://www.upedu.org/papers/ICSE2015_OrganizationalFactors/LavalleeRobillard_ICSE2015_WhyGoodDevelopersWriteBadCode.pdf
======
PaulRobinson
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.

~~~
ExpiredLink
That doesn't sound Agile.

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

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

------
munificent
"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!

------
arohner
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?

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

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

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

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

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

------
brianpgordon
Does anyone recognize which company this study examined?

------
trhway
your bad code is somebody else's good code.

~~~
crpatino
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).

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

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

~~~
davidjnelson
I wonder what going into sales would be like. You could try the other side of
the coin.

