Date: 2012-08-28 12:46 am (UTC)From: [personal profile] anathomical
First of all, I realized after I posted my comment that it might sound like I was dismissing your points about organization, which was not my intention, but then I figured I'd let you respond before tossing in more thoughts! So, sorry if that's how it seemed.

Because you are clearly talking about more than directive authority. BUT I think that structure imposed from outside makes it harder to hold onto directive authority, so I do think that part of how this whole thing is presented is worth being careful with. Especially since ADT has been discussing some of these problems internally. Not that we don't need outside input!

Also, I do want to clarify. My point isn't that coders work on what they like, it's that they work on what they are motivated to do. In fact, most of the bugs I end up fixing aren't ones I run into, but are ones that people I know run into. I fix things for my friends. I might also fix things for recognition, either external or internal to the committee. I don't fix things just because someone tells me to (though I might fix something that someone tells me to if I think it will result in recognition, etc.). To use my by-now stretched fic metaphor: I might write a fic that I wouldn't otherwise because I signed up for an exchange, and that's part of the responsibility. But if I don't have fun, I probably won't sign up for the next one. Anyway, while this is all worth discussing, and really has to be dealt with for any sort of organizational changes, let's dig into the actual things you want to do a bit.

Now I kind of regret cutting my discussion of Agile processes because it sounds like you've either had bad experiences with them or just not been around them much, but they're generally considered: (a) much better at rapid iteration, (b) much better for user-focus (a knock-on effect of rapid iteration), (c) harder to scale (in that middle-management of coder teams have to be coders, not project managers, for maximum efficiency). With the exception of that third point, which can be mitigated, agile development is significantly more in line with our goals, I think.

Furthermore, while Agile doesn't scale as cleanly, we are nowhere near the limits of that scaling. I work at a 2-million-ish-user startup at the moment, and not only do we use Agile, but I'm pretty sure that we could double the size of our tech team, maybe even triple it, before even beginning to run into organizational issues.

I suspect that it's worth diving into more detail on specifics, but deciding on Agile or Waterfall doesn't really address what I take to be some of your early concerns.

I will say that it's interesting that you seem to take almost the exact opposite approach as me to the problems I think you're focusing on. One of the issues we have (and I think ADT is aware of this) is that Coders are too dominant in decision-making and priority setting. Testing is especially pushed out of a lot of those conversations, and the results are unfortunate. Additionally, we're still not iterative enough, and our release cycles are far too long.

I read you as suggesting that the solution there is to draw clearer distinctions between various groups so that each sub-division of ADT ends up with its own strong voice in its own area, and then use a coordinating committee to increase and encourage cross-group communication. I tend to take the exact opposite approach. If a group within ADT has less influence/input than they should, the solution is integration rather than separation + more management.

I feel like my points are all over the map, not really managing to come out all that coherent. It's been one of those days.

I hope it makes some sense,
Identity URL: 
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


If you are unable to use this captcha for any reason, please contact us by email at

Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.


eylul: (Default)

October 2012

 12 3456
14 151617181920

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 23rd, 2017 01:37 pm
Powered by Dreamwidth Studios