261–270 of 319 posts
Earlier quoted context omitted.
That breaks as soon as you have to interrupt working on Nice To Have Feature X to working on Inportant Bugfix/CVE Y.
How often does that happen to an individual developer though? Once a month? In an averagely well run company even that may be towards the higher end. Should your entire development strategy be based on a once a month occurrence?
Closer to once a week for me.
Earlier quoted context omitted.
I think the objections to rewriting code are sometimes justified, rather than just blindly following rules. As you said, refactoring code helps you understand it. This means that you can end up feeling like your code is objectively clearer than before you started, but sometimes it's just an illusion caused by the fact that you just (re)wrote it. If there are other people in the company that already understand that fu…
(Genuine question.) Do you think "small changes" shouldn't be "tacked on in the easiest places"? I'll try to give an example I hope is realistic: One of the heaviest things an application can get is a complete theme system. Suppose you don't have one. It's not a requirement. Adding a theme system when there is none is months of work and might impact basically every line of code that displays anything. So you're not d…
When exactly is the right time can be hard to figure out. Especially because, if enough hacks have accumulated that code really does need a reshuffle, then the job of refactoring is harder, which actually increases the temptation to put it off. But I wouldn't make a big sweeping change just because of one small hack that's a bit ugly.
Earlier quoted context omitted.
I know about this but haven't found an answer to my question. This was in part my motivation to post this question here.
You develop features behind compile or runtime flags and keep it off until it's ready to ship. This is what chromium.org does so that might be a more accessible way to see it in practice.
"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?
Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership": "In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."
I’m not convinced this works so great for Google. Some rewrites are very noticeable as a user, and things in the UI frequently shift around for no discernible reason. Perhaps worse, they seem unable to get below a certain level of bugginess in products like Google Maps and Gmail. Perhaps because a new round of rewrites always introduces new bugs before all of the old ones ever get fixed. Perhaps their metrics tell th…
Perhaps their metrics tell them that all of this is fine, I don’t know. But then, you have to realize Google has so much money they don’t really have to spend it very efficiently.
The user experience ranges between good to mediocre to bad, depending. Google is simply too rich and powerful to care. So long as the goose keeps laying the golden eggs, they can just keep going along and patting themselves on the back.
Earlier quoted context omitted.
Think of a CL like a Pull Request that has (and can only have) a single commit. It's visible in code review UI, has a description, has tests run on it, it can be merged by other people and it can be referenced from anywhere. Eventually it's merged into the head or dropped.
So this is identical to squashing and rebasing your feature branch?
Earlier quoted context omitted.
> definitely never Python which is a maintenance nightmare Did you just say that all startups should never use Python? This is such a ridiculous statement I could hardly imagine where to begin with it.
Yes.
Earlier quoted context omitted.
We do this at a smaller scale (~1500 employees) with success. It enables everyone to work towards a goal and to discuss with their superior any issues that get in the way, as well as every success story along the way. Both are very important parts of the journey.
What goals/steps are there? Is it anything more than something like Goal: get promoted/get higher salary Steps to the goal: did my job well ?
"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?
This is simply part of how they've implemented Jack Welch's Vitality Curve[1]. It's pretty common practice for most large companies, although I understand more and more are starting to move away from this approach. As it turns out, most people don't enjoy playing Game of Thrones with their co-workers every quarter. [1] https://en.wikipedia.org/wiki/Vitality_curve
Earlier quoted context omitted.
I saw this a BT where on system was rewritten in OWS (Oracle Web Services) used 15 Person Years and around a Million Quid - Not the best use of shareholders money. But some one got to tick some boxes on there promotion track
Well, but that money was certainly not needed for someone else if it was so readily available.