16 ms·

Chrome was delivered without any sprints at all (2021)

355 points by luu 4y ago

smrtinsert 4y ago
But what about the ceremonies?!?!
- sktrdie 4y ago
  He said there were no divorces! /s
- jimjimjim 4y ago
  everybody solemnly chants the holy words "you're on mute"
koala_man 4y ago
Sprint here refers to crunch time, and not agile development.
- mattnewton 4y ago
  Probably also was done without agile, I didn’t really see anyone doing “agile” in my time at google.
  - cmrdporcupine 4y ago
    I did. Or rather, I saw teams that thought they were dong it, because they used pivotal-type tracking tools and stories. But it always degraded into broken-down-waterfall.
    - cornel_io 4y ago
      [flagged]
  - koala_man 4y ago
    "Agile" means different things to different people. I would argue it's agile if you release early&often to continuously incorporate feedback, even if you don't play Planning Poker in Scrum Sprint Planning every two weeks.
    - ch4s3 4y ago
      > Planning Poker in Scrum Sprint Planning every two weeks I would argue that isn't agile at all.
nine_zeros 4y ago
But but, how else would I introduce more bureaucracy for engineers?
surfpel 4y ago
I'm not familiar with the twitter UI, does this put things in the correct order? https://threadreaderapp.com/thread/1427137725119959046.html https://threadreaderapp.com/thread/1427137725119959046.html In response to this thread: https://threadreaderapp.com/thread/1426587396343099397.html https://threadreaderapp.com/thread/1426587396343099397.html
- bobobob420 4y ago
  Never trust anyone who uses a series of tweets to say a paragraph.
pessimizer 4y ago
It was a product that no one had asked for and no one was waiting for, and wasn't intended to make a dime.
- jahnu 4y ago
  And yet this succeeds very rarely
  - blondin 4y ago
    funny you say that, since we are talking about Google here, because Gmail has a similar story.
  - pessimizer 4y ago
    People are actually very good at producing products that make no money that no one is asking for.
- 3a2d29 4y ago
  This is an underrated point
- senttoschool 4y ago
  And the company's fortunes did not rest on the product being successful.
  - pessimizer 4y ago
    Seeing as it's money-losing (like virtually all of non-ad google), it wouldn't have helped anyway. The only value to Chrome for Google is the monopolistic market-distortion through vertical integration.
    - alisonkisk 4y ago
    - satyrnein 4y ago
nsgi 4y ago
Obviously very good that Chrome was delivered without people doing lots of overtime. However, a lot of his argument seems to be about the age of the management, and surely ageism is illegal and it should be about the person's skills rather than being old enough to have school-aged kids or even how many decades of experience they have Edit: Okay, I guess the kind of ageism he is suggesting isn't illegal in the US, but it is in the UK and is still generally considered unethical
- eterevsky 4y ago
  What he writes about is seniority, not ageism. It's about whether to incentivize career paths in which senior engineers keep doing technical work.
- jsty 4y ago
  I won't try and read into whether or not there's ageism anywhere in the tweet stream, but certainly when talking about hiring the magic words are "find experienced engineers to run it". This is very much legal and ethical in the UK - we're not precluded from setting an experience-based hiring bar. I'm sure if a 25 year old had come along with two browsers under their belt they'd gladly have been hired into a leadership role too.
- rvnx 4y ago
  Maybe the secret is not really about the age or management skills, but rather that Chrome is an insanely profitable product (+ in a monopoly) so the pressure is rather low compared to a startup. Additionally whether a specific feature is ready or not for a specific cycle is not that important considering that there are releases every 6 weeks and even before for metrics gathering activities.
  - Cederfjard 4y ago
    The author of the tweets is talking about when Chrome was first delivered, no? It wasn’t profitable, nor a monopoly, before it had come out.
- gridspy 4y ago
majormajor 4y ago
This thread really seems to be burying the lede which isn't just "we didn't have crunch" but the more specific claim that it was engineers with at least a decade of experience having deep technical involvement that made the difference.
wolfgang42 4y ago
Worth noting, from the linked thread: > In light of all the responses, I really regret posting this tweet that mischaracterized reality: > In fact: The IE3 team did not have an unusual rate of divorce.I know of no broken families and only one divorce during the IE3 project. > Here’s my statement reflecting on this in greater depth: https://www.linkedin.com/pulse/my-recent-twitter-blow-up-hadi-partovi/ https://www.linkedin.com/pulse/my-recent-twitter-blow-up-had...
- deleted 4y ago
  [deleted]
United857 4y ago
Unlike IE, Chrome initially built off WebKit, so a lot of the work in writing a renderer was already done. Obviously a lot of work with V8, multiprocess IPC, etc. still went into the effort but still easier than starting from scratch like what IE did.
- ubercore 4y ago
  IE started with Mosaic, no?
  - jerrygoyal 4y ago
    a lot of work with great UX as well
  - kryptiskt 4y ago
    It started with Spyglass, who were Mosaic licensees, but apparently wrote their own code. The story of Spyglass is told here https://ericsink.com/Browser_Wars.html https://ericsink.com/Browser_Wars.html "Management made the decision to transition our business completely and pursue the market for web browsers. Tim Krauskopf, the founder and head of development, asked me to write a web browser. I started work on Spyglass Mosaic on April 5th, 1994. The demo for our first prospective customer was already on the calendar in May. I ended up as the Project Lead for the browser team. Yes, we licensed the technology and trademarks from NCSA (at the University of Illinois), but we never used any of the code. We wrote our browser implementations completely from scratch, on Windows, MacOS, and Unix. We were not the first Mosaic licensee, but we were the last. Prior to us, a company called Spry took the Mosaic code and tried to sell "Internet in a Box". People still seem to get Spry and Spyglass confused because of the similar names." "Internet Explorer 2.0 was basically Spyglass Mosaic with not too many changes. IE 3.0 was a major upgrade, but still largely based on our code. IE 4.0 was closer to a rewrite, but our code was still lingering around -- we could tell by the presence of certain esoteric bugs that were specific to our layout engine. Licensing our browser was a huge win for Spyglass. And it was a huge loss. We got a loud wake-up call when we tried to schedule our second conference for our OEM browser customers. Our customers told us they weren't coming because Microsoft was beating them up. The message became clear: We sold our browser technology to 120 companies, but one of them slaughtered the other 119."
zerr 4y ago
Off-topic: does 9-to-5 mean that 1-hour lunch break is considered as working time? How common is that?
- khazhoux 4y ago
  9-to-5 here is figurative. No one is tracking hours for software engineers at most companies. It just means: you start working in the morning, and you stop working in the evening. As opposed to working until late at night and/or weekends.
  - zerr 4y ago
    I understand that. 9-to-5 is a common term, but I wonder why - many mention clocking out at 5, does that mean they arrive at 8 in the morning? Or maybe some have lunch on the keyboard while continue working.
    - khazhoux 4y ago
      The most common (by far) schedule I've seen across every software company is: arrive at 9, ~45-minutes lunch, leave at 6. Lots of people arrive before 8 but it's not the norm. 8am meetings --before COVID-- were always generally frowned upon.
    - ipaddr 4y ago
      Many places give you that hour. 35 hours weekly.
    - nicoburns 4y ago
      In Europe a 7.5hr day is standard, so 9-to-5 can be literally 9am until 5pm, with a 30 minute lunch break.
      - pmontra 4y ago
        I live in a Southern European country where the standard for office work is 9-18 with a one hour break starting between 12:30 and 13:30. On my last job as employee we were more flexible. I was starting at 10 maybe with even a 90 minutes break but I was usually in office until 19 or 20, which was OK because traffic was insane before then.
Barrin92 4y ago
>"I mean even at Google (on a different team) I was a "technical lead" in my 20s, and let me tell you, I had noooo business leading anything technical of any importance. But this is very common! We would never accept this in other fields. Would you live in a house built entirely by junior carpenters in their late 20s who built one or two houses that barely stood up? Would you drive cars designed and built by junior engineers?" one of the strangest and most baffling things about the entire industry tbh. Like, would you ever expect a 25 year old guy to command a spaceship? Yet in software you have these weekly "I'm 40, is my life over" posts. In most disciplines people correctly acknowledge that there's a sweet spot of skill and experience that overlaps somewhere in your late 30s, 40s or even 50s, yet in software very often we recreate Lord of the Flies, leading to chaotic project management.
- andreilys 4y ago
  The constitution was signed by 20-somethings e.g. James Monroe (18), John Marshall (20), Aaron Burr (20), Alexander Hamilton (21), and James Madison (25)
  - kthejoker2 4y ago
    First, those are the ages of those men at the signing of the Declaration of Independence. The Constitution was not ratified until nearly 15 years later. Second, none of the people you listed signed the Declaration. The average age of the Declaration signers was 41; only 3 were younger than 30.
  - butlerm 4y ago
    I am afraid you have an unreliable source. The Constitution was ratified by the states, not signed by delegates. At the time of ratification, the average age of the delegates was 42. James Madison, for example, was born in 1751 and was 36 years of age in 1787. Alexander Hamilton was born four years later and was 31 in 1787. There were only four delegates in their twenties.
- vlovich123 4y ago
  There are 20 year olds who demonstrate fine leadership skills and maturity. There are plenty of 40 year olds who do not. Find the best people you can regardless of age. Also, often times the only way to get that experience in the first place is to be put into the positions of leadership to develop your skills.
ryandrake 4y ago
If there's one much-believed software industry trope I wish would die, it's this idea that building great software requires constant heroics, crazy hours, mandatory crunch time, living at the office, and sacrificing your personal life and loved ones. That's how undisciplined and/or disorganized clowns do it, not professional software teams. When someone says, "Wow, we worked nights and weekends, guzzled Mountain Dew, pulled 48 hour coding shifts, drained our mental health, and half of us got divorced, but the result was this kickass video game!!" it's not admirable--it's sad. That's just not how it's supposed to be done, people! EDIT: This seemingly well-received comment seems to have ended up perma-locked to the bottom of the page. -weird!-
- shadowgovt 4y ago
  If anything, that kind of behavior should give the outside world pause and raise questions about the sustainability of any product output. That mattered less in the days of one artifact software development (and still matters less in areas like video games where that is the case), but software development these days is a process and many projects are far more marathon than sprint.
  - ryandrake 4y ago
    > If anything, that kind of behavior should give the outside world pause and raise questions about the sustainability of any product output. It should give everybody pause, including software practitioners. A separate, but related pet-peeve is how these unsustainable heroics are often rewarded at work!! Boss: "Look at Chris over there--he stayed up until 4:30AM and fixed that ship-blocking bug. What a champ!" Chris gets a $1,000 spot bonus and now the rest of the team looks up to him as an example of good software development. Incredible but it happens almost everywhere!
- khazhoux 4y ago
  > it's not admirable--it's sad It's not just sad. It's often bullshit. I don't believe for one second when people say "I worked 120-hour weeks for 6 months!" Simple math tells you this is a farce. Even 100-hour weeks is not sustainable, unless people want to claim they literally did nothing but wake-commute-work-lunch-work-commute-dinner-sleep for weeks on end. Not buying it.
twsted 4y ago
Understand all and Aaron, at the question: "You guys forked webkit which forked khtml, so you all had a nice leg up no?" says: "Yes. Just like IE started from Mosaic Spyglass. But a rendering engine (like WebKit/Spyglass) is not a browser. Certainly not a multi process, sandboxed browser. Chrome v1 was a 200 person year effort." but, come on, much work was already done and they seem not to remember this.
- doctor_eval 4y ago
  Also, Chrome was using WebKit long before they forked it. IIRC, for several years they used the exact same engine used by Safari, and both Apple and Google were contributing to it.
- zaphar 4y ago
  No where in that thread is he suggesting they weren't standing on the shoulders of those who came before, but he's also right a rendering engine is not a browser and at the time Chrome was revolutionary in a number of ways. It was crazy fast. Even compared to other khtml browsers. It's multi-process architecture meant that for the first time a single page or tab couldn't take down your whole browser. And yes that was something I experienced frequently at the time. 200 person years to deliver a full browser that was an leap forward compared to the rest of the browsers is seriously impressive. His point stands they did it without a death march.
shadowgovt 4y ago
Sprints are only really necessary when there's a deadline to hit. For the longest time, one of the advantages Google has had as a software house is that when you're an industry leader, deadlines are soft because all you're worried about is somebody playing catch up, not your need to catch up to somebody else. As the company has grown in size and scale, calcified a bit, and branched out into spaces where they aren't the leader, the culture around this sort of thing has changed. They are not, for example, the leader in Cloud, and the life of a Cloud SWE is markedly different than the life of an ads or artificial intelligence research SWE.
- vlovich123 4y ago
  Sprints are just a formal way for management to check in that the team isn’t down a weird rabbit hole / getting them to do regular check ins with the team for visibility. It’s independent of deadlines.
- seadan83 4y ago
  If you replan at each sprint iteration, how does that help ensure a multi-sprint deadline is going to be achieved? My impression was the sprint is the deadline, so it emphasizes to not have deadlines in favor of small incrementalism. Hence, if there is an actual deadline, sprints I think are exactly the wrong tool to help
  - pas 4y ago
    sprints deadlines are like milestones. the mantra of strive to deliver something in each sprint helps to prevent the failure mode when a year goes by and everything is in 85% readiness, but the last 15% will need another year (or more!)
    - seadan83 4y ago
      Sure, but if you plan out 10 milestones two weeks apart, is that not just "waterfall" at that point? To be sure, my main point is to disagree that sprints help hit deadlines. They might even hurt. For example. I'm not sure if that failure mode is really changed via sprints. if you get 10 months in, and 15% left, nothing changes that it could still take a year. Further, the sprints discourage lifting your head up to unblock, design and plan that 15% before you actually start on it. So seems a bit waterfall like to feel incremental stuff was getting done, but you still underscored that last 15%, and sprints encourage you to realize that very late in the game. I think a big flaw in scrum is error analysis of expected completion dates. Instead of compounding uncertainty across sprints, often that velocity is given no error bars and is linearly extrapolated months into the future (and in a perverse way increases estimate precision erroneously).
khazhoux 4y ago
Even since "Agile" starting taking off ~2010, it has made be very sad that many junior engineers today genuinely believe that somehow no software was ever written correctly without it. They were taught in school that there exists this bogeyman software development methodology called "WATERFALL" where pencil-pushers in a windowless office write requirements which they hand off in a printed binder to the team of engineers in the basement, who is not allowed to ever talk to the user. The Agile consultants somehow convinced a large segment of the industry that they discovered and/or invented the notion of working with users, of gathering feedback from them, of checking in with your teammates, etc. And they completely disregard the possibility that maybe --just maybe-- there are some developers who can get a metric shit-ton of work done without someone poking them repeatedly for status. And they popularized the term "Cowboy Coder" as a reckless developer who does whatever the hell he wants and dares you to mess with him. When in fact, their so-called "cowboys" are simply the best developers in the team, who write great code and don't need a scrum-master to help them plan it. But the Agile methodology resists the notion of some developers simply being awesome at their job -- in Agile, you are good at your job by meeting your "points" for every sprint.
- mschuster91 4y ago
  > They were taught in school that there exists this bogeyman software development methodology called "WATERFALL" where pencil-pushers in a windowless office write requirements which they hand off in a printed binder to the team of engineers in the basement, who is not allowed to ever talk to the user. Having worked in government and big-co companies before: sadly, this is not a bogeyman trope, but reality. Including the printed binder, although it's called "spec sheet" or "tender document" (or whatever the correct english words for "Ausschreibungsunterlagen" and "Lastenheft" are). The amount of "silos" and "leadership" involving themselves in petty fiefdom fights is astonishing - that is partially a reason why small startups are so much more efficient, they haven't had the time to develop layers and layers of middle management wanting to justify their existence, protecting budgets or establishing their authority. Government projects tend to be the worst target for such micromanager wannabe-king types, given that they can rarely be fired from their jobs for incompetence.
- doctor_eval 4y ago
rr808 4y ago
Before Scrum we had 3x 1-hour team meetings a week to talk about what we're on and what we might need help with. After we went "agile" we moved to having 3x 1-hour team meetings a week with the same. Power to the developers. :)
- khazhoux 4y ago
  Ha, I remember the first project I encountered that "went Agile." The weekly team meeting (which everyone complained about) was replace with daily standups (30 minutes), a two-hour retrospective (useless) every 2 weeks, and a 2-hour sprint planning every 2 weeks. Power to the developers indeed.
  - IMTDb 4y ago
    So basically, you are able to find the time to criticise your team process in a completely unrelated HN post. But when there is dedicated time for that - in the process itself - you call it "useless" ? ;-)
    - khazhoux 4y ago
      Not unrelated: the entire comment thread is about developer process. And retrospectives were useless in the most literal way. The time spent every week going over "What worked well? What could have gone better?" did not materially improve the team's effectiveness.
      - IMTDb 4y ago
        The next retro is the place to discuss why these retro do not yield to any measurable improvement, and agree on a better process/schedule that works for your team. If your point is that your team processes are sooo perfect and sooo amazing that there is nothing to criticise, review or change, I'll have a hard time believing that. If your point is that no matter how much time you spend on these meetings, nothing changes, I'd argue that you need to spend even more time and energy on them on them as you clearly haven't figured out how to efficiently gather, analyse and act on self-reflection of you team processes. The retro itself might be the starting point of your thought process since it seems so "useless" and yet is absolutely essential if you don't want an external "manager" to do that job for you.
dijonman2 4y ago
Sprints are to knock down the high achievers and provide an opportunity for substandard developers to all appear as if there is progress. A place to hide, if you will. All of the high functioning teams I’ve worked on didn’t have any kind of agile structure. Agile can be done well, but more often than not it isn’t.
- i_love_cookies 4y ago
  I mean, that's true to an extent but there's large volumes of software that has no use for high achievers and is better off with process consistency and predictability the development of something like Chrome isn't one of those project but say a banking website or a inventory management system could be
oars 4y ago
I wonder how UNIX would look if it had been delivered with Agile.
- pas 4y ago
  wasn't it delivered with the principles? individuals before process? guys talking to each other informally and adding features they found useful (feedback from users, delivering value quickly)
thrwy_918 4y ago
The author is using the word a bit differently, but the fact that "sprint" has been normalized as a unit of work for software development, and developers are expected to be in a "sprint" more or less at all times, has always been a source of the deepest absurdity to me. A "sprint" is, almost by definition, a pace that's sustainable only for short periods. The fact that developers are expected to perform sprint after sprint endlessly, to view "sprint" as the default baseline pace, seems a ludicrous abuse of language.
- butlerm 4y ago
  It certainly implies developers recovering for several days between sprints.
- throwaway821909 4y ago
  I think the language is accurate and that's the problem (or not depending on your perspective) - sprints are all or nothing, and a way to create an artificial sense of urgency. "It's the last day of the sprint, better work late/cut corners because 99% done is failure". And then if you do your reward is one more work item next sprint, to ensure everyone is working as hard as possible all the time.
- slim 4y ago
  if memory does not fail me, original sprint was 3 weeks long followed by "spare" time till the end of the month (mostly meetings, planning, review, etc..)
- paulryanrogers 4y ago
  Was the word 'sprint' chosen to describe a never ending crunch? Or just to roughly imply quick forward motion. Unlike waterfall that often slows for large portions of time until the next sudden and irreversible release? Perhaps it would've been more accurate to use something like 'unit' in education. Which is just a subdivision of time and effort roughly equal to a week or two.
- crazygringo 4y ago
  I think you're being overly literal with "sprint". And no, developers are not expected to be "in a sprint more or less at all times". To the contrary -- in between each sprint, there's a review, a retrospective, often a weekend, then regrouping and feature analysis, planning poker, decision on which features to impement, and getting it up on the board. That's the whole point. Instead of a long marathon without revision/reassessment/regrouping, it's a series of short sprints interspersed with revision/reassessment/regrouping. The metaphor here is the distance traveled, not the speed. Sprints are shorter distances, that's all. Nobody has ever intended "sprint" to mean that engineers are going faster than in a marathon, anymore than "waterfall" means engineers are all tumbling down white water to their deaths at the bottom. :)
babyshake 4y ago
A sprint means to go as fast as you possibly can, and is associated with exertion to the point of exhaustion. There's a reason managers love the word sprint.
jmyeet 4y ago
> I mean even at Google (on a different team) I was a "technical lead" in my 20s, and let me tell you, I had noooo business leading anything technical of any importance. But this is very common! So these big tech companies have a caste system. And no I don't mean the Indian caste system, which obviously has its own controversies. The caste system is really a form of social proof. Did you go to MIT, Stanford, UW, Waterloo or CMU? Ok, you're in the club. You can join TI (Technical Infrastructure). Out of college you'll be L5 in 2-3 years (the same level an external hire with 10 years of experience will have). You will find yourself on the better projects with more promotion prospects. This kind of premature promotion is to find the 1 in 20 of these people who are truly talented enough to continue getting promoted to L6-8+.
- google234123 4y ago
  Is TI really regarded better than search? Do they typically promote faster?
- evmar 4y ago
  This comment is pretty ironic given that Aaron (the person you’re quoting) didn’t go to college at all. Source: https://blog.thirdyearmba.com/not-everyone-should-attend-college-but-lets-n https://blog.thirdyearmba.com/not-everyone-should-attend-col...
  - zaphar 4y ago
    I worked at Google for 7 years and never went to college either. I was never hampered by that in my career. If anything people were more impressed that I was doing this without the degree than if I had actually had a degree to point at.
olliej 4y ago
I really don't understand the "sprints" approach to development - I've never worked on any project where it makes sense, either the things I've been working on take less time than a "sprint" or they take longer, and that's for any sprint length you can produce. Real software requires some degree of planning, and sprints seem to be more an attempt to avoid that planning. I don't mean to the level of gantt chart hell (I've experienced that as well). Sprints, at least as they actually occur in the real world, seem to actively harm any large scale projects, and increase the overhead for long term projects if you can get them to fit.
- pas 4y ago
  there are different thoughs on this, but .. the team should not pick a task until it's clear what to do and until it's broken down into something that they think/agree can be delivered in one iteration. this is usually called refinement. (as the raw user requirements are transformed into a concrete design and then tasks) http://tryqa.com/wp-content/uploads/2014/12/scrum-methodology.gif http://tryqa.com/wp-content/uploads/2014/12/scrum-methodolog... if something is so unclear that the design/planning itself requires prototyping something, then that can be added as a task for the sprint. then when it's done, on the next refinement the team is in a better position to find a good design.
_gabe_ 4y ago
> I mean even at Google (on a different team) I was a "technical lead" in my 20s, and let me tell you, I had noooo business leading anything technical of any importance. But this is very common! We would never accept this in other fields. Would you live in a house built entirely by junior carpenters in their late 20s who built one or two houses that barely stood up? Would you drive cars designed and built by junior engineers? I find this kind of funny, because this is what happens right? I was under the assumption that architects typically design the building plans and do all the engineering, and a construction crew (which can consist of people mainly in their 20s) will build those plans under the supervision of the lead engineers/architects. So, in the same way that many senior software engineers don't write much code, don't architects/civil engineers typically refrain from using power tools to build the actual building? If this is the case, then software engineering is very akin to other engineering disciplines in this regard. I feel like the author of this tweet is conflating craftsmen with senior leads. A craftsmen is somebody I would expect to have been working with the medium for 10+ years, and continues honing their craft throughout the years. Whereas engineers and architects are typically more concerned with the abstract ideas and overall outcome. An engineer/architect can be a craftsman, but I don't believe they need to be synonymous.
- nso95 4y ago
  Well an early career civil engineer isn't building the actual structures either
- aboodman 4y ago
  Not at all. Every construction project has a site lead, usually in their 30s or 40s who has decades of experience.
- suzzer99 4y ago
  A software architect who doesn't code anymore is worse than useless in all of my experience. They're flimflam salespeople who build PowerPoints full of buzzwords that aren't even necessary, and then delegate everything to developers who actually code to try to build their Frankenstein contraptions. "But we have to have websockets, it's in the presentation!"
throwfh80h82 4y ago
I'm not advocating for death marches, but a small project being built in a company that has a money machine printing billions of dollars a quarter isn't reflective of most environments.
- nojvek 4y ago
  Microsoft had a machine printing billions of dollars but their environment was quite different. I was in IE team on dev tools. We shipped every 6 months, while chrome shipped every month. In the last 2 months of 6 months release, we had feature code freeze. Even small bug fixes weren’t allowed. First month was planning. Our dev pace was slower than Chrome. Chrome shipped a lot more in 6 months than IE did. Chrome had an insane testing suite that tested pixel perfect rendering and Perf benchmarks. Doing this on every pull request is just amazing. IE had some work to do. I was surprised to learn that the E2E test results were hosted on some engineer’s dev machine in his office. We used to run tests on our machine before committing to source depot. IE CI/CD had a lot to desire. My takeaway from IE vs Chrome was that Chrome had good leadership, they highly invested in all kinds of tooking to encode their security, UX, performance bars. IE leadership was sometimes far away from the user experience. They didn’t care about the little big things.
  - mike_hearn 4y ago
    Yeah but many of those things are a direct consequence of budgets. If you are willing to throw 100 incredibly well paid engineers at nothing but testing infrastructure then you can get that sort of result but it's implausible to expect a normal company to invest the same amount. Even today Microsoft couldn't match Google's investment in Chrome and simply gave up. It's worth observing here that Chrome was not just unusual in having access to a huge budget and highly experienced senior engineers, but also in the fact that it was the passion project of Larry Page. The Chrome team could take their time, because Page simply wanted to do a browser and always had, end of story. I worked at Google at the time and I recall vividly that Page/Brin never emailed the entire company in the way most CEOs do. They appeared at TGIFs but emailing the whole firm at once? They just didn't do it. With one exception (that I can recall at least): the day Chrome launched. Not only did Page email the whole firm but he sent a short, informal and clearly ecstatic note proclaiming that Chrome was "spectacular". Schmidt opposed the idea the entire time, so Page and Brin just hired a bunch of browser engineers behind his back and funded what was basically a black project. Schmidt later stated he was basically forced to change his mind "because it was so good". In reality he was forced to because he'd been there before and it would have been self destructive to try to cancel an already running project the company founders were so in love with. Remember, at the time Chrome launched it: 1. Only ran on Windows. 2. Couldn't print, amongst many other missing features. 3. Had no extensions and wouldn't for quite some time. 4. Had numerous page compatibility problems with many major websites that simply didn't work at all, due to its KHTML heritage, UA sniffing etc. 5. Had a pitch so complicated and developer centric you needed an entire comic book with the developers in it to try and explain why anyone should care. Not surprisingly given the above, it had a brief usage spike as people tried it out and its usage then collapsed to nearly nothing, taking (iirc) years to rebuild to its initial launch spike level despite being heavily pushed via the google.com homepage. Also, Chrome was entering a market with largely stagnant competitors, unlike the IE3 team, who were (or believed they were) fighting a successful, energized, passionate company that posed an existential threat to Microsoft's business. The IE team faced time pressure. When Chrome appeared there was Safari, which didn't care about the Windows market and was there mostly as a feature tick box for Apple's operating systems. The IE team was still disbanded at that point. Firefox was an inspiration but basically funded by Google anyway, and was struggling with tech debt. I'd say Chrome 1.0 was competently executed but in any kind of normal company, with normal goals (like usage or profit), in which the project wasn't the passion project of an invulnerable CEO, they would absolutely have had to crunch like crazy and would then have certainly been cancelled or gone bankrupt despite that, due to the near total focus on engineering over all else. It worked, in the end. I'm writing this from Chrome after all because Safari is inexplicably buggy even though I'm using a Mac, and with time they did get to add plenty of compelling features. Also being able to outspend their competitors meant taking control of HTML5 and putting other companies in a position where all their budget is taken by trying to keep up with whatever random features they threw into the spec. But anyway, the reason the Chrome team could live normal 9-5 lives is nothing to do with senior engineering leadership. To claim otherwise seems kinda unfair on everyone building new products who does not have a time/money budget set by a near-obsessed CEO who also happens to control the google.com homepage. A good example of a team it'd be unfair to was the Android team, who also had very experienced senior engineers with OS dev experience, but whose position was far more similar to that of the IE3 team. Android's creation was typified by enormously punishing hours and huge amounts of crunch.
deleted 4y ago
[deleted]
aantix 4y ago
If unfinished stories just roll over in to the next sprint, is there any point to the sprint?
- antonvs 4y ago
  One point is to identify what work the team is supposed to be focused on, and help avoid arbitrary distractions.
- pas 4y ago
  estimation. you can look back over the previous sprints and see how much on average has been done in one. then you do reference class estimation of the incoming tasks. (story points are used for this.)
mbrodersen 4y ago
I have delivered successful software for 30+ years without sprints or any other ceremonies. I simply keep a prioritised “to do” list and only work on what is the #1 priority. I do it when managing development teams and when working as part of a team. It’s simple. It works. And when asked to change priorities, it is clear from the priority list what the consequences will be. And usually people will change their minds when they can easily see the consequences. It also means that you never need to say no. You simply add the new task to the priority list and negotiate whether it moves up/down relative to other tasks.
- pas 4y ago
  when asked do you give estimates? how many people can ask you to move something up/down? is your list public to others? does it happen that the #1 thing is blocked by some dependency? (do you simply move to #2?) how do you manage a team? (do they work on your list or they have theirs?)
  - mbrodersen 4y ago
    Yes I give estimates when asked. I use the priority list to negotiate the number of deliverables agreed to. The list makes it easy for biz people to balance time vs. deliverables. Yes if #1 is blocked then I work on #2 until #1 is unblocked. And if #2 is blocked then I work on #3 etc. I use a single prioritised list to manage teams. The list is public to the team and I rearrange it as needed when new discoveries/obstacles warrant it. I also let team member choose which tasks they want to work on. As long as it is one of the high priority tasks. I don’t know if individual team members have their own list. I don’t care how they do their work as long as it gets done at high quality. I also publicly list tasks completed and the people who completed them. It makes it very obvious to everybody who the most productive people are. It’s a great motivator for the team because everybody wants to be #1.
blinding-streak 4y ago
https://twitter.com/tallmike/status/1427280948400328704?t=i7ysKIpN9B2ahM-PieX_Og&s=19 https://twitter.com/tallmike/status/1427280948400328704?t=i7... > I’m in the relatively rare position of having worked on both Chrome and IE3. To add all the truth @aboodman wrote, both teams were amongst the best I’ve worked with, but Chrome was much healthier, happier and more supportive. Senior industry folks helped.
gravypod 4y ago
To me it is clear that Age != Experience. Early in my career I have worked with many people, while being much older, were not as emotionally intelligent as I was. I have also worked with many people who were younger than I was who were more emotionally intelligent. That is what leadership mainly boils down to. Also, technical decisions should not come from the top. A leader should look at what something puts together and say "yea you covered your bases, go for it." My current TL is older than me by a big gap but my experience on many technical things out-ways theirs and so they defer to me. Their experience on the social side of things is far better than mine and I always defer to them for planning and comms advice. Basically: Age is a very poor proxy for how competent a leader is at running a team, making technical decisions, and many other factors that come to building large products. Selecting by age and putting the oldest person in change of a project is a horrible idea. Case in point: most governments are gerontocracy. How confident in the wise decision making powers of our political leadership?
throwaway892238 4y ago
> Would you live in a house built entirely by junior carpenters in their late 20s who built one or two houses that barely stood up? Well carpenters don't build houses by themselves. You might be talking about a framer, whose job is definitely important, but not really more important than most other of the trades needed to build a house. But actually by their late 20s a framer can have a decade of experience, more than enough to become a journeyman and frame with one or two assistants. It depends on when they apprenticed and became journeymen, where they learned the trade, and what their contracting and business ethics are. > Would you drive cars designed and built by junior engineers? Designers don't really build cars, but junior engineers are involved. Typically not leading themselves, though, as the handful of big car manufacturers can hire senior engineers to oversee them, and screwing up the launch of a car won't make it easy for you to work for one of the few competitors. People who make custom cars have probably been doing it for years as a hobby, and often aren't engineers at all. In the non-software world, if you build something, there is a direct tangible result of that thing coming into existence. Like, if you build a cabinet, the worst case that happens is the shelves fall apart, so you don't need a whole lot of guarantees as a consumer. If you're building a car, there's a shit-ton of regulations (today, anyway) and potential lawsuits. If you're building a house, there's the code, there's 30 different specialized trades, all kinds of restrictions on who can do what and when and how, and a hundred government inspections. But like in any trade, you can pass a test and still be a lying cheating piece of shit. (If you're a government contractor it's hard to tell if you're the former or incompetent) There is no magic spell or development lifecycle that stops shitty things from being shitty, or makes things automatically good. But sometimes there are regulations that enforce due diligence, and sometimes a contractor earns a good reputation through their results and word of mouth. Sadly, in the software world, there are practically no regulations, no [serious] trade groups, no apprenticeships, no unions, no threat of class-actions, and very very rarely any substantive real-world consequence to shame a company into hiring competent workers. Bottom line: if you work somewhere and you are not satisfied or don't feel the work is challenging enough, get better and move on. The only way to escape monotony is to raise yourself up.
michelb 4y ago
I think they wanted the best people on it and accept whatever they wanted/needed? I mean it is one of their most important products to dominate the web.

355 points by luu 4y ago

smrtinsert 4y ago

But what about the ceremonies?!?!

sktrdie 4y ago
He said there were no divorces! /s
jimjimjim 4y ago
everybody solemnly chants the holy words "you're on mute"

koala_man 4y ago

Sprint here refers to crunch time, and not agile development.

mattnewton 4y ago
Probably also was done without agile, I didn’t really see anyone doing “agile” in my time at google.
- cmrdporcupine 4y ago
  I did. Or rather, I saw teams that thought they were dong it, because they used pivotal-type tracking tools and stories. But it always degraded into broken-down-waterfall.
  - cornel_io 4y ago
    [flagged]
- koala_man 4y ago
  "Agile" means different things to different people. I would argue it's agile if you release early&often to continuously incorporate feedback, even if you don't play Planning Poker in Scrum Sprint Planning every two weeks.
  - ch4s3 4y ago
    > Planning Poker in Scrum Sprint Planning every two weeks I would argue that isn't agile at all.

nine_zeros 4y ago

But but, how else would I introduce more bureaucracy for engineers?

surfpel 4y ago

I'm not familiar with the twitter UI, does this put things in the correct order? https://threadreaderapp.com/thread/1427137725119959046.html https://threadreaderapp.com/thread/1427137725119959046.html In response to this thread: https://threadreaderapp.com/thread/1426587396343099397.html https://threadreaderapp.com/thread/1426587396343099397.html

bobobob420 4y ago
Never trust anyone who uses a series of tweets to say a paragraph.

pessimizer 4y ago

It was a product that no one had asked for and no one was waiting for, and wasn't intended to make a dime.

jahnu 4y ago
And yet this succeeds very rarely
- blondin 4y ago
  funny you say that, since we are talking about Google here, because Gmail has a similar story.
- pessimizer 4y ago
  People are actually very good at producing products that make no money that no one is asking for.
3a2d29 4y ago
This is an underrated point
senttoschool 4y ago
And the company's fortunes did not rest on the product being successful.
- pessimizer 4y ago
  Seeing as it's money-losing (like virtually all of non-ad google), it wouldn't have helped anyway. The only value to Chrome for Google is the monopolistic market-distortion through vertical integration.
  - alisonkisk 4y ago
  - satyrnein 4y ago

nsgi 4y ago

Obviously very good that Chrome was delivered without people doing lots of overtime. However, a lot of his argument seems to be about the age of the management, and surely ageism is illegal and it should be about the person's skills rather than being old enough to have school-aged kids or even how many decades of experience they have Edit: Okay, I guess the kind of ageism he is suggesting isn't illegal in the US, but it is in the UK and is still generally considered unethical

eterevsky 4y ago
What he writes about is seniority, not ageism. It's about whether to incentivize career paths in which senior engineers keep doing technical work.
jsty 4y ago
I won't try and read into whether or not there's ageism anywhere in the tweet stream, but certainly when talking about hiring the magic words are "find experienced engineers to run it". This is very much legal and ethical in the UK - we're not precluded from setting an experience-based hiring bar. I'm sure if a 25 year old had come along with two browsers under their belt they'd gladly have been hired into a leadership role too.
rvnx 4y ago
Maybe the secret is not really about the age or management skills, but rather that Chrome is an insanely profitable product (+ in a monopoly) so the pressure is rather low compared to a startup. Additionally whether a specific feature is ready or not for a specific cycle is not that important considering that there are releases every 6 weeks and even before for metrics gathering activities.
- Cederfjard 4y ago
  The author of the tweets is talking about when Chrome was first delivered, no? It wasn’t profitable, nor a monopoly, before it had come out.
gridspy 4y ago

majormajor 4y ago

This thread really seems to be burying the lede which isn't just "we didn't have crunch" but the more specific claim that it was engineers with at least a decade of experience having deep technical involvement that made the difference.

wolfgang42 4y ago

Worth noting, from the linked thread: > In light of all the responses, I really regret posting this tweet that mischaracterized reality: > In fact: The IE3 team did not have an unusual rate of divorce.I know of no broken families and only one divorce during the IE3 project. > Here’s my statement reflecting on this in greater depth: https://www.linkedin.com/pulse/my-recent-twitter-blow-up-hadi-partovi/ https://www.linkedin.com/pulse/my-recent-twitter-blow-up-had...

deleted 4y ago
[deleted]

United857 4y ago

Unlike IE, Chrome initially built off WebKit, so a lot of the work in writing a renderer was already done. Obviously a lot of work with V8, multiprocess IPC, etc. still went into the effort but still easier than starting from scratch like what IE did.

ubercore 4y ago
IE started with Mosaic, no?
- jerrygoyal 4y ago
  a lot of work with great UX as well
- kryptiskt 4y ago
  It started with Spyglass, who were Mosaic licensees, but apparently wrote their own code. The story of Spyglass is told here https://ericsink.com/Browser_Wars.html https://ericsink.com/Browser_Wars.html "Management made the decision to transition our business completely and pursue the market for web browsers. Tim Krauskopf, the founder and head of development, asked me to write a web browser. I started work on Spyglass Mosaic on April 5th, 1994. The demo for our first prospective customer was already on the calendar in May. I ended up as the Project Lead for the browser team. Yes, we licensed the technology and trademarks from NCSA (at the University of Illinois), but we never used any of the code. We wrote our browser implementations completely from scratch, on Windows, MacOS, and Unix. We were not the first Mosaic licensee, but we were the last. Prior to us, a company called Spry took the Mosaic code and tried to sell "Internet in a Box". People still seem to get Spry and Spyglass confused because of the similar names." "Internet Explorer 2.0 was basically Spyglass Mosaic with not too many changes. IE 3.0 was a major upgrade, but still largely based on our code. IE 4.0 was closer to a rewrite, but our code was still lingering around -- we could tell by the presence of certain esoteric bugs that were specific to our layout engine. Licensing our browser was a huge win for Spyglass. And it was a huge loss. We got a loud wake-up call when we tried to schedule our second conference for our OEM browser customers. Our customers told us they weren't coming because Microsoft was beating them up. The message became clear: We sold our browser technology to 120 companies, but one of them slaughtered the other 119."

zerr 4y ago

Off-topic: does 9-to-5 mean that 1-hour lunch break is considered as working time? How common is that?

khazhoux 4y ago
9-to-5 here is figurative. No one is tracking hours for software engineers at most companies. It just means: you start working in the morning, and you stop working in the evening. As opposed to working until late at night and/or weekends.
- zerr 4y ago
  I understand that. 9-to-5 is a common term, but I wonder why - many mention clocking out at 5, does that mean they arrive at 8 in the morning? Or maybe some have lunch on the keyboard while continue working.
  - khazhoux 4y ago
    The most common (by far) schedule I've seen across every software company is: arrive at 9, ~45-minutes lunch, leave at 6. Lots of people arrive before 8 but it's not the norm. 8am meetings --before COVID-- were always generally frowned upon.
  - ipaddr 4y ago
    Many places give you that hour. 35 hours weekly.
  - nicoburns 4y ago
    In Europe a 7.5hr day is standard, so 9-to-5 can be literally 9am until 5pm, with a 30 minute lunch break.
    - pmontra 4y ago
      I live in a Southern European country where the standard for office work is 9-18 with a one hour break starting between 12:30 and 13:30. On my last job as employee we were more flexible. I was starting at 10 maybe with even a 90 minutes break but I was usually in office until 19 or 20, which was OK because traffic was insane before then.

Barrin92 4y ago

>"I mean even at Google (on a different team) I was a "technical lead" in my 20s, and let me tell you, I had noooo business leading anything technical of any importance. But this is very common! We would never accept this in other fields. Would you live in a house built entirely by junior carpenters in their late 20s who built one or two houses that barely stood up? Would you drive cars designed and built by junior engineers?" one of the strangest and most baffling things about the entire industry tbh. Like, would you ever expect a 25 year old guy to command a spaceship? Yet in software you have these weekly "I'm 40, is my life over" posts. In most disciplines people correctly acknowledge that there's a sweet spot of skill and experience that overlaps somewhere in your late 30s, 40s or even 50s, yet in software very often we recreate Lord of the Flies, leading to chaotic project management.

andreilys 4y ago
The constitution was signed by 20-somethings e.g. James Monroe (18), John Marshall (20), Aaron Burr (20), Alexander Hamilton (21), and James Madison (25)
- kthejoker2 4y ago
  First, those are the ages of those men at the signing of the Declaration of Independence. The Constitution was not ratified until nearly 15 years later. Second, none of the people you listed signed the Declaration. The average age of the Declaration signers was 41; only 3 were younger than 30.
- butlerm 4y ago
  I am afraid you have an unreliable source. The Constitution was ratified by the states, not signed by delegates. At the time of ratification, the average age of the delegates was 42. James Madison, for example, was born in 1751 and was 36 years of age in 1787. Alexander Hamilton was born four years later and was 31 in 1787. There were only four delegates in their twenties.
vlovich123 4y ago
There are 20 year olds who demonstrate fine leadership skills and maturity. There are plenty of 40 year olds who do not. Find the best people you can regardless of age. Also, often times the only way to get that experience in the first place is to be put into the positions of leadership to develop your skills.

ryandrake 4y ago

If there's one much-believed software industry trope I wish would die, it's this idea that building great software requires constant heroics, crazy hours, mandatory crunch time, living at the office, and sacrificing your personal life and loved ones. That's how undisciplined and/or disorganized clowns do it, not professional software teams. When someone says, "Wow, we worked nights and weekends, guzzled Mountain Dew, pulled 48 hour coding shifts, drained our mental health, and half of us got divorced, but the result was this kickass video game!!" it's not admirable--it's sad. That's just not how it's supposed to be done, people! EDIT: This seemingly well-received comment seems to have ended up perma-locked to the bottom of the page. -weird!-

shadowgovt 4y ago
If anything, that kind of behavior should give the outside world pause and raise questions about the sustainability of any product output. That mattered less in the days of one artifact software development (and still matters less in areas like video games where that is the case), but software development these days is a process and many projects are far more marathon than sprint.
- ryandrake 4y ago
  > If anything, that kind of behavior should give the outside world pause and raise questions about the sustainability of any product output. It should give everybody pause, including software practitioners. A separate, but related pet-peeve is how these unsustainable heroics are often rewarded at work!! Boss: "Look at Chris over there--he stayed up until 4:30AM and fixed that ship-blocking bug. What a champ!" Chris gets a $1,000 spot bonus and now the rest of the team looks up to him as an example of good software development. Incredible but it happens almost everywhere!
khazhoux 4y ago
> it's not admirable--it's sad It's not just sad. It's often bullshit. I don't believe for one second when people say "I worked 120-hour weeks for 6 months!" Simple math tells you this is a farce. Even 100-hour weeks is not sustainable, unless people want to claim they literally did nothing but wake-commute-work-lunch-work-commute-dinner-sleep for weeks on end. Not buying it.

twsted 4y ago

Understand all and Aaron, at the question: "You guys forked webkit which forked khtml, so you all had a nice leg up no?" says: "Yes. Just like IE started from Mosaic Spyglass. But a rendering engine (like WebKit/Spyglass) is not a browser. Certainly not a multi process, sandboxed browser. Chrome v1 was a 200 person year effort." but, come on, much work was already done and they seem not to remember this.

doctor_eval 4y ago
Also, Chrome was using WebKit long before they forked it. IIRC, for several years they used the exact same engine used by Safari, and both Apple and Google were contributing to it.
zaphar 4y ago
No where in that thread is he suggesting they weren't standing on the shoulders of those who came before, but he's also right a rendering engine is not a browser and at the time Chrome was revolutionary in a number of ways. It was crazy fast. Even compared to other khtml browsers. It's multi-process architecture meant that for the first time a single page or tab couldn't take down your whole browser. And yes that was something I experienced frequently at the time. 200 person years to deliver a full browser that was an leap forward compared to the rest of the browsers is seriously impressive. His point stands they did it without a death march.

shadowgovt 4y ago

Sprints are only really necessary when there's a deadline to hit. For the longest time, one of the advantages Google has had as a software house is that when you're an industry leader, deadlines are soft because all you're worried about is somebody playing catch up, not your need to catch up to somebody else. As the company has grown in size and scale, calcified a bit, and branched out into spaces where they aren't the leader, the culture around this sort of thing has changed. They are not, for example, the leader in Cloud, and the life of a Cloud SWE is markedly different than the life of an ads or artificial intelligence research SWE.

vlovich123 4y ago
Sprints are just a formal way for management to check in that the team isn’t down a weird rabbit hole / getting them to do regular check ins with the team for visibility. It’s independent of deadlines.
seadan83 4y ago
If you replan at each sprint iteration, how does that help ensure a multi-sprint deadline is going to be achieved? My impression was the sprint is the deadline, so it emphasizes to not have deadlines in favor of small incrementalism. Hence, if there is an actual deadline, sprints I think are exactly the wrong tool to help
- pas 4y ago
  sprints deadlines are like milestones. the mantra of strive to deliver something in each sprint helps to prevent the failure mode when a year goes by and everything is in 85% readiness, but the last 15% will need another year (or more!)
  - seadan83 4y ago
    Sure, but if you plan out 10 milestones two weeks apart, is that not just "waterfall" at that point? To be sure, my main point is to disagree that sprints help hit deadlines. They might even hurt. For example. I'm not sure if that failure mode is really changed via sprints. if you get 10 months in, and 15% left, nothing changes that it could still take a year. Further, the sprints discourage lifting your head up to unblock, design and plan that 15% before you actually start on it. So seems a bit waterfall like to feel incremental stuff was getting done, but you still underscored that last 15%, and sprints encourage you to realize that very late in the game. I think a big flaw in scrum is error analysis of expected completion dates. Instead of compounding uncertainty across sprints, often that velocity is given no error bars and is linearly extrapolated months into the future (and in a perverse way increases estimate precision erroneously).

khazhoux 4y ago

Even since "Agile" starting taking off ~2010, it has made be very sad that many junior engineers today genuinely believe that somehow no software was ever written correctly without it. They were taught in school that there exists this bogeyman software development methodology called "WATERFALL" where pencil-pushers in a windowless office write requirements which they hand off in a printed binder to the team of engineers in the basement, who is not allowed to ever talk to the user. The Agile consultants somehow convinced a large segment of the industry that they discovered and/or invented the notion of working with users, of gathering feedback from them, of checking in with your teammates, etc. And they completely disregard the possibility that maybe --just maybe-- there are some developers who can get a metric shit-ton of work done without someone poking them repeatedly for status. And they popularized the term "Cowboy Coder" as a reckless developer who does whatever the hell he wants and dares you to mess with him. When in fact, their so-called "cowboys" are simply the best developers in the team, who write great code and don't need a scrum-master to help them plan it. But the Agile methodology resists the notion of some developers simply being awesome at their job -- in Agile, you are good at your job by meeting your "points" for every sprint.

mschuster91 4y ago
> They were taught in school that there exists this bogeyman software development methodology called "WATERFALL" where pencil-pushers in a windowless office write requirements which they hand off in a printed binder to the team of engineers in the basement, who is not allowed to ever talk to the user. Having worked in government and big-co companies before: sadly, this is not a bogeyman trope, but reality. Including the printed binder, although it's called "spec sheet" or "tender document" (or whatever the correct english words for "Ausschreibungsunterlagen" and "Lastenheft" are). The amount of "silos" and "leadership" involving themselves in petty fiefdom fights is astonishing - that is partially a reason why small startups are so much more efficient, they haven't had the time to develop layers and layers of middle management wanting to justify their existence, protecting budgets or establishing their authority. Government projects tend to be the worst target for such micromanager wannabe-king types, given that they can rarely be fired from their jobs for incompetence.
doctor_eval 4y ago

rr808 4y ago

Before Scrum we had 3x 1-hour team meetings a week to talk about what we're on and what we might need help with. After we went "agile" we moved to having 3x 1-hour team meetings a week with the same. Power to the developers. :)

khazhoux 4y ago
Ha, I remember the first project I encountered that "went Agile." The weekly team meeting (which everyone complained about) was replace with daily standups (30 minutes), a two-hour retrospective (useless) every 2 weeks, and a 2-hour sprint planning every 2 weeks. Power to the developers indeed.
- IMTDb 4y ago
  So basically, you are able to find the time to criticise your team process in a completely unrelated HN post. But when there is dedicated time for that - in the process itself - you call it "useless" ? ;-)
  - khazhoux 4y ago
    Not unrelated: the entire comment thread is about developer process. And retrospectives were useless in the most literal way. The time spent every week going over "What worked well? What could have gone better?" did not materially improve the team's effectiveness.
    - IMTDb 4y ago
      The next retro is the place to discuss why these retro do not yield to any measurable improvement, and agree on a better process/schedule that works for your team. If your point is that your team processes are sooo perfect and sooo amazing that there is nothing to criticise, review or change, I'll have a hard time believing that. If your point is that no matter how much time you spend on these meetings, nothing changes, I'd argue that you need to spend even more time and energy on them on them as you clearly haven't figured out how to efficiently gather, analyse and act on self-reflection of you team processes. The retro itself might be the starting point of your thought process since it seems so "useless" and yet is absolutely essential if you don't want an external "manager" to do that job for you.

dijonman2 4y ago

Sprints are to knock down the high achievers and provide an opportunity for substandard developers to all appear as if there is progress. A place to hide, if you will. All of the high functioning teams I’ve worked on didn’t have any kind of agile structure. Agile can be done well, but more often than not it isn’t.

i_love_cookies 4y ago
I mean, that's true to an extent but there's large volumes of software that has no use for high achievers and is better off with process consistency and predictability the development of something like Chrome isn't one of those project but say a banking website or a inventory management system could be

oars 4y ago

I wonder how UNIX would look if it had been delivered with Agile.

pas 4y ago
wasn't it delivered with the principles? individuals before process? guys talking to each other informally and adding features they found useful (feedback from users, delivering value quickly)

thrwy_918 4y ago

The author is using the word a bit differently, but the fact that "sprint" has been normalized as a unit of work for software development, and developers are expected to be in a "sprint" more or less at all times, has always been a source of the deepest absurdity to me. A "sprint" is, almost by definition, a pace that's sustainable only for short periods. The fact that developers are expected to perform sprint after sprint endlessly, to view "sprint" as the default baseline pace, seems a ludicrous abuse of language.

butlerm 4y ago
It certainly implies developers recovering for several days between sprints.
throwaway821909 4y ago
I think the language is accurate and that's the problem (or not depending on your perspective) - sprints are all or nothing, and a way to create an artificial sense of urgency. "It's the last day of the sprint, better work late/cut corners because 99% done is failure". And then if you do your reward is one more work item next sprint, to ensure everyone is working as hard as possible all the time.
slim 4y ago
if memory does not fail me, original sprint was 3 weeks long followed by "spare" time till the end of the month (mostly meetings, planning, review, etc..)
paulryanrogers 4y ago
Was the word 'sprint' chosen to describe a never ending crunch? Or just to roughly imply quick forward motion. Unlike waterfall that often slows for large portions of time until the next sudden and irreversible release? Perhaps it would've been more accurate to use something like 'unit' in education. Which is just a subdivision of time and effort roughly equal to a week or two.
crazygringo 4y ago
I think you're being overly literal with "sprint". And no, developers are not expected to be "in a sprint more or less at all times". To the contrary -- in between each sprint, there's a review, a retrospective, often a weekend, then regrouping and feature analysis, planning poker, decision on which features to impement, and getting it up on the board. That's the whole point. Instead of a long marathon without revision/reassessment/regrouping, it's a series of short sprints interspersed with revision/reassessment/regrouping. The metaphor here is the distance traveled, not the speed. Sprints are shorter distances, that's all. Nobody has ever intended "sprint" to mean that engineers are going faster than in a marathon, anymore than "waterfall" means engineers are all tumbling down white water to their deaths at the bottom. :)

babyshake 4y ago

A sprint means to go as fast as you possibly can, and is associated with exertion to the point of exhaustion. There's a reason managers love the word sprint.

jmyeet 4y ago

> I mean even at Google (on a different team) I was a "technical lead" in my 20s, and let me tell you, I had noooo business leading anything technical of any importance. But this is very common! So these big tech companies have a caste system. And no I don't mean the Indian caste system, which obviously has its own controversies. The caste system is really a form of social proof. Did you go to MIT, Stanford, UW, Waterloo or CMU? Ok, you're in the club. You can join TI (Technical Infrastructure). Out of college you'll be L5 in 2-3 years (the same level an external hire with 10 years of experience will have). You will find yourself on the better projects with more promotion prospects. This kind of premature promotion is to find the 1 in 20 of these people who are truly talented enough to continue getting promoted to L6-8+.

google234123 4y ago
Is TI really regarded better than search? Do they typically promote faster?
evmar 4y ago
This comment is pretty ironic given that Aaron (the person you’re quoting) didn’t go to college at all. Source: https://blog.thirdyearmba.com/not-everyone-should-attend-college-but-lets-n https://blog.thirdyearmba.com/not-everyone-should-attend-col...
- zaphar 4y ago
  I worked at Google for 7 years and never went to college either. I was never hampered by that in my career. If anything people were more impressed that I was doing this without the degree than if I had actually had a degree to point at.

olliej 4y ago

I really don't understand the "sprints" approach to development - I've never worked on any project where it makes sense, either the things I've been working on take less time than a "sprint" or they take longer, and that's for any sprint length you can produce. Real software requires some degree of planning, and sprints seem to be more an attempt to avoid that planning. I don't mean to the level of gantt chart hell (I've experienced that as well). Sprints, at least as they actually occur in the real world, seem to actively harm any large scale projects, and increase the overhead for long term projects if you can get them to fit.

pas 4y ago
there are different thoughs on this, but .. the team should not pick a task until it's clear what to do and until it's broken down into something that they think/agree can be delivered in one iteration. this is usually called refinement. (as the raw user requirements are transformed into a concrete design and then tasks) http://tryqa.com/wp-content/uploads/2014/12/scrum-methodology.gif http://tryqa.com/wp-content/uploads/2014/12/scrum-methodolog... if something is so unclear that the design/planning itself requires prototyping something, then that can be added as a task for the sprint. then when it's done, on the next refinement the team is in a better position to find a good design.

_gabe_ 4y ago

> I mean even at Google (on a different team) I was a "technical lead" in my 20s, and let me tell you, I had noooo business leading anything technical of any importance. But this is very common! We would never accept this in other fields. Would you live in a house built entirely by junior carpenters in their late 20s who built one or two houses that barely stood up? Would you drive cars designed and built by junior engineers? I find this kind of funny, because this is what happens right? I was under the assumption that architects typically design the building plans and do all the engineering, and a construction crew (which can consist of people mainly in their 20s) will build those plans under the supervision of the lead engineers/architects. So, in the same way that many senior software engineers don't write much code, don't architects/civil engineers typically refrain from using power tools to build the actual building? If this is the case, then software engineering is very akin to other engineering disciplines in this regard. I feel like the author of this tweet is conflating craftsmen with senior leads. A craftsmen is somebody I would expect to have been working with the medium for 10+ years, and continues honing their craft throughout the years. Whereas engineers and architects are typically more concerned with the abstract ideas and overall outcome. An engineer/architect can be a craftsman, but I don't believe they need to be synonymous.

nso95 4y ago
Well an early career civil engineer isn't building the actual structures either
aboodman 4y ago
Not at all. Every construction project has a site lead, usually in their 30s or 40s who has decades of experience.
suzzer99 4y ago
A software architect who doesn't code anymore is worse than useless in all of my experience. They're flimflam salespeople who build PowerPoints full of buzzwords that aren't even necessary, and then delegate everything to developers who actually code to try to build their Frankenstein contraptions. "But we have to have websockets, it's in the presentation!"

throwfh80h82 4y ago

I'm not advocating for death marches, but a small project being built in a company that has a money machine printing billions of dollars a quarter isn't reflective of most environments.

nojvek 4y ago
Microsoft had a machine printing billions of dollars but their environment was quite different. I was in IE team on dev tools. We shipped every 6 months, while chrome shipped every month. In the last 2 months of 6 months release, we had feature code freeze. Even small bug fixes weren’t allowed. First month was planning. Our dev pace was slower than Chrome. Chrome shipped a lot more in 6 months than IE did. Chrome had an insane testing suite that tested pixel perfect rendering and Perf benchmarks. Doing this on every pull request is just amazing. IE had some work to do. I was surprised to learn that the E2E test results were hosted on some engineer’s dev machine in his office. We used to run tests on our machine before committing to source depot. IE CI/CD had a lot to desire. My takeaway from IE vs Chrome was that Chrome had good leadership, they highly invested in all kinds of tooking to encode their security, UX, performance bars. IE leadership was sometimes far away from the user experience. They didn’t care about the little big things.
- mike_hearn 4y ago
  Yeah but many of those things are a direct consequence of budgets. If you are willing to throw 100 incredibly well paid engineers at nothing but testing infrastructure then you can get that sort of result but it's implausible to expect a normal company to invest the same amount. Even today Microsoft couldn't match Google's investment in Chrome and simply gave up. It's worth observing here that Chrome was not just unusual in having access to a huge budget and highly experienced senior engineers, but also in the fact that it was the passion project of Larry Page. The Chrome team could take their time, because Page simply wanted to do a browser and always had, end of story. I worked at Google at the time and I recall vividly that Page/Brin never emailed the entire company in the way most CEOs do. They appeared at TGIFs but emailing the whole firm at once? They just didn't do it. With one exception (that I can recall at least): the day Chrome launched. Not only did Page email the whole firm but he sent a short, informal and clearly ecstatic note proclaiming that Chrome was "spectacular". Schmidt opposed the idea the entire time, so Page and Brin just hired a bunch of browser engineers behind his back and funded what was basically a black project. Schmidt later stated he was basically forced to change his mind "because it was so good". In reality he was forced to because he'd been there before and it would have been self destructive to try to cancel an already running project the company founders were so in love with. Remember, at the time Chrome launched it: 1. Only ran on Windows. 2. Couldn't print, amongst many other missing features. 3. Had no extensions and wouldn't for quite some time. 4. Had numerous page compatibility problems with many major websites that simply didn't work at all, due to its KHTML heritage, UA sniffing etc. 5. Had a pitch so complicated and developer centric you needed an entire comic book with the developers in it to try and explain why anyone should care. Not surprisingly given the above, it had a brief usage spike as people tried it out and its usage then collapsed to nearly nothing, taking (iirc) years to rebuild to its initial launch spike level despite being heavily pushed via the google.com homepage. Also, Chrome was entering a market with largely stagnant competitors, unlike the IE3 team, who were (or believed they were) fighting a successful, energized, passionate company that posed an existential threat to Microsoft's business. The IE team faced time pressure. When Chrome appeared there was Safari, which didn't care about the Windows market and was there mostly as a feature tick box for Apple's operating systems. The IE team was still disbanded at that point. Firefox was an inspiration but basically funded by Google anyway, and was struggling with tech debt. I'd say Chrome 1.0 was competently executed but in any kind of normal company, with normal goals (like usage or profit), in which the project wasn't the passion project of an invulnerable CEO, they would absolutely have had to crunch like crazy and would then have certainly been cancelled or gone bankrupt despite that, due to the near total focus on engineering over all else. It worked, in the end. I'm writing this from Chrome after all because Safari is inexplicably buggy even though I'm using a Mac, and with time they did get to add plenty of compelling features. Also being able to outspend their competitors meant taking control of HTML5 and putting other companies in a position where all their budget is taken by trying to keep up with whatever random features they threw into the spec. But anyway, the reason the Chrome team could live normal 9-5 lives is nothing to do with senior engineering leadership. To claim otherwise seems kinda unfair on everyone building new products who does not have a time/money budget set by a near-obsessed CEO who also happens to control the google.com homepage. A good example of a team it'd be unfair to was the Android team, who also had very experienced senior engineers with OS dev experience, but whose position was far more similar to that of the IE3 team. Android's creation was typified by enormously punishing hours and huge amounts of crunch.

deleted 4y ago

[deleted]

aantix 4y ago

If unfinished stories just roll over in to the next sprint, is there any point to the sprint?

antonvs 4y ago
One point is to identify what work the team is supposed to be focused on, and help avoid arbitrary distractions.
pas 4y ago
estimation. you can look back over the previous sprints and see how much on average has been done in one. then you do reference class estimation of the incoming tasks. (story points are used for this.)

mbrodersen 4y ago

I have delivered successful software for 30+ years without sprints or any other ceremonies. I simply keep a prioritised “to do” list and only work on what is the #1 priority. I do it when managing development teams and when working as part of a team. It’s simple. It works. And when asked to change priorities, it is clear from the priority list what the consequences will be. And usually people will change their minds when they can easily see the consequences. It also means that you never need to say no. You simply add the new task to the priority list and negotiate whether it moves up/down relative to other tasks.

pas 4y ago
when asked do you give estimates? how many people can ask you to move something up/down? is your list public to others? does it happen that the #1 thing is blocked by some dependency? (do you simply move to #2?) how do you manage a team? (do they work on your list or they have theirs?)
- mbrodersen 4y ago
  Yes I give estimates when asked. I use the priority list to negotiate the number of deliverables agreed to. The list makes it easy for biz people to balance time vs. deliverables. Yes if #1 is blocked then I work on #2 until #1 is unblocked. And if #2 is blocked then I work on #3 etc. I use a single prioritised list to manage teams. The list is public to the team and I rearrange it as needed when new discoveries/obstacles warrant it. I also let team member choose which tasks they want to work on. As long as it is one of the high priority tasks. I don’t know if individual team members have their own list. I don’t care how they do their work as long as it gets done at high quality. I also publicly list tasks completed and the people who completed them. It makes it very obvious to everybody who the most productive people are. It’s a great motivator for the team because everybody wants to be #1.

blinding-streak 4y ago

https://twitter.com/tallmike/status/1427280948400328704?t=i7ysKIpN9B2ahM-PieX_Og&s=19 https://twitter.com/tallmike/status/1427280948400328704?t=i7... > I’m in the relatively rare position of having worked on both Chrome and IE3. To add all the truth @aboodman wrote, both teams were amongst the best I’ve worked with, but Chrome was much healthier, happier and more supportive. Senior industry folks helped.

gravypod 4y ago

To me it is clear that Age != Experience. Early in my career I have worked with many people, while being much older, were not as emotionally intelligent as I was. I have also worked with many people who were younger than I was who were more emotionally intelligent. That is what leadership mainly boils down to. Also, technical decisions should not come from the top. A leader should look at what something puts together and say "yea you covered your bases, go for it." My current TL is older than me by a big gap but my experience on many technical things out-ways theirs and so they defer to me. Their experience on the social side of things is far better than mine and I always defer to them for planning and comms advice. Basically: Age is a very poor proxy for how competent a leader is at running a team, making technical decisions, and many other factors that come to building large products. Selecting by age and putting the oldest person in change of a project is a horrible idea. Case in point: most governments are gerontocracy. How confident in the wise decision making powers of our political leadership?

throwaway892238 4y ago

> Would you live in a house built entirely by junior carpenters in their late 20s who built one or two houses that barely stood up? Well carpenters don't build houses by themselves. You might be talking about a framer, whose job is definitely important, but not really more important than most other of the trades needed to build a house. But actually by their late 20s a framer can have a decade of experience, more than enough to become a journeyman and frame with one or two assistants. It depends on when they apprenticed and became journeymen, where they learned the trade, and what their contracting and business ethics are. > Would you drive cars designed and built by junior engineers? Designers don't really build cars, but junior engineers are involved. Typically not leading themselves, though, as the handful of big car manufacturers can hire senior engineers to oversee them, and screwing up the launch of a car won't make it easy for you to work for one of the few competitors. People who make custom cars have probably been doing it for years as a hobby, and often aren't engineers at all. In the non-software world, if you build something, there is a direct tangible result of that thing coming into existence. Like, if you build a cabinet, the worst case that happens is the shelves fall apart, so you don't need a whole lot of guarantees as a consumer. If you're building a car, there's a shit-ton of regulations (today, anyway) and potential lawsuits. If you're building a house, there's the code, there's 30 different specialized trades, all kinds of restrictions on who can do what and when and how, and a hundred government inspections. But like in any trade, you can pass a test and still be a lying cheating piece of shit. (If you're a government contractor it's hard to tell if you're the former or incompetent) There is no magic spell or development lifecycle that stops shitty things from being shitty, or makes things automatically good. But sometimes there are regulations that enforce due diligence, and sometimes a contractor earns a good reputation through their results and word of mouth. Sadly, in the software world, there are practically no regulations, no [serious] trade groups, no apprenticeships, no unions, no threat of class-actions, and very very rarely any substantive real-world consequence to shame a company into hiring competent workers. Bottom line: if you work somewhere and you are not satisfied or don't feel the work is challenging enough, get better and move on. The only way to escape monotony is to raise yourself up.

michelb 4y ago

I think they wanted the best people on it and accept whatever they wanted/needed? I mean it is one of their most important products to dominate the web.