I strongly suspect he's comparing them to smaller startups, which can pivot incredibly quickly. Once you've got your software being used by millions of people, on thousands of machines, you do have to slow down somewhat, to make sure it's maintainable and doesn't break easily. But they're almost certainly still more agile than MS.
They DO sound slow to me. My max team has only ever been 20 - userbase, dunno, some has been quite a lot, the Jessops/Tesco/etc photo processing terminals were probably the most, but I was mainly working on the "next version" and not bugfxing/upgrades on the installed version. The guys who did that seemed to turn it round fairly swiftly - Tesco *demand* that!
Depends on what you mean by "team", my current team is only about 8, but my previous team was about 70 people, arranged in 5 subteams.
You cannot iterate quickly when your infrastructure is used in so many places, unless you do hideous amounts of automated testing - and even then that's going to throw up things that stop working from the most innocuous of changes.
Edit: That included analysts, coders, testers, one solutions architect, and five managers. It wasn't 70 devs.
ah, but that amount of code didn't spring, fully-formed into being an instant - y'know. It was written bits at a time. As should its accompanying test code be/have been.
Of course none of us is perfect at this, certainly not me - and I learned that writing the tests as you write the code is a stonkingly good idea that saves you HEAPS of time in the end back in 1988 on my *SECOND* programming project at Uni (guess how the first one went?)
I have had to dig out multiple research/expect references to back up my estimates to management (in teh past) purely cos even other developers fidn it hard to believe that test code takes AT LEAST as much time to write as the 'actual' code - and moreover that that total time is less than what it will *actually* take you to get a solid, reliable product if you don't take that time to write and run those tests.
And I STILL haven't quite pushed that far enough at the current job - but I will do on Friday now I have actual dev figures out of JIRA's work logs >:-)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
no subject
no subject
You cannot iterate quickly when your infrastructure is used in so many places, unless you do hideous amounts of automated testing - and even then that's going to throw up things that stop working from the most innocuous of changes.
Edit: That included analysts, coders, testers, one solutions architect, and five managers. It wasn't 70 devs.
no subject
Got it in one, though I wouldn't call it 'hideous' :-) Extensive, maybe.
no subject
no subject
Of course none of us is perfect at this, certainly not me - and I learned that writing the tests as you write the code is a stonkingly good idea that saves you HEAPS of time in the end back in 1988 on my *SECOND* programming project at Uni (guess how the first one went?)
I have had to dig out multiple research/expect references to back up my estimates to management (in teh past) purely cos even other developers fidn it hard to believe that test code takes AT LEAST as much time to write as the 'actual' code - and moreover that that total time is less than what it will *actually* take you to get a solid, reliable product if you don't take that time to write and run those tests.
And I STILL haven't quite pushed that far enough at the current job - but I will do on Friday now I have actual dev figures out of JIRA's work logs >:-)