Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I close pull requests

jeffgeerling.com

Post reply on HN
Print view View original

181–188 of 188 posts

Re: Why I close pull requests

#181

Post by user5994461 »

fdsfsaa wrote: post #167
beat wrote: post #155

Earlier quoted context omitted.

It depends on the result. If the result is public embarrassment of the company and the loss of millions in market worth? If the result is someone dying?

Do you have any actual evidence that a culture of design documents and signoffs produces code with fewer vulnerabilities?

How to make flawless software that goes into space => A truckload of process and design documents. https://www.fastcompany.com/28121/they-write-right-stuff

Whatever software is made, the [lack of] efforts put in design and reviews will have high impact on quality [or lack thereof].

Re: Why I close pull requests

#182

Post by imagist »

fdsfsaa wrote: post #47
yegle wrote: post #13

At Google, if you want to implement new features (or large refactoring), you'll need to write a design doc. In which, you should answer questions your reviewers might ask (common questions like: why do you want to do this, what are the alternatives, how components interactive with each other before/after your change). This is something like Python's PEP: you need a proposal to convince your reviewer that you have put…

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

> Code is just code. Bad changes can be backed out. It's much better to move fast and iterate quickly than to create an illusion of care and add friction to every aspect of the development process. Up-front design of software just does not work. If it did, waterfall project planning would be successful.

Bad changes can be backed out, but in an infrastructure with any size, this isn't a trivial task. I've worked in a million-line codebase with multiple separate deployments, and in that case, design documents were much cheaper to create and maintain than a rollback or even writing working code and then discarding it. In an infrastructure of Google's age and size, the trade off is even more clearly in favor of up-front design.

You probably think the "move fast and break things" ideology you're espousing is agile, but it's not. It's just another plan, and agile is about responding to change over following a plan. I hope that if you ever work on a project of Google's size that you can adapt.

Re: Why I close pull requests

#183

Post by jimmywanger »

fdsfsaa wrote: post #179
jimmywanger wrote: post #173

Earlier quoted context omitted.

> Microsoft has not collapsed. In fact, it's doing better than ever. If Microsoft of all companies can reform itself, so can Google. I don't know what you think of Google's process. A design doc is needed for any large user facing change or large infrastructure change, and it goes through sections and you skip the ones that are not applicable. For instance, if you're not storing user information, you skip the PII sec…

> Also, the areas in which Microsoft is revitalizing itself are green field projects like the cloud and some other interesting hardware/software integration The example I have in mind is in a big legacy product. I can't get more specific without outing myself, but it's very far from greenfield. > Specialized labor does help. Specialization of labor can also hurt. I've found myself frustrated with security people in t…

> Broad exposure helps too.

It seems as though you haven't really encountered Google process in person, you've just heard stories. Security people do have a day job, they just do security on the side because they've expressed interest/aptitude.

My point remains. I'd rather have a plumber fix my plumbing or check over plumbing designs rather than an enthusiastic amateur.

> Why? There's no rule that says that everyone needs to see the same UI in production.

They don't. Google constantly runs A/B testing. Once you get it to production you've already invested the time in productionizing it.

> It's telling that Google autonomous drivers experts had to leave the company in order to get their work into a real live product.

Or that it's be far more lucrative to be acquired than continue working on Google X. You can't ascribe motives to their actions.

Re: Why I close pull requests

#185

Post by beat »

fdsfsaa wrote: post #168
beat wrote: post #153

Earlier quoted context omitted.

I can tell you've never dealt with one of those trivial backouts on a product that moves a hundred billion dollars a day and is a key component of the entire US economy. Or a product where a bad software deployment can actually kill people. Process is the scar tissue of the enterprise. Those scars are there because the enterprise was wounded. Lots of process, many scars.

I can choose not to work in an environment riddled with "scar tissue". Instead, I can go work at a startup and eat that enterprise's lunch with a tenth of the budget. Unfortunately, thanks to inflexible and sanctimonious attitudes some programmers adopt about what is and is not "responsible" engineering, the only way to change practices is to beat the old practices in the marketplace.

You're welcome to try eating Google's lunch, since their process is your favorite example.

But try tackling banking, or insurance, or transportation logistics, or any other big-boy problems with that attitude. You won't last long.

Re: Why I close pull requests

#186

Post by braveo »

jimmywanger wrote: post #173
fdsfsaa wrote: post #105

Earlier quoted context omitted.

It's funny that you mention Microsoft. A friend (he has ~100 reports, transitively) at Microsoft tells me that at least on his team, the old-fashioned three-specification (design, dev, test) document triplet, each with a multi-page checklist-laden Word template, has been supplanted by a lightweight scheme that boils down to one or two paragraphs. That's real progress. Microsoft even runs successful open source projec…

> Microsoft has not collapsed. In fact, it's doing better than ever. If Microsoft of all companies can reform itself, so can Google. I don't know what you think of Google's process. A design doc is needed for any large user facing change or large infrastructure change, and it goes through sections and you skip the ones that are not applicable. For instance, if you're not storing user information, you skip the PII sec…

> The review committee does this for hours a day, and they see far more cases. That's like saying that it's better for you to assess the condition of the transmission of your car, because you care more and are more invested. I'd rather have the guy who rebuilds transmissions for a living, who has seen dozens of transmissions, and is familiar with common failure modes and pitfalls.

That's a really bad analogy, borderline dishonest.

In this case it's a mechanic taking his vehicle to another mechanic for service, you better believe that first mechanic is both more invested and more familiar with the transmission.

Re: Why I close pull requests

#187

Post by dismantlethesun »

fdsfsaa wrote: post #98
dismantlethesun wrote: post #90

Earlier quoted context omitted.

> You shouldn't hire people who don't give enough of a shit to take the big picture into account. Even if you care, you can't know the entire story. I work for a small company, tiny compared to Google, but often we run into someone proposing a change that backtracks on a strategy decided 2 years ago. Luckily it was encoded in a design document or else, how would anyone new find out about it? New people want to know t…

> backtracks on a strategy decided 2 years ago Why should anyone be bound today by decisions made two years ago? Maybe that strategy no longer makes sense. I've seen it go both ways. On one hand, sometimes a new developer in an old codebase does something "against the grain" of the system due to unfamiliarity or JavaScript-induced brain damage. On the other hand, sometimes circumstances change and even good old desig…

> Why should anyone be bound today by decisions made two years ago? Maybe that strategy no longer makes sense.

Then that'd be a great time to discuss that the strategy should be changed, and move forwards as a team---not a single developer deciding to go against the grain with side effects that may be unknown.

Here's an example:

At my company it's our strategy that all file operations happen atomically and asynchronously. Even if your function was the one to create a temporary file, and you are absolutely sure it's happening locally, deleting it must be an asyc task handled by another worker.

Why? Because historically, small tasks start off as local only operations, but get upgraded to handle remote instances. Remote operations can fail fairly often, and we don't want the entire task chain to die because you couldn't delete a temp file on another server.

Now .... to any single developer writing a small script, this feels inane because forcing it to a asyc op, using our message bus tool chain, etc. will slow down the entire function by an order of magnitude. But it saves on 10x more integration work 6 months from now that they don't anticipate.

Re: Why I close pull requests

#188

Post by stinkytaco »

user5994461 wrote: post #86
stinkytaco wrote: post #50

Earlier quoted context omitted.

I can't comment on Google's culture, but: >Design documents turn every feature into a half-assed, lowest-common-denominator risk-minimized shell of itself. Sounds like a sentence written by someone who is an engineer and not a support staff or a user, i.e the people who have to deal with the fallout of every feature change and every engineering decision. I could just as easily substitute "feature driven design" into…

> Sounds like a sentence written by someone who is an engineer and not a support staff or a user Wow. I feel terribly offended as an engineer. Could we not confuse "engineering" with "pushing random changes at any times that may not even pass the tests by any bro-ninja that just felt like it". The poster has clearly never written or maintained any critical software.

I didn't mean it to offend, just to emphasize that though the poster may feel it affronts his "engineering dignity" (his words) to write design documents, there are others in the chain who have to deal with the fallout from that.
Post reply on HN