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

http://www.upedu.org/papers/ICSE2015_OrganizationalFactors/LavalleeRobillard_ICSE2015_WhyGoodDevelopersWriteBadCode.pdf

by danielalmeida • 11 years ago

173 80 11 years ago

vkjv• 11 years 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• 11 years 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• 11 years ago

It's an attempt at a catchy title by appealing to the 10X developer belief/archetype.

PaulRobinson• 11 years 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.

hinkley3• 11 years 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.

tomswartz073• 11 years 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?

sbov• 11 years ago

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.

Terr_2• 11 years ago

IMO most of your "why" ought to be code-comments, not commit-messages, because most of the time people say: "Why is this code this way" as opposed to "Why did this specific transition occur in the past".

ExpiredLink• 11 years ago

That doesn't sound Agile.

kyllo• 11 years ago

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

pc862• 11 years ago

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.

Delmania• 11 years ago

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.

dheera• 11 years ago

I think there are a lot of conflicting ideas at play here. As a coder, yes I can write good code. But however, everyone I know in the valley tells me "just shut up and launch, it doesn't have to be good. You should have launched yesterday, that's what they would have told you at YC". This advice have a lot of truth to it, because you need to get feedback, validate your project, and perhaps have the first-to-market advantage in the highly competitive world of technology today, with investors and customers hounding you on both sides. However, this hasty, rushed culture necessarily will result in a lot of poorly-written code being deployed (followed by a lot of rewrites), even by decent coders, because they simply aren't given the time and runway.

bgoerdt• 11 years ago

The situation is very different when creating software for internal use in large corporations, which I think was the case with this study. With a startup, launching early can get you the advantages you mentioned, and your code quality does not necessarily have to be high because you generally will not have many users at the start. Large internal software must be highly functional and performant from the first deployment because it will immediately be used by the whole company and will often affect revenue streams. This allows low quality to have a huge impact from day 1.

mikekchar• 11 years ago

If you write code that solves a people problem and allows your project to move forward, no matter how stinky that code is, that code is "good code".

By nature, we programmers often judge our code on its technical merits. But a stinky piece of crap that I might write that shows me clearly what I need to build, or demonstrates the techniques that are required, or shows that something isn't going to work early, etc can have immense value.

Writing stinky code is a tool that every programmer can use. The trick is to know when you should use it and when you should not. If done properly, you can solve some intractable problems dealing with requirements gathering, design, or even political problems. When used improperly it can have exactly the opposite effect -- it pushes requirements gathering back, or defers important design decisions until it is too late, or creates conflict within the team.

I know some people in the industry who are pretty good at this, but I know of nobody who is a master at it. Not only do you need to be good at it personally, you need to be able to influence the team to coordinate their work in a way that is not destructive. This requires you to have impeccable taste, amazing technical ability and sublime communication skills. It is a skill that I wish more programmers would value and work towards.

mpdehaan2• 11 years 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• 11 years 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.

paulhauggis2• 11 years 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• 11 years 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• 11 years 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• 11 years 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.

s73v3r2• 11 years 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.

angersock• 11 years ago

It depends, right?

It's right to the biz side of the house, because they have no idea what the costs of those cut corners are. They just know that they asked for shiny feature X, and then that shiny feature X was delivered, albeit with a complaint that the codebase was now Y harder to work on.

Rinse and repeat, and their interface is still "Oh, well, if I ask, the engineers will make it happen".

As this goes on, though, the engineers incur costs and suffering in order to keep delivering. And for any developer worth their salt, there is a very real cost--I almost want to say psychic and emotional trauma--associated with working on bad code.

And these engineers? Odds are, they have no big stake in whether or not the feature works. They're paid (badly) the same way either way, and don't get any benefit whether or not the new feature works.

So, they'll just leave when the continual cost of dealing with a shitty codebase outweighs the benefits of staying at that company. And they'll probably be rewarded with more money for switching!

The incentives are all wrong, and then one day your sales folks realize that any request suddenly takes waaay longer than is acceptable.

amag• 11 years ago

This all depends of course of the definition of "cutting corners". Sometimes one person's "cutting corners" is another person's "striving for excellence" and sometimes it's "run project into oblivion".

All too often the short-sighted "quickest" way forward is through copy-paste some code that does something remotely similar and massage it into giving the desired output. Sometimes this is necessary, but a lot of times it is not. And every time it leads to technical debt. I've worked on a lot of code bases like this: "Copy file x, rename copy, add copy to project file, rename global names, massage into y, rinse repeat". And then you find a bug in x.

Developers are typically too far removed from customers to ever know, but often the customer is just using time as a bargaining chip. Everybody wants all their needs filled right this instance but most people are reasonable enough to know that the universe doesn't work that way. You just need to gently remind them of it and they will respect you all the more for it, at least if you then deliver quality on time.

Of course this is harder with customers who believe they know a thing or two about development. In their mind it's just change the output of x, but what they don't know is that because you cut corners in the past, you'll need to change the output in y, z, x2, x3, y2, z3 and zz as well...

paulhauggis2• 11 years ago

If there is an emergency situation where I need to apply a hack, of course. But, I always go back and take the time to fix it with an engineered, long-term, solution.

I also don't over promise features in an un-realistic amount of time.

silverbax882• 11 years ago

I will tell you, as someone in the same position, that even when you get all of the time you need, and you write elegant, beautiful code, in five years that code will probably seem clunky and outdated, and someone will ask you what the heck you were thinking when you wrote it.

juliangregorian• 11 years ago

After five years, you'll probably ask that of yourself! But if I was really given all the time I preferred, I'd have brought the code current with my ideals.

ploxiln• 11 years ago

So, there's no such thing as good quality code that saves time in the long run? So we should just give up and hire some cheap overseas contractors because the result will be the same?

To anyone except an MBA running a software project for the first or second time, that's pretty obviously not true. (Some people, when they realize this, do "additional process will be mandated until quality improves".)

mesozoic• 11 years ago

Observationally this seems why sales driven organizations might have trouble keeping good developers. They force the build up of so much technical debt and never give the time to fix it that the good developers just leave rather than maintain the nightmare of code they've had to write.

0xdeadbeefbabe• 11 years ago

Are you implying logic driven companies exist?

themodelplumber• 11 years ago

This weakness in sales-driven organizations applies to other types of employees, too. I used to be a graphic designer for one such organization, and it was next to impossible to create marketing collateral based on design standards; they'd rather buy it in a template kit from an office supply store than wait for a better plan to unfold. I later watched as they completely missed a huge opportunity to go upmarket with the proprietary hardware technology that the product staff developed. They were so obsessed with what was right in front of them that they became embroiled in tactics without strategy, and only the amazing breadth and depth of the market allowed them to continue making a profit without punishing them too severely.

lifeisstillgood• 11 years 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• 11 years 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• 11 years ago

your bad code is somebody else's good code.

crpatino• 11 years 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• 11 years ago

Does anyone recognize which company this study examined?

munificent• 11 years 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• 11 years ago

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

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

Related Stories