Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming

At EA, It Can Take a Whole Day To Change 3 Lines of Code (neowin.net) 145

New submitter segaboy81 writes: In 2001 the Manifesto for Agile Software Development was born, and it took the software engineering world by storm. Linux, Windows, Facebook, AAA games, and just about everything else, adheres to this manifesto in some form or another. It is a paradigm that allows teams to work collaboratively on projects in the most effective and streamlined way possible. However, EA may not have gotten the memo. According to a blogpost by former EA developer Adam Berg, different teams take very different approaches to development with one team in particular being especially slow to progress. Adam recounts his experience on the FIFA team where he worked on the Wii, PS Vita, and Nintendo 3DS ports of the game: "I often worked in the realm of competition logic. Testing changes here could mean progressing through several seasons of career mode in order to test out a change. No joke, it would take an entire day to change 3 lines of code and know that it actually worked correctly."
This discussion has been archived. No new comments can be posted.

At EA, It Can Take a Whole Day To Change 3 Lines of Code

Comments Filter:
  • by Anonymous Coward on Thursday December 16, 2021 @02:48PM (#62087565)

    Sure its easy to say that it's just "three lines of code", but is the code in a critical performance path in the software? One that where a minor change can alter the performance drastically?

    Not all three lines of code are the same.

    • by fermion ( 181285 )
      It is because few here have software, much less a honest days work. There are low level functions which are highly optimized and have to work on suc function, a few lines, took me two days to work and verify. Some are business critical involving business rules. Went back and forth on one of these for a week.
    • by mlheur ( 212082 ) on Thursday December 16, 2021 @03:39PM (#62087901)

      The headiline should have said "At EA it can take a day to perform full regression testing on 3 lines of changed code". But that's not news...

      • by jythie ( 914043 )
        Yeah, once i saw the bit about testing the headline became pretty mundane. I've worked on projects that have full day or multi-day testing cycles, even worse, projects with multi-day testing cycles and no online update capability.. so there were times in the cycle where there was a lot of pressure to keep changes minimal and run the full test plan, so '3 days for 3 lines' was a very real ratio.
        • Shit, I'd love it only take a day to get code in at work.

          It can take a week to get approval after testing says it's good.

        • I was on a project for autonomous driving and driver assistance systems.

          Testing involves (amoung automatic tests) driving the car on the road, and making sure changed lines are actually executed during test drives.

          Could take days or weeks until the conditions were met that the lines actually were executed.

      • by thegarbz ( 1787294 ) on Thursday December 16, 2021 @07:12PM (#62088707)

        The headiline should have said "At EA it can take a day to perform full regression testing on 3 lines of changed code". But that's not news...

        EA doing testing? Are you kidding, that would be the biggest news of the year.

    • 3 lines of code that fast seems a bit rushed. Seriously. Unless you're doing web apps with continuous customer-tested delivery, you need to verify the software before anyone else sees it.

  • Where's QA? (Score:3, Insightful)

    by skam240 ( 789197 ) on Thursday December 16, 2021 @02:51PM (#62087583)

    This is a major game publisher, where's the QA team? Their literal purpose is so much higher paid programmers don't have to spend an entire day testing a small change.

    • by splutty ( 43475 )

      You seem to be under the mistaken impression that EA has proper QA. (As in properly trained and paid)...

      • by skam240 ( 789197 )

        Fair point. I actually worked in a major game publishers QA department for a few years in the late 90's and early 2000's and it was great work for a kid just getting out into the world but I hear nowadays it's just shit working in any capacity for the major publishers.

    • Re:Where's QA? (Score:4, Informative)

      by Len ( 89493 ) on Thursday December 16, 2021 @03:10PM (#62087725)

      It's the programmer's job to write correct code. You're not supposed to submit untested code and wait for QA to send it back to you.

      That's how I've always worked, anyway. I say it takes half a day to change a line of code, including time to test it, commit it, update the bug report, etc.

      • by sjames ( 1099 )

        Often it makes sense for each developer to have a personal git repo, then test their changes and if all works well, send a pull request upstream.

        It might make sense instead to have a personal branch from the dev branch for that purpose.

        Reading further in TFA, some silos don't have any sort of test framework. If you change 3 lines affecting what happens if you frotz the troll you must then compile the whole game and play it from start until you get to the troll on level 12 in order to test.

        It didn't directly

      • It's the programmer's job to write correct code. You're not supposed to submit untested code and wait for QA to send it back to you.

        Sure, though the "Testing changes here could mean progressing through several seasons of career mode in order to test out a change." from the summary sounds more like QA, of course that depends a lot on the specific change.

        That's how I've always worked, anyway. I say it takes half a day to change a line of code, including time to test it, commit it, update the bug report, etc.

        Seems about right. And given that changing a line of code takes half a day it's worth spending the time to make sure someone won't ne

    • You wouldn't normally make QA the gate keeper for a 3 line change. You put the change up for review and in parallel you'd run automated builds and some light-weight tests. (CI/CD) before integrating it. Later when you get closer to release, the software as a whole would go through a QA process. You might have code freeze where changes require a more formal process to introduce. And changes would generally be focusing on addressing bug reports from QA rather than new development.

      A 3 line bug fix at my compan

      • by skam240 ( 789197 )

        You wouldn't normally make QA the gate keeper for a 3 line change. You put the change up for review and in parallel you'd run automated builds and some light-weight tests. (CI/CD) before integrating it

        Sure but what the parent article is describing is well beyond what I would call "light-weight" testing and if it necessitates playing through in career a couple times as stated in the article then the game should be playable enough for a QA person.

        A good bit ago now I spent 3 years working QA for a major game publisher and the article's description of what was happening very much made it sound like they had programmers doing QA work to me.

    • by antdude ( 79039 )

      We're the QA team. :(

    • QA can be just as highly paid as devs, or more maybe depending on their seniority. But at every stage of development, from requirements to specs to design and all the way down to testing, the sooner you catch a bug the less it costs a company to fix it. So if a developer finds a bug before QA does, it's a big win. Developers should never throw something over the wall to testers to are the first team to touch it.

      Kind of annoys be by working code bases where this doesn't happen. Ie, ran across an issue la

    • by jeremyp ( 130771 )

      Absolutely. In my company, the programmers write the code and then they push it to the compilation team to compile. It used to be a bit time consuming until we wrote the automated script that creates a Jira ticket for each compilation error. Everybody's happy. Or at least I think they are: I haven't spoken to the programmers in a while... or even seen them about, come to think of it. Anyway, we know it's all working because we used to get thousands of tickets every day and it's now dropped to zero.

      Seriously

  • by loonycyborg ( 1262242 ) on Thursday December 16, 2021 @02:52PM (#62087597)
    Every little change in code can have various hard to predict side effects, in many cases leading to bugs. The hardest part about games is that it takes long time to test all relevant use cases. From this perspective whole day is pretty darn fast and most likely not enough!
    • It means that they have poorly defined interfaces between the sections of their code.

      • Not necessarily. Things can be more subtle, for example game world's feature started behaving in subtly different way with which AI can't cope yet.
      • by ravenshrike ( 808508 ) on Thursday December 16, 2021 @03:40PM (#62087911)

        In the example given they wanted to change the way the soccer teams iterated their performance over several seasons. Which means that you would have to run through those seasons to make sure it worked correctly. It's not a question of if it would compile or if their were glaring bugs. Now, you can argue that there should have been a separate dev mode which would automate the career mode inputs so as not to need input from the programmer, but even then to run that long of a sim it would still take a bit of time.

      • by tlhIngan ( 30335 )

        It means that they have poorly defined interfaces between the sections of their code.

        it's a videogame. Effectively they're one-off products that once released, short of a few patches, is never touched again. The code is written to be disposed of because it often is - they release FIFA 2022? Ok, start on FIFA 2023, and you likely will start with new tools, a newer engine, etc, so you discard all the previous code and start from scratch.

        Because of this game code is written more for "just make it work" than "m

    • Modern and well-designed code should not have this problem, at least to the same extent. But legacy code will, in spades. That is one reason why software architecture and design principles have evolved, to take advantage of painful lessons learned while trying to maintain, debug, and support legacy code.
      • Re: (Score:3, Insightful)

        by Anonymous Coward

        What crack are you smoking? If you're lucky, that ideal will hold up for v0.1. After that - all bets are off as modifications are needed.

        Also, what does "Modern" have to do with anything? I can write 'well-designed' FORTRAN, COBOL, PostScript, R, JavaScript, etc. 'Well-designed' is also very subjective. Was it designed to be fast? In many instances you're usually throwing away all the good design intentions to eek performance out of it. A nice well structured CASE - gone! - Put in a multi-level neste

    • Yea, 3 line change. changed "int" to "float" for three functions. That'd be .. fun. Good luck sorting that out in a day unless your 3 line change also included some beefier unit tests.

    • Every little change in code can have various hard to predict side effects

      Indeed. I'm reminded of a collision detection change on bees in Skyrim. Turning bees into a craft item which can be picked up had the unintended consequence of yeeting the cart into deep space during the intro scene. You know when an unstoppable force hits an immovable object and something has to give.

  • the only question is, How are they doing it so fast?

    a day? you haven't even written the story yet

  • News? (Score:5, Insightful)

    by Thelasko ( 1196535 ) on Thursday December 16, 2021 @03:00PM (#62087653) Journal
    Sounds like the author has never worked on a large project before. A small change in code can have huge consequences. That's why large companies have change prevention... I mean...excuse me... change control boards.

    However, this is also why startups have an advantage. Screw ups don't have near the consequences at a startup as at a large established company.
    • But 'they didn't get the memo!!' They're not adhering to the manifesto! Or else everything would be so easy and great!

      This actually might be the most bizarre and clueless 'story' I've ever seen on /.

      • This actually might be the most bizarre and clueless 'story' I've ever seen on /.

        Really? Since your UID is roughly what mine is, you've been registered here for a while. Perhaps your memory's recency effect half-life needs to be bumped up a bit.

    • Re:News? (Score:5, Insightful)

      by shadowwynd ( 6310460 ) on Thursday December 16, 2021 @03:40PM (#62087909)
      I freely admit to spending 36 hours (my personal worst) in tracking down a bug wherein everything compiled fine and would give bad data for *some* inputs. I have a degree in Computer Science, have been programming on small/medium projects for ~30 years, have used ~20+ languages at one point or another.

      It turns out to have been a single misplaced comma in a completely different section of code, out of thousands of lines of code. The butterfly effect is alive and well in programming. Three lines in a day can be generous.

      I am reminded of Gimli's quote from Lord of the Rings: "With cautious skill, tap by tap - a small chip of rock and no more, perhaps, in a whole anxious day - so we could work”
      • I've got similar stats for my career (30+ years, etc.), and I can recall taking several days to find one bug in particular - a multithread timing issue caused by the incorrect implementation of an atomic operation (something like i++). It turns out that you can't do an atomic fetch-and-increment by doing an atomic fetch followed by an atomic increment, there's this tiny little window in between when the lock is released that gets hit every few million times the operation is executed. Part of the process
      • by Calydor ( 739835 )

        Reminds me of a (possibly fictional) quote attributed to Homer when he wrote the Iliad:

        "Today was a good day. Today I wrote a full sentence."

  • by jellomizer ( 103300 ) on Thursday December 16, 2021 @03:00PM (#62087655)

    That article makes it seem like the author never work professionally doing any coding.
    I have a reputation as a fast to deliver coder, however I have taken a while day to change a line of code, because that one line of code, can drastically change the program and affect outcomes down the line.

    Changing code is a lot like those Science Fiction Time Travel stories, where someone just kills a butterfly in the past ends up destroying civilization in the updated present.

    Even the best documented code, you will need to understand what it is doing and why in a bigger picture before you fix something. Often you can fix it rather quickly because you know the scope of the function, but other times it could be a bigger scope, where that result of the function calls different functions to call.

    • by splutty ( 43475 )

      And don't even start on the huge amount of 'coders' that have zero mathematical background, so just write code they 'think' works instead of writing something that's actually mathematically efficient..

      (Sort algorithms come to mind. Although those have been hammered out pretty solidly nowadays you still see people implementing their own because they think it's better (spoiler: It's not), without having any clue about the actual mathematics behind it.)

      • Actually, this is one of my problems with the way interviews are done all over the industry. The only answer to, 'how do you efficiently implement a balancing binary tree," should be "I find a stable and reliable library that already does it, rather than wasting my time writing it from scratch'.

        Unless you're being hired specifically to create those libraries because you're working at Matlab or something, you should almost always be using built-in language or library functionality instead. Reinventing the wh

        • When I'm conducting the interview, I'm a big fan of candidates that give that answer. And then I make them implement one anyway.

          Because what I'm really trying to find out is if they can write anything that makes sense, and try to get a glimpse into their problem solving. And asking something like "balance a tree" or "sort an array" is much faster than explaining a real problem.

          Also, for any young'ins reading this: Talk about what you're doing and why during this kind of thing. Yeah, sorting an array is s

        • If I asked that question it is to ensure you have an understanding of how it works, though I would give you partial credit for that answer too. Many things are best answered with "I would use a standard library", especially in the security space.
      • (Sort algorithms come to mind. Although those have been hammered out pretty solidly nowadays you still see people implementing their own because they think it's better (spoiler: It's not), without having any clue about the actual mathematics behind it.)

        One place you see this is with slightly disguised sorting operations... things that the programmer does not think of as sorts but is. The canonical example of this I have seen even experienced programmers implement (often due to code evolution) is a selection sort. They have a list and scan it to find something. Then they scan it again to find the next thing. Then they scan it again...

        The initial implementation only scanned the list once for one item, and so was O(N), not too bad (though O(1) is available).

      • And don't even start on the huge amount of 'coders' that have zero mathematical background, so just write code they 'think' works instead of writing something that's actually mathematically efficient..

        (Sort algorithms come to mind. Although those have been hammered out pretty solidly nowadays you still see people implementing their own because they think it's better (spoiler: It's not), without having any clue about the actual mathematics behind it.)

        It depends a lot on the project but in my experience efficient code doesn't come from a background in math, it comes from a background in algorithms. Big O notation [wikipedia.org] is generally all the math you need, and then it's largely just understanding what the code is doing.

        But for sure, clever code is slow code more often than not. Leveraging a library that people have been optimizing for years is usually the way to go.

      • > Sort algorithms come to mind. Although those have been hammered out pretty solidly nowadays you still see people implementing their own

        Like the time when the junior programmer in our team implemented a bubble-sort over a linked list. Hello, O(n^3) complexity.

    • Yeah, this is largely a, "Where in the product are the lines in question?" Some code lines won't have as huge an impact as others.

      Or: not all code changes are equal.
    • by Somervillain ( 4719341 ) on Thursday December 16, 2021 @04:02PM (#62088039)

      That article makes it seem like the author never work professionally doing any coding. I have a reputation as a fast to deliver coder, however I have taken a while day to change a line of code, because that one line of code, can drastically change the program and affect outcomes down the line.

      Changing code is a lot like those Science Fiction Time Travel stories, where someone just kills a butterfly in the past ends up destroying civilization in the updated present.

      Even the best documented code, you will need to understand what it is doing and why in a bigger picture before you fix something. Often you can fix it rather quickly because you know the scope of the function, but other times it could be a bigger scope, where that result of the function calls different functions to call.

      Couldn't agree more. I think one thing to add is that once you have users and a product makes money, the most trivial of changes becomes expensive in terms of complexity and person hours.

      For my personal dicking around project? ...sure, I can write code as fast as I can type and upload to an AWS instance. However, I don't make money off it, so it doesn't matter. Once you make money, things like legacy support and backwards compatibility are huge.

      Here's a classic example. I worked at a place where the product had a codename and a month before launching, they settled on the final market name. We found on reference to the code name in the on hover help text. A new employee checked out the latest version of the code, made the trivial text change and broke a major form. Even though it was just 1 word in a display, the entire page broke because he checked out the latest version...and it had a bunch of new code in it. Every code review showed a trivial 1 word change. The change was live for 10 minutes. We got a ton of calls from angry customers for the downtime.

      For my current job, I've done simple 1 line changes and it's literally taken months to hit customer servers.

      We have billions of dollars on the line and there are a lot of precautions.

      While the process I follow is not without opportunities for improvement, you can never get a 3 line change out 1 day when money is on the line. It has to be audited for security violations. It has to be reviewed for correctness. Regression tests need to be performed to ensure there are no downstream impacts. It takes nearly a day for a machine to run those regression tests. Even when we have mission-critical emergencies, a 5 minute fix takes hours to propagate to all our servers across all zones and be verified.

      The author definitely has never had experience working for a profitable company.

  • At Nintendo... (Score:4, Insightful)

    by doug141 ( 863552 ) on Thursday December 16, 2021 @03:01PM (#62087667)

    One of their cartridge games for the N64 (no online bug updates) was being finalized (crunch time), and the special ending for collecting all stars (or whatever) didn't pop. The lead programmer made a change, went to sleep while the playtester started a marathon game on the new code for all the stars. 14 hours later, the bonus ending still didn't pop. The lead programmer says, "Oops," makes another change and says "try that." The playtester has to do it all over.

    • by Calydor ( 739835 )

      Seems odd if game developers don't have special versions with editable save games so you can make a quick test to see if something works, then a full run on a 'real' version to see if it works there as well.

  • A change kicking off a whole day of continuous integration before it can merge is not surprising, though it can be frustrating and maybe relatively rare. In this case it may be more manual but the principle applies, agile doesn't mean 'merge the code fast, no matter what'. If your process is that once you've made your change you can't work on other changes while the code is being tested, well then you have a problem of some sort.

    Unit testing can *help* and failing fast on unit tests can help iterate to a

  • Misleading (Score:5, Insightful)

    by Phydeaux314 ( 866996 ) on Thursday December 16, 2021 @03:06PM (#62087703)

    This is not "a day to fight through bureaucracy to change three lines of code." This is "a day to change three lines, and properly evaluate the consequences of that change," which for something as core to their gameplay loop as the competition management, isn't really that surprising.

  • While originally intended as a process for manglement to get extra work out of coders for free, Agile quickly turned into a way for programmers to avoid doing any work, sprint after sprint.

    After sprint.

    • While originally intended as a process for manglement to get extra work out of coders for free, Agile quickly turned into a way for programmers to avoid doing any work, sprint after sprint.

      After sprint.

      Sprint doesn't exists anymore. You mean, ... T-Mobile after T-Mobile. After T-Mobile. :-)

    • Re:Agile? (Score:5, Insightful)

      by sjames ( 1099 ) on Thursday December 16, 2021 @04:12PM (#62088091) Homepage Journal

      That's the thing. Agile (as opposed to agile) is yet another attempt to observe a highly skilled and productive group of programmers, formalize what they do and try to get a pack of chimps to become highly productive coding by numbers. Sadly though, they miss so many corner cases and how to determine when those are present, that even the original team becomes a pack of chimps if they are forced to adhere to the Agile way.

    • How so?

      If programmers would not work, the project would never finish, or never had "sprint results" in production.

  • This is actually good software discipline. Agile was designed for things that are easy to deploy (ie: web stuff), so the cost of fixing something is low. When the fix cost is high, testing is important.

  • by Targon ( 17348 ) on Thursday December 16, 2021 @03:17PM (#62087773)
    I remember a long long time ago(almost 30 years at this point), I encountered something interesting in a program I was assigned to work on. There was one routine that was actually sending a negative value which SHOULD have been a positive value. Now, throughout the rest of the program, everything that made use of that routine was flipped to deal with the source of the problem giving incorrect values in the first place. So, go back through the entire program, find all cases where that routine was being called, and update them to work properly. That is what happens at times, a bug is introduced, but rather than people going back to the source and have THAT get fixed, they just work around it. The problem is that going forward, it causes a cascading problem where everything else needs to be done "wrong" to work around a small but annoying bit of stupidity deeper in the program. If people aren't brave enough to get things fixed properly, debugging can become NASTY. How many cases of negatives being flipped to positives that then need to be flipped back to negatives due to one simple bug will there be? What if someone goes to debug the program later, looks at code, sees the thing being done, "wrong", and then corrects it without it being addressed in the rest of the program? Suddenly, it's just ONE section that works properly, but then everything else isn't giving proper results. So, do it right the first time, but don't be afraid to get to the source of the problem and get it fixed THERE, before debugging turns into a nightmare. I am just happy I don't deal with code at this point, because the days where doing things the right way have been over for decades at this point.
  • three lines (Score:5, Insightful)

    by volkerdi ( 9854 ) on Thursday December 16, 2021 @03:18PM (#62087781)

    Thus spake the master programmer:
                    "Though a program be but three lines long, someday it will have to
                    be maintained."
                                    -- Geoffrey James, "The Tao of Programming"

  • Not all Agile Development shops have the same degree of agility in the deployment. It's actually pretty common not to have CD, even when running scrums, for example. The degree to which you can use CD depends on the receptiveness of your customers to receiving new features continuously and piecemeal, among a million other variables. CD is great when you can do it, but if you can't it doesn't mean you suck.
  • Way back in 1998, I worked somewhere that (initially) outsourced its HP sysadmin to another company (whose initials come before HAL). It took 2 weeks to get them to add an entry to the /etc/hosts file (seriously, literally) as all changes had to go through their "review board". After they accidentally deleted the production database -- twice -- (so much for the review board) our company cancelled the contract and brought the systems in-house for me and another person to manage. It helped that our manage

  • I'm guessing the author hasn't done a lot of coding for pay.

    There are places Agile makes sense, but it's not everywhere - and shouldn't be. But the term does seem to mainly float around in the manager-sphere.

    • But the term does seem to mainly float around in the manager-sphere.

      And often when it floats around there, it has no meaning.

  • Who worked for AT&T back in the 80s. They spent 6 months testing a single line of code and when inserted, it killed service in three states. His quote on the matter was "Anytime you pick up the phone and get a dial tone, you should fall to your knees and thank the Lord - because the Phone Company has very little to do with it."
    • by PPH ( 736903 )

      They spent 6 months testing a single line of code and when inserted, it killed service in three stateThey spent 6 months testing a single line of code and when inserted, it killed service in three states.

      That's just a sign that AT&Ts software QA process is broken. A bunch of people who write and rubber stamp piles of documents without reading or understanding the actual contents. They are just going through the motions. But it sure does keep a lot of people employed.

      Cargo cult QA.

  • ... 3 lines of code. This is a change. It might have been an entire page of code. And it could take a day to do proper requirements development and code reviews in either case. This is just a sign that EA has rejected the "move fast and break things" software lifecycle.

  • I'm not a developer, so take my comments as you will. But with a long career in I.T. plus making it one of my primary hobby interests for decades, I've definitely noticed a trend towards buggier, less reliable code, since the concepts caught on for things like "Agile programming".

    Seems to me, it's all about putting a priority on getting new code out the door rapidly, instead of ensuring things are done properly first. "Let the millions of users find the bugs for us when they use it!" is the new mantra fro

  • We're working "agile" as well...

    We are a cloud provider though. Never in my life have I been so inefficient and unmotivated at work.

  • Anyplace with actual quality gates, things take time. I can make a 1 character change, I still need to have that change code reviewed, pass autoamted tests, and then hand it off to QA. The first part of that could take a day to get someone's time if the team is busy. Processes just take time, and the size of the change is not always the determining factor in how long it takes- in fact the smaller it is the more likely something else is to be the bottleneck.

  • A whole lot of orgs are very slow to make changes. One day to make a change isn't strange at all.

    Agile is a generic bunch of idealistic phrases by a dozen dudes at a whiteboard. Agile does not provide any practical solutions to common problems. It's just bullshit that people throw around to justify not using rigor or due diligence, or to avoid writing documentation, or having a change control process.

  • and none of those words are in English and none of them have shit to do with anything either.
  • So NO it didn't take a whole day to change 3 lines of code, it took a whole day to test 3 lines of code that had a LOT of prerequisite conditions. That isn't necessarily bad or slow and this has nothing to do with how EA works, sounds like someone that doesn't understand how code development happens, most of the time is generally spent on testing not coding.
  • sports title right? So, my guess is those 3 lines of code are to change the date to the current year and pull a roster of new player names so they sell the same garbage for $80+ again.

  • by ocean_soul ( 1019086 ) <tobias.verhulstNO@SPAMgmx.com> on Thursday December 16, 2021 @05:10PM (#62088327)

    Did anyone actually read the original article? Not the linked neowin post, but the devtails one neowin links to? It's a post explaining how EA managed to get rid of extremely long iteration times. I don't have much love to spare for EA, but this post is just ridiculous.

  • As other posters have pointed out: If those are critical lines of code, where a change requires a lot of testing, then a day is fine.

    I want to make an additional point: This has nothing at all to do with whether the team is "agile" or not. Agile means working iteratively, in short cycles. Changing those three lines of code in one day could well be part of an agile cycle.

    If the guy is actually an experiences developer, then he is clearly used to working on small or new projects. Maintenance on big, estab

  • In an game changing an percentage can take an lot of play to see if it works / if the game play is good with that change.
    And in an sports game that may be you need to play an full season to test it

  • In the 1970s, there was a book called "Why Nothing Works". Their poster child was Xerox, which, at one point, needed the sign off of something like 50 managers to make a small change to a copier machine.

    This was a vastly different company from the one that took the stock market by storm a few decades earlier.

    • Thus spake the Master Programmer:

      "Let the programmers be many and the managers few -- then all will be productive."

  • In the late 80s. I interviewed at at place that was about to upgrade to the next version of VAX/VMS. Based on their description of the requirements for preparation, the paperwork produced would have outweighed the system by a factor of 3.

Experience varies directly with equipment ruined.

Working...