6 ms·

In my case I work at Google. Company-wide, we aggressively push code quality. You cannot submit code without someone reviewing it. You cannot submit code in a l

by jfasi 9y ago

In my case I work at Google. Company-wide, we aggressively push code quality. You cannot submit code without someone reviewing it. You cannot submit code in a language in which you aren’t certified as proficient without someone with proficiency (called readability) reviewing it. Our review tools run automated code quality heuristics and present negative results to the reviewer. All affected unit tests are run when you request review and all negative results are highlighted. You can’t modify another team’s code without their approval at review time. We have an entire team dedicated to performing modernizing refactors across our entire codebase to remove deprecated methods, migrating to new language features, etc. Unit testing isn’t strictly enforced, but we have automated dashboards that will show you your coverage and guilt you if it’s poor. This is just the stuff I can name off the top of my head. The result of all this is that even if a team wants to just get things done, they’re going to be nudged in the direction of better quality simply by using our tools. As for my team, I work in Ads. We’re a group of just over half a dozen people operating a handful of revenue-critical systems, and our code quality standards are raised accordingly. From a management perspective, it doesn’t make sense to hire a group almost entirely composed of PhDs and then have them spend their time putting out fires caused by sloppy implementstions. We put a lot of effort into getting the code right at the outset and then running it for years without need for massive intervention. In my experience this involves a few things. First, we tolerate a fair bit of deadline slip. Google isn’t exactly gonna go broke without our newfangled product, so if we need an extra half a quarter to make it happen right, then we take it. Secondly, we write up thorough design documents before breaking ground. This means few surprises at implementation time, letting us focus on getting the code right. Finally, we spend a lot of time refactoring and cleaning things up. Systems balloon over time, and sometimes it’s more cost effective to clean house and make otherwise complex changes simple. Doubly so if subsequent changes are also made easier. I can’t speak for the rest of the company, but I think our team’s standards are pretty high.

hellokadi 9y ago
"Secondly, we write up thorough design documents before breaking ground." Design documents? Sounds scarily like waterfall to me.
- barry0079 9y ago
  When did planning and design stop being the first stage of a sprint? Agile doesn't mean start writing code before planning and requirements gathering.
- sturgill 9y ago
  What's wrong with waterfall? I've got a buddy who works at Lockheed on the f22 and a brother who's a pilot in the Air Force. I prefer certain systems be completely spec'd out before a single line of code is written. Moving fast and breaking things isn't the only way to write code.
  - Jtsummers 9y ago
    Waterfall sucks. I say this as a guy with experience in the kind of systems you mention (though not the F-22). Waterfall itself leaves little room for early feedback which means schedules are always delayed and problems are pushed to the next block cycle (a 12-24 month activity). Integration of changes is delayed until the last minute (versus the lean software concept of the last responsible moment). Testing turns into a massive clusterfuck at PFQT and FQT which is the last stage of a waterfall cycle. Waterfall assumes you can know too many things at the start and have everything go right. It fails when it encounters the real world but is still pushed by program offices across the DOD despite extreme cost and schedule overruns and quality issues. I’m out now and on mobile. But I can write in more detail later if you want about the problems of the pervasive waterfall method in DOD projects. Even the DOD systems acquisition documents have endorsed iterative/incremental (a slow motion agile/lean when you dig into it) development models since 1985 but still Waterfall lives on.
  - Jtsummers 9y ago
    Waterfall, Or why I hate government projects There's a lot of options between "moving fast and breaking things" and waterfall. And almost every one of them is better than waterfall. Let's be clear on terms. True Waterfall is a single sequential pass: Analysis, design, development, testing. There is no feedback, there is no room for error. Now, you think there being no room for error sounds good until your project is years late and billions overdue. Because no time was allowed for feedback and correcting for errors, they're discovered late (in testing) and either: 1) you loop back then and fix it [0] 2) you "descope" requirements and whittle it down to a functioning, but incomplete, system 3) you push through and finish it on time (because in most Waterfall shops the estimated schedule is a commitment) and deliver a buggy product (that in the USAF and others can, and has, literally meant death). Implemented waterfall actually allows for a greater degree of feedback. Maybe they even do unit tests on software [1] so they have some degree of effective testing during development. More often, they keep the Waterfall idea of big testing at the end. By this I mean a 1+ month event where a comprehensive test suite is executed. This is preceded by a preliminary execution which also takes 1+ months. So let's say you have a 15 month project, this means they literally schedule 2+ months to executing these tests and this is the only time they will execute all of them. Between the PFQT and FQT they will deal with any rework. They still treat estimates as commitments and still rush crappy code out to the customer. So every defect is discovered as late as possible, rather than as early as possible. Any error in logic, any error in design (which is the most critical cause of lack of safety and reliability in systems) will not be found until month 12 or 13 of a 15 month project, if it's found in this cycle at all. There is no place in this world for Waterfall in any variation except for small projects (less than 30k or so lines of C) or projects that have been done a hundred times before by the same team who is going to do it now (they are literally the only ones who can get this done). But most companies will still try to do waterfall with teams of novices (to the domain, often to the profession to as they prefer cheap new grads to experienced developers and experts). The DoD has, since 1985, endorsed a model based on iterative and incremental development. This means that you scope your initial necessary features, and over a series of projects you add in the extra ones (including ones you may not have thought of to start with, either on oversight or something that changed). Within each project cycle the iterative model has you doing a rough equivalent of the "sprints" in Agile (big-A) shops. Though often longer (still 1-3 months rather than aiming for days or weeks). However, since there's always a lag this wasn't really picked up by leadership until the 1990s so most of the present leadership still started their careers in the Waterfall world of the 1980s (civil service tends to stick around for 40 years) and still insist on peddling that bullshit rather than adopting more sensible development models. There is no feasible way that anyone working on the F-35, originally conceived in 1992!!!, could have possibly laid out the work for that project properly in a Waterfall approach. Which is also probably why it was years late, billions over budget, and failed to meet some operational requirements when it was finally delivered. [0] Too late to be effective because everyone who did the development has been laid off or reassigned or simply slept and forgotten what they did a year earlier. [1] The initial developers may, but they will strip this out before handing it off to the maintenance programmers who are in a different company. Can't help the competition, customer be damned.
expertentipp 9y ago
sounds like no fun at all
- toomuchtodo 9y ago
  Processes that ensure high value code (longevity, readability, maintainability) rarely are, but that's what pays the bills.
  - expertentipp 9y ago
    If processes and algorithms hold such tight grip on any new code created, just employ the same processes and algorithms to create the code itself:) Humans just seem obsolete there.
    - toomuchtodo 9y ago
      Your humans still end up writing those processes and algorithms :) it's just a fancier IDE!
      - expertentipp 9y ago
        I bet there are flow diagrams created by drag and dropping things. Any corporate process-related software evolves in a final form into an UI with diagrams created by drag and dropping things.
- jfasi 9y ago
  It sounds like it, but in practice it’s not as onerous as you’d think. If someone’s idea of fun is to play the cowboy, the no, it’s not fun. On the other hand the problems we deal with in designing and implementing systems like this are so challenging and unique that they more than make up for the added process.
- blub 9y ago
  Creating robust software is both challenging and satisfying. It doesn't need to be "fun" to be enjoyable.
sturgill 9y ago
The great part about this process is that, in my opinion, it highlights the importance of pragmatism. Google, as multi-billion dollar ad company, is understandably (and I would say, correctly) risk adverse when it comes to changes to its bread and butter. But if a new startup tries to replicate a process whose aim is to produce code that "[runs for] years without need for massive intervention" before they've established product/market fit, they will run out of cash. Google has very specific needs. Code quality requirements for banking software is different than a CRUD app. IMHO, the best path is to be honest with where you are as a company. Some times you need to just see what works, and multiple cheap iterations that you have no plan to support in the future can be critical to success. Other times you're making billions of dollars and the most important thing is to not screw up. With every variation in between. So at my company: our subscription and payment handling is designed to run for years. Not screwing up is the most important. Certain product features are pushed as quickly to market as we can, with an eye towards future stability. "Good enough" being good enough.

by jfasi 9y ago

hellokadi 9y ago

"Secondly, we write up thorough design documents before breaking ground." Design documents? Sounds scarily like waterfall to me.

barry0079 9y ago
When did planning and design stop being the first stage of a sprint? Agile doesn't mean start writing code before planning and requirements gathering.
sturgill 9y ago
What's wrong with waterfall? I've got a buddy who works at Lockheed on the f22 and a brother who's a pilot in the Air Force. I prefer certain systems be completely spec'd out before a single line of code is written. Moving fast and breaking things isn't the only way to write code.
- Jtsummers 9y ago
  Waterfall sucks. I say this as a guy with experience in the kind of systems you mention (though not the F-22). Waterfall itself leaves little room for early feedback which means schedules are always delayed and problems are pushed to the next block cycle (a 12-24 month activity). Integration of changes is delayed until the last minute (versus the lean software concept of the last responsible moment). Testing turns into a massive clusterfuck at PFQT and FQT which is the last stage of a waterfall cycle. Waterfall assumes you can know too many things at the start and have everything go right. It fails when it encounters the real world but is still pushed by program offices across the DOD despite extreme cost and schedule overruns and quality issues. I’m out now and on mobile. But I can write in more detail later if you want about the problems of the pervasive waterfall method in DOD projects. Even the DOD systems acquisition documents have endorsed iterative/incremental (a slow motion agile/lean when you dig into it) development models since 1985 but still Waterfall lives on.
- Jtsummers 9y ago
  Waterfall, Or why I hate government projects There's a lot of options between "moving fast and breaking things" and waterfall. And almost every one of them is better than waterfall. Let's be clear on terms. True Waterfall is a single sequential pass: Analysis, design, development, testing. There is no feedback, there is no room for error. Now, you think there being no room for error sounds good until your project is years late and billions overdue. Because no time was allowed for feedback and correcting for errors, they're discovered late (in testing) and either: 1) you loop back then and fix it [0] 2) you "descope" requirements and whittle it down to a functioning, but incomplete, system 3) you push through and finish it on time (because in most Waterfall shops the estimated schedule is a commitment) and deliver a buggy product (that in the USAF and others can, and has, literally meant death). Implemented waterfall actually allows for a greater degree of feedback. Maybe they even do unit tests on software [1] so they have some degree of effective testing during development. More often, they keep the Waterfall idea of big testing at the end. By this I mean a 1+ month event where a comprehensive test suite is executed. This is preceded by a preliminary execution which also takes 1+ months. So let's say you have a 15 month project, this means they literally schedule 2+ months to executing these tests and this is the only time they will execute all of them. Between the PFQT and FQT they will deal with any rework. They still treat estimates as commitments and still rush crappy code out to the customer. So every defect is discovered as late as possible, rather than as early as possible. Any error in logic, any error in design (which is the most critical cause of lack of safety and reliability in systems) will not be found until month 12 or 13 of a 15 month project, if it's found in this cycle at all. There is no place in this world for Waterfall in any variation except for small projects (less than 30k or so lines of C) or projects that have been done a hundred times before by the same team who is going to do it now (they are literally the only ones who can get this done). But most companies will still try to do waterfall with teams of novices (to the domain, often to the profession to as they prefer cheap new grads to experienced developers and experts). The DoD has, since 1985, endorsed a model based on iterative and incremental development. This means that you scope your initial necessary features, and over a series of projects you add in the extra ones (including ones you may not have thought of to start with, either on oversight or something that changed). Within each project cycle the iterative model has you doing a rough equivalent of the "sprints" in Agile (big-A) shops. Though often longer (still 1-3 months rather than aiming for days or weeks). However, since there's always a lag this wasn't really picked up by leadership until the 1990s so most of the present leadership still started their careers in the Waterfall world of the 1980s (civil service tends to stick around for 40 years) and still insist on peddling that bullshit rather than adopting more sensible development models. There is no feasible way that anyone working on the F-35, originally conceived in 1992!!!, could have possibly laid out the work for that project properly in a Waterfall approach. Which is also probably why it was years late, billions over budget, and failed to meet some operational requirements when it was finally delivered. [0] Too late to be effective because everyone who did the development has been laid off or reassigned or simply slept and forgotten what they did a year earlier. [1] The initial developers may, but they will strip this out before handing it off to the maintenance programmers who are in a different company. Can't help the competition, customer be damned.

expertentipp 9y ago

sounds like no fun at all

toomuchtodo 9y ago
Processes that ensure high value code (longevity, readability, maintainability) rarely are, but that's what pays the bills.
- expertentipp 9y ago
  If processes and algorithms hold such tight grip on any new code created, just employ the same processes and algorithms to create the code itself:) Humans just seem obsolete there.
  - toomuchtodo 9y ago
    Your humans still end up writing those processes and algorithms :) it's just a fancier IDE!
    - expertentipp 9y ago
      I bet there are flow diagrams created by drag and dropping things. Any corporate process-related software evolves in a final form into an UI with diagrams created by drag and dropping things.
jfasi 9y ago
It sounds like it, but in practice it’s not as onerous as you’d think. If someone’s idea of fun is to play the cowboy, the no, it’s not fun. On the other hand the problems we deal with in designing and implementing systems like this are so challenging and unique that they more than make up for the added process.
blub 9y ago
Creating robust software is both challenging and satisfying. It doesn't need to be "fun" to be enjoyable.

sturgill 9y ago

The great part about this process is that, in my opinion, it highlights the importance of pragmatism. Google, as multi-billion dollar ad company, is understandably (and I would say, correctly) risk adverse when it comes to changes to its bread and butter. But if a new startup tries to replicate a process whose aim is to produce code that "[runs for] years without need for massive intervention" before they've established product/market fit, they will run out of cash. Google has very specific needs. Code quality requirements for banking software is different than a CRUD app. IMHO, the best path is to be honest with where you are as a company. Some times you need to just see what works, and multiple cheap iterations that you have no plan to support in the future can be critical to success. Other times you're making billions of dollars and the most important thing is to not screw up. With every variation in between. So at my company: our subscription and payment handling is designed to run for years. Not screwing up is the most important. Certain product features are pushed as quickly to market as we can, with an eye towards future stability. "Good enough" being good enough.