The great developers I’ve known would pull back and think about the problem longer, draft up some plans and noodle on it with colleagues and I love that foresight.
The problem with a policy like this is that you’re slowing everything down for the sake of the few that might need it. Your team leads should be able to determine which ones should require the investigation and keep the team moving efficiently.
More importantly, when experienced developers formalize their reasoning for a proposal, less experienced developers can learn from it. That same knowledge becomes archived in a format that is easy to discover and consume in the future.
But, do you believe the statistic that 90% of the cost of software is the maintenance?
If so, then the only way you can be a mythical 10x engineer is if you are willing to do things that really reduce the team costs. Everything else about 10x engineers is just mythology.
I think this is an example / practice of one of those things you can do for your team. Communicating clearly up front, being willing to discuss and alter poor thinking (everyone does it) is what turns individual contributors into powerful team members. If you just start with coding, you are missing all that part of it.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Working software is the primary measure of progress.
- The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
Hmmm. Apart from the very suspicious number (90%) I wonder what exactly it's meant by "maintenance". Because it could be bug fixing, adding or changing features, refactoring, server or db administration, etc. And what period of time is included in the "maintenance" phase: one year, ten, a century?
White-boarding doesn't really address the problem because some of the thorny issues really are substantive scalability or maintainability considerations. I've found it much easier to discuss with mocked code.
There is a time and place for everything. If you a working on a project that takes months it should be planned ahead but if it only takes a few days you might not need. Let us not forget why we got rid of waterfall model.
It's actually doubtful it ever existed: its first formal description, in the 1970s, is used as an example of a model that doesn't work.
Let me formulate the Godwin-Udik's law:
"As an online discussion on development practices grows longer, the probability of a mention of waterfall as a negative example approaches 1"
I have no clue about this, but I suspect that the government, rather than mandating a software development methodology, simply used to agree beforehand on what was to be delivered and expected to have it delivered at the end of the process. It's a constraint on how you sign contracts with external suppliers, not on how you write code- though I understand that the first influences the second.
Frankly I don't know. The Manifesto itself is not very clear about it. I've worked in agile and non-agile companies, but none used a waterfall model. If anything, agile adoption always meant more process (stories, standups, planning, retrospectives, etc.) rather than less. Before or without agile, the structuring of work has been mostly the same, albeit without the formal process defined by this or that agile methodology (to be fair, scrum is the only one I've ever seen).
Let us also not forget about all the time wasted on getting your plan validated. Or how your validated plan is completely screwed only realized after you start implementing it. Pros and cons to each solution.
Stuff in the PRs is developers-only.
Probably most people won't realise, but it was in that kind of situation that "continuous integration servers" came into being. The idea was that after you pushed to trunk, the tests would run (and in those days we slapped your fingers if the test suite ran for more than a minute or two -- for reasons which will become obvious) and you would have a minute or two to fix any gaffs you made merging conflicts, etc. If you wanted to merge your code, you would wait until the CI server gave a green light, so if the tests were slow, it would be a major PITA.
The massive upside of this process was that you always knew what your colleagues were planning to do. You saw all their progress every 20 minutes! You integrated with their changes! If you saw a problem, you yelled over the cubicle wall and said, "Hey that won't work because I'm doing X" -- saving both you and your colleague hours of wasted effort.
TBD in this style is hard, but very rewarding. The main reason I don't practice it these days is because 1) We have continuous deployment and you don't want to deploy unfinished work 2) The teams I work on these days are distributed (and I'm 9 timezone hours away from their day). However, I really miss that immediate feedback and the seemingly effortless way in which everyone on the team is kept completely in sync. I've never found anything that even comes close (and I've done the "preliminary PR" thing many times).
That sort of XP style development also tends to come hand-in-hand with near-constant pair programming. So even if the conceptual limit is "5 sets of committers", that's still double the actual team size. And in practice, the cross-pollination that comes with swapping pairs every day or every few days means there's less of a cognitive load to needing to be aware of what's going on, since chances are either you or your pair already has context.
git commit --allow-empty -m 'Empty commit so I can open a PR'
I find that nobody looks at them, though. :-)
Sometimes I ask people to look at the code in progress when I want opinions on architecture or just overall code quality.
When I think the feature is ready for merging, I'll create a pull request.
How does a draft PR help me? What do I get with a draft PR that I don't already have?
I assume it's a good idea, and everyone here seems to think so too, so I think I'm missing something obvious.
Edit: Lots of great points below, mostly pointing out features that I don't really use a lot, which is why I didn't see the improvement. Thanks everyone!
* Signifies that the work is being done, preventing duplicate efforts.
* Shows people all the work being done in a single location, rather than having to hunt down forks and branches.
* Gives a nice UI showing the exact changes, without having to compare to specific commits.
* Gives a review interface, where people can comment on the code itself or even on specific lines.
All your other points still stand- you still create one branch per feature, check in frequently and push up work. If you explicitly want a review you can ask people for it (as you already do), but now they have a nice place to do it.
Or maybe I'm confused by your answer, are people commonly reviewing PR's without being asked?
This basically is a better WIP system than before because it can prevent accidental reviews and wasting time of re-reviewing when it actually is ready.
#1. PR triggered checks will fire
#2. You use the same tools for reviewing and can leave better comments
#3. I like PR comments to be detailed and explain the changes well for non-team members. Composing the draft message can help reveal items I need to make clearer or need to still do.
#4. It's clearer which branches/tasks are still being worked on, and how the work is progressing.
Ah, didn't even think of this one. Thanks!
Remember than anything GH does “can be done by email”, to cite some early commentary. But collectively, the ease of use, and defaulting to best practice, that GH introduced have vastly improved and enlarged the open source community.
I know I never submitted patches in the 10+ years in the industry pre-Github. Now, barely a week goes by without at least one PR.
Clearly not, otherwise I wouldn't have asked. :)
> It essentially formalizes a workflow like the one you describe.
How though? What do I gain by doing it this way that I can't already get? What's easier now? That's the part I'm not seeing.
That said, having worked with git internals and models of repo access I'm pretty sure GH introduced forks to work-around the issues with repository control. Conceptually there is no need for forks, one could push to private branches of the target repo directly. Unfortunately git doesn't have tools for per-branch level controls directly. More details in https://github.com/rescrv/gitswitch
I assume you meant commenting? It took me a minute.
The heart of this being this point: sometimes the workflow of the team demands different ways of thinking about it, and its nice to have that flexibility.
Edit: worth noting also, this does something for those of us using this methodology (I am a big promoter of trunk based development with ruthless purging of short lived feature branches)
Opening WIP PR allows everyone to see several things:
1. what issue is being worked on
2. that it is claimed by someone
3. When that issue was started to being worked on
4. The intentions in solving the issue (if done right)
Those are real wins.
I wonder if the hub client will get a open draft PR option soon.
If so, this can't be done within git, since the overall container is a single repo. There is no atomicity or even coordination between repos. You can get loose coordination though via integration with an issue tracker like jira. The tracker links multiple PRs across multiple repos into a single meta-merge. But you aren't going to get "simultaneous merge" in the sense of a single atomic cross-PR and cross-repo commit.
 One of the things that is awful with github [not git itself], is that all your controls such as commit rules, privileges, visibility, have the granularity of the entire repo. Even though awful, this is the right approach considering that many git restrictions are per-repo, eg branches. vs perforce, eg
This is one of the reasons cited for monorepos, you can make a single atomic commit/PR that changes some API, and the consumers of that API.
As it is now, you end up writing a warning comment to merge some other PR at the same time and hoping your reviewers read it.
Disclosure: worked at Google, have used both systems a lot.
What other 'hacky ways' you mean? 'Magic' refs/for/* branches can be a bit weird at beginning. On the other hand introducing Gerrit 7-8 years ago to my back-then employer made me understand the Git model much better. Anyway, e.g. IntelliJ IDEA plugin for Gerrit should alleviate almost all pain points (if someone stick to JetBrains products).
Were you working on Android/AOSP? I always assumed that this is the primary project where Googlers have a chance to work with Gerrit. I thought that Google uses some in-house CR system, as mentioned by https://www.gerritcodereview.com/about.html.
1. Start a branch with a first commit
2. Open a PR and write details / background
3. Mark WIP
4. Eventually remove WIP and add someone as reviewer.
Glad to see this is available now.
Having something like this that allows a little closer relationship between the plan and the code created for the plan is nice.
* Notifying the maintainers might be useful in some cases. Often, I will file a WIP pull request to get preliminary review by a maintainer so that I know I’m going in the right direction.
* Being able to convert a draft pull request into a full one: Useful if the original author has stopped responding and you’d like to merge in their changes (after tweaking them, etc.)
I'm not sure. When I send a PR marked with PR I usually want to know the opinion of the maintainer/owner to know if it is going in the right direction and if it worth finishing.
This seems like the kind of feature that probably takes longer than a week to build and test, so I'm guessing it was already in the works.
I've done this many times myself, and I hope nobody was counting those as a feature request.
This feature signals "yeah it's OK to take your time and not merge stuff incrementally - here's a feature just for that since it's such an important part of your workflow".
Yes, people have been doing it anyway but at least it felt a bit like a hack, like it's not supposed to work that way.
Am I crazy, or is this pushing back progress made in CI coding practices?
For some projects maybe.
Other projects want changes to be very carefully presented, considered and reviewed.
> it's not supposed to work that way
According to who? Is this how you do things at work? Ok, but other people work differently. There’s not authority in programming to set what we’re ‘supposed’ to do.
> is this pushing back progress made in CI coding practices?
Seems orthogonal to me. You can run CI on a branch.
But overall, no not everyone’s development is a mad dash to get everything merged instantly and some want carefully created PRs.
Funny how some terms can be diffused enough over time to come to mean almost the opposite of what they originally meant. Continuous Integration is about integrating continuously. "the practice of merging all developer working copies to a shared mainline several times a day." i.e. everyone commits to master multiple times a day.
Then tooling gets built to facilitate this way of working. People start confusing build tooling with CI the practice. Eventually that tooling gets used to support people working in continual isolation on feature branches. People start calling this practice CI even though there's no integration in sight.
Of course true CI isn't applicable for all contexts. Draft pull requests look like a great tool for where CI is impractical.
The CI system then does the work for you to test that on top of master. You’re talking about developers doing things that the CI system is there to do.
Otherwise, you still might test indvidual feature branches on top of master, but that wouldn't prevent any conflicts between several of the pending branches. One could think of a system that continuously tests all possible combinations of all pending feature branches to spot any conflicts before actually integrating them. Not sure whether such thing exists, though, or whether it'd be very practical.
I'll sometimes open a PR for this with "WIP" in the title, "DO NOT MERGE" in the body, or without the "For review" label that we use.
These PRs serve to facilitate discussion, start knowledge sharing, and update other developers on my progress more clearly than a branch they might have to check more carefully. However I would definitely not want to merge one.
I love CI/CD, we do a lot of it and try to have small changes and feature flagging as much as possible, but this feels pretty useful in general for us. Yes it could be mis-used, but I don't think that's a reason not to have the feature.
It's a choice.
All that said I think this feature in github is minor enough that it'll make what people were doing already more convenient (UX win) but won't substantially change how people work. It's just not dramatic enough.