7 ms·

Here is a (tongue-in-cheek) model I've developed. It's based on the observation that teams who were basically competent and had an overabundance of hard technic

Here is a (tongue-in-cheek) model I've developed. It's based on the observation that teams who were basically competent and had an overabundance of hard technical skills reliably delivered, while teams where hard skills were rather thin on the ground could not deliver. To avoid this degenerating into the tautology "only teams that can develop software can development software" let's develop the idea a little bit: Definition: A team member is "garage competent" if, when locked in a garage with a computer and an internet connection (but without help or advice from other team members,) he or she could deliver some working version of the product single handed, given sufficient time. The model's prediction is just this: if the number of garage competent team members is greater than the number of other team members, then the project will be delivered. Otherwise, the project will fail. (In this simple version of the model described above, simple majority serves as a proxy for control of the project. A more nuanced but harder to define model would define "control of a project" as a weighted sum over team members taking into account the leverage of different assigned role such as PM or architect.) I posit this is not just a highly predictive model, but in fact the causal mechanism project failure: Once people who are not "garage competent" are in control, they make reliably make decisions that will ultimately doom the project. Try it out yourself: think of a historical project where you know the outcomes and can estimate garage competence for each team member and see if it makes the correct prediction.

avip 8y ago
My methodology is something of a corollary: the secret of successfully delivering an (admittedly simple) sw product is to minimize the connectivity of the delivery network. The principle is simple: for small projects, the drag introduced by elements of broken communication outweighs the potential benefits of adding working nodes. So if we need to "build a web app", the ideal setup is to find someone who's an ok designer, ok coder, ok devops, and ok at asking customers what the hell they need the thing to do (PM?). If that fails, the next-ideal setup is 2 people working independently on aspects as far as possible from each other.
- peterwwillis 8y ago
  Your methodology is to either lean on rock stars or have people not work together?
- bobm_kite9 8y ago
  These risks get a lot of coverage in Risk-First: - https://github.com/risk-first/website/wiki/Communication-Risk https://github.com/risk-first/website/wiki/Communication-Ris... - https://github.com/risk-first/website/wiki/Complexity-Risk#connectivity https://github.com/risk-first/website/wiki/Complexity-Risk#c... - https://github.com/risk-first/website/wiki/Coordination-Risk https://github.com/risk-first/website/wiki/Coordination-Risk
pjc50 8y ago
Deliver what, though? If you provided each garage programmer with a full waterfall aerospace grade up front specification, you'd have a lot more success than if you just gave them some vague post it notes. It would also ensure they produced almost identical results. But the upfront spec is expensive, and in itself hard to produce - the premise of most methodologies is that iteration with real software and real customers is actually the most effective way of producing a viable spec. I don't think I've worked with more than one or two people who would fail to deliver with a clear spec.
- mLuby 8y ago
  You're getting at intuiting requirements, which I think of as a mid-level or senior dev skill. Super important for orgs without massive product/design resources, but it's different from this garage test. I can certainly believe a good number of programmers couldn't, for example, figure out how to build a database on their own, or a 3D game, work with cryptocurrencies, or reverse-engineer an API. There's a reason FizzBuzz is still a valuable gating test.
- gutnor 8y ago
  I guess "garage competence" is determined part of the environment. In an environment where getting proper spec is a challenge the competent developer needs advanced business knowledge too. Similarly, a very technically competent team would still doom the project by making the wrong business assumption in their decisions. I worked in several project where having built a 1:1 relationship with key people at the client location was essential to get anything done. i.e. Being known by the guys in the room was the difference between a release met with hostility (negative expectations) and one met with excitement (positive expectations). Garage Competence would have required those connections.
- olooney 8y ago
  I assume that the lone developer locked in the garage is still able to communicate as much as necessary with clients and stakeholders. The garage metaphor makes it sound like they're cut off the whole world, when what I intended was just to isolate them from the development team. Sorry about that; I could have been clearer. So, the developer in the garage would have to be able to interview stakeholders and capture requirements. They are welcome to write their own spec, or stories, or whatever artifacts they prefer, but shouldn't expect to be given a complete spec in most cases.
bobm_kite9 8y ago
Sounds necessary, but maybe not sufficient for project success. Problem is, the context of the project will often involve people of questionable competence...
dogline 8y ago
I like this, and something like this seems to be the step-zero of all of the rest of the methodologies. If you don't have enough people who generally know what they're doing, the project will fail, regardless of method.
lukasm 8y ago
> The model's prediction is just this: if the number of garage competent team members is greater than the number of other team members, then the project will be delivered. Otherwise, the project will fail. I have seen successful teams when only one person was very good at X and other learned it. And he was NOT in control and people in control weren't technical. If you have at least one component person on the project, time becomes the most important variable. > think of a historical project where you know the outcomes and can estimate garage competence for each team member and see if it makes the correct prediction. Sure. Bunch of competent people, but demotivated. Another case: Competent people, but not enough time.
- dtech 8y ago
  > Another case: Competent people, but not enough time. I would say that in this case the following condition for failure from the parent is true: > people who are not "garage competent" are in control
- tonyedgecombe 8y ago
  I have seen successful teams when only one person was very good at X and other learned it. One of the patterns I saw regularly when I was contracting is a team of ten developers would have one or two people doing almost all the work.
sonnyblarney 8y ago
Ha, I liked that. Your thesis is backed by some data from the COCOMO model of software estimation [1] The 'quality of the team' is generally the #1 cost driver of a project, according to some hard data. [1] https://en.wikipedia.org/wiki/COCOMO https://en.wikipedia.org/wiki/COCOMO
dragonwriter 8y ago
> Try it out yourself: think of a historical project where you know the outcomes and can estimate garage competence for each team member and see if it makes the correct prediction. Nope, it , IME, significantly underpredicts delivery. If you change your success metrics to something that takes into account the completeness, correctness, and/or operational success of what is delivered, I think the problem reverses to overpredicting success, and I think the source of that is that focussing on garage competence of team members ignores that coordinating work of a team effectively is its own critical skill, critical defects in which will cause otherwise competent teams to deliver garbage.

avip 8y ago

My methodology is something of a corollary: the secret of successfully delivering an (admittedly simple) sw product is to minimize the connectivity of the delivery network. The principle is simple: for small projects, the drag introduced by elements of broken communication outweighs the potential benefits of adding working nodes. So if we need to "build a web app", the ideal setup is to find someone who's an ok designer, ok coder, ok devops, and ok at asking customers what the hell they need the thing to do (PM?). If that fails, the next-ideal setup is 2 people working independently on aspects as far as possible from each other.

peterwwillis 8y ago
Your methodology is to either lean on rock stars or have people not work together?
bobm_kite9 8y ago
These risks get a lot of coverage in Risk-First: - https://github.com/risk-first/website/wiki/Communication-Risk https://github.com/risk-first/website/wiki/Communication-Ris... - https://github.com/risk-first/website/wiki/Complexity-Risk#connectivity https://github.com/risk-first/website/wiki/Complexity-Risk#c... - https://github.com/risk-first/website/wiki/Coordination-Risk https://github.com/risk-first/website/wiki/Coordination-Risk

pjc50 8y ago

Deliver what, though? If you provided each garage programmer with a full waterfall aerospace grade up front specification, you'd have a lot more success than if you just gave them some vague post it notes. It would also ensure they produced almost identical results. But the upfront spec is expensive, and in itself hard to produce - the premise of most methodologies is that iteration with real software and real customers is actually the most effective way of producing a viable spec. I don't think I've worked with more than one or two people who would fail to deliver with a clear spec.

mLuby 8y ago
You're getting at intuiting requirements, which I think of as a mid-level or senior dev skill. Super important for orgs without massive product/design resources, but it's different from this garage test. I can certainly believe a good number of programmers couldn't, for example, figure out how to build a database on their own, or a 3D game, work with cryptocurrencies, or reverse-engineer an API. There's a reason FizzBuzz is still a valuable gating test.
gutnor 8y ago
I guess "garage competence" is determined part of the environment. In an environment where getting proper spec is a challenge the competent developer needs advanced business knowledge too. Similarly, a very technically competent team would still doom the project by making the wrong business assumption in their decisions. I worked in several project where having built a 1:1 relationship with key people at the client location was essential to get anything done. i.e. Being known by the guys in the room was the difference between a release met with hostility (negative expectations) and one met with excitement (positive expectations). Garage Competence would have required those connections.
olooney 8y ago
I assume that the lone developer locked in the garage is still able to communicate as much as necessary with clients and stakeholders. The garage metaphor makes it sound like they're cut off the whole world, when what I intended was just to isolate them from the development team. Sorry about that; I could have been clearer. So, the developer in the garage would have to be able to interview stakeholders and capture requirements. They are welcome to write their own spec, or stories, or whatever artifacts they prefer, but shouldn't expect to be given a complete spec in most cases.

bobm_kite9 8y ago

Sounds necessary, but maybe not sufficient for project success. Problem is, the context of the project will often involve people of questionable competence...

dogline 8y ago

I like this, and something like this seems to be the step-zero of all of the rest of the methodologies. If you don't have enough people who generally know what they're doing, the project will fail, regardless of method.

lukasm 8y ago

> The model's prediction is just this: if the number of garage competent team members is greater than the number of other team members, then the project will be delivered. Otherwise, the project will fail. I have seen successful teams when only one person was very good at X and other learned it. And he was NOT in control and people in control weren't technical. If you have at least one component person on the project, time becomes the most important variable. > think of a historical project where you know the outcomes and can estimate garage competence for each team member and see if it makes the correct prediction. Sure. Bunch of competent people, but demotivated. Another case: Competent people, but not enough time.

dtech 8y ago
> Another case: Competent people, but not enough time. I would say that in this case the following condition for failure from the parent is true: > people who are not "garage competent" are in control
tonyedgecombe 8y ago
I have seen successful teams when only one person was very good at X and other learned it. One of the patterns I saw regularly when I was contracting is a team of ten developers would have one or two people doing almost all the work.

sonnyblarney 8y ago

Ha, I liked that. Your thesis is backed by some data from the COCOMO model of software estimation [1] The 'quality of the team' is generally the #1 cost driver of a project, according to some hard data. [1] https://en.wikipedia.org/wiki/COCOMO https://en.wikipedia.org/wiki/COCOMO

dragonwriter 8y ago

> Try it out yourself: think of a historical project where you know the outcomes and can estimate garage competence for each team member and see if it makes the correct prediction. Nope, it , IME, significantly underpredicts delivery. If you change your success metrics to something that takes into account the completeness, correctness, and/or operational success of what is delivered, I think the problem reverses to overpredicting success, and I think the source of that is that focussing on garage competence of team members ignores that coordinating work of a team effectively is its own critical skill, critical defects in which will cause otherwise competent teams to deliver garbage.