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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
Extensive and rather interesting discussion on variations of the theme "No plan survives contact with the enemy" can be found in military writings going back centuries. An overview is linked below.
The key it seems, is the team agreeing there's going to be a punch in the mouth, accept that, stick together (i.e., don't panic), find a solution and continue (til the next painful punch). The plan can change, the process for considering change should not.
The arc of my point is that the methodology matters (kinda), but more importantly it's that everyone agrees to what the process is and sticks to it. Without such dedication and consistency the methodology doesn't matter, you're gonna come up short.
AFAIK, when they were all made to compete against each other in MMA it quickly became obvious that Brazilian jiu-jitsu was top dog. Although modern MMA definitely takes in the best techniques from each martial arts style.
Is agile the Brazilian jiu-jitsu of software development?
The best techniques for MMA, it's still a sport; more realistic than traditional boxing, but then that's a pretty low bar. I've been training martial arts for 25 years and I wouldn't put myself in there for all the money in the world. It's brutally violent, and the most successful fighters are very well trained and don't seem to give a shit about messing their opponents up for life; but it still has nothing to do with martial arts.
Wrapping your legs around your opponent's waist and rolling around on the ground for minutes ceases to be a good idea the second you leave the ring. While breaking fingers, ribs, poking eyes, punching throats and kicking knees and groins suddenly become viable options. In most cases; the sooner you can get the hell out of there the better, because the risk of getting into trouble increases fast in a street fight.
BJJ isn't defined by rolling around on the ground for minutes, it's defined by the importance of training against resisting opponents safely, which most traditional martial arts cannot or are not willing to do.
I am sorry but this eye poke, throat punch nonsense has been debunked over and over again: a) those things are not nearly as devastating as they sound and b) in a fight both people can do it, more so the person who has positional control. Browsing youtube searching for street fights where BJJ is used is pretty illuminating as to exactly how effective it is. Short of MMA there isn't anything else quite as useful, though you are right that getting the hell out is the best option if possible.
No it hasn't, because it works. Otherwise they wouldn't be forbidden in the ring, would they?
There's plenty of Bullshit Do out there, no doubt. But there is also plenty of useful knowledge and experienced teachers that you miss if you assume that everyone who came before you was a complete idiot.
Many martial arts were honed into more or less perfection over hundreds of years by people just as intelligent as you and me, but with generations of experience from actual mortal combat. Living another day is a pretty good motivation for training and evolving.
Much of that is still around, but it's not being marketed. Because it's not what most people are looking for, it's too real and ego-killing. Because it's barely allowed; you can't spar out in the open with real knives or swords for example, you'll end up in a cell before you know what happened. And because it's been Disneyfied, by people like Jack Mace and Master Wong.
Once you've spent tens of years really training martial arts, as opposed to sports or pretending in silly uniforms; there's not going to be much to prove any more. If there is, you're doing it wrong. I prefer not fighting, people get hurt best case. So I can't really show you anything that looks like MMA, because that's just not how we train. And we don't do competitions; because there are no winners; just two banged up idiots, one happy and one sad. But for whatever it's worth this is me with a private student 3 years ago:
Your point that martial arts originally came from real, life and death experience is well taken. But wouldn't you agree that when that component is taken out, without the hard sparing needed to keep things honest, any art will tend to degenerate and fall prey to hucksters? See TKD in America for example.
I don't buy the idea that we have to pound the crap out of each other in a ring to prove that everyone is honest about their skills.
If you want to learn anything, you definitely need to spar; but sparring is not a competition, no one is actually trying to hurt anyone. The more experienced your partner is, the harder you can go without risking injury.
TKD suffers from the same sports virus as MMA if you ask me; just a different, less violent and more exotic flavor.
AFAIK, when they were all made to compete against each other in MMA it quickly became obvious that Brazilian jiu-jitsu was top dog.
Not really. BJJ was very successful in the early days of what we now call MMA because everyone was playing a new sport with new rules and those rules allowed new tactics that were unfamiliar. BJJ's style of ground fighting was alien to practitioners of many other styles and they hadn't trained to defend against it, but also crucially, within the rules of MMA taking your opponent to the ground is something you can often achieve and with relative safety, so BJJers initially enjoyed a big natural advantage by being able to move the fight to their territory. Fighters from other styles quickly learned to sprawl, posture up on the ground, and so on, after which BJJ still offered effective techniques but wasn't nearly as dominant as it had been in the early days.
The analogy is quite flawed anyway, though. MMA is a great sport for those who enjoy it, but it's still a sport and still has its own rules. What works in the octagon, with a fence around the outside and a clean, flat floor, between exactly two fighters wearing fight-friendly clothing, when both are unarmed and neither is allowed to employ "dirty fighting" techniques is... well, not necessarily what would work without those rules, whether in a different sport or in any sort of real life altercation.
BJJ was the top dog twenty years ago, when half of the fighters had no grappling skills. Now that basic grappling skills are standard, BJJ-focused fighters aren't winning very much. It wasn't actually objectively best, it was just the least-bad in an undeveloped field.
Not really least-bad, probably just most unique. Almost every other style stops and resets after someone hits the ground, so BJJ went where the others didn't.
It was the same as Ronda Rousey dominating women's matches when that section of the UFC started up. It doesn't mean that Judo is "better" than the other styles, the other competitors simply didn't know what to do with it, and now they do.
It certainly has parallels to trendy new software engineering styles "dominating" the field, though I'm not sure they lead to any more real "victories" compared to actual combat. Just because the time runs out on a software project doesn't mean that anybody actually won.
I don't particularly agree that BJJ is the top dog solo sport. In the early days of MMA, it certainly outcompeted fighters who were boxers, kickboxers, karate experts, etc, but there was a notable absence of certain sports, such as combat sambo, until recently. Khabib has shown how effective it can be against high-level BJJ practitioners.
> Although modern MMA definitely takes in the best techniques from each martial arts style.
No, it doesn't.
Virtually all historical martial arts styles not compromising effectiveness to adapt to some social constraint focus heavily on weapons. (Heck, even most of those compromising effectiveness to adapt to a social constraint do, unless the specific social constraint is the needs of a group completely barred by law or convention from arms.)
The “martial” in “martial arts” means “pertaining to war”—when was the last war you’ve heard about fought in exclusively one-on-one hand-to-hand combat without weapons?
> Is agile the Brazilian jiu-jitsu of software development?
I would say the various concrete methodologies marketed as “Agile” have approximately the same relationship to software development as BJJ has to warfare, sure.
:-) Good one. Your analogy applies to all sport. It's all very well having set plays but executing them during a match is another story. Most fans have unrealistic expectations of their sports teams. Most clients have unrealistic expectations of the software development process.
Regardless of intent or documentation, I’ve never come across a methodology that didn’t devolve into the same practice as every other methodology. The root problem is that the people who are looking for a methodology/silver bullet are convinced — and no amount of reality will ever convince them otherwise — that software development can be done with 100% predictability, just like, say, adding a garage to a house. So even XP, that explicitly states up front that this is not possible in software, gets morphed into “agile” which is actually a great way to manage predictable development tasks, but a horrible way to manage software.
Adding a garage isn't predictable either. You think you have good as-built drawings, then it turns out your house has creative electrical wiring that you have to deal with first, or your shingles don't show up on schedule, etc.
Any non-trivial project with external dependencies is going to have to be able to adjust when things don't go as planned.
Software development might be worse and it's worth trying to improve, but it's far from unique.
Here's an example of that: when I built a house, we had the following characteristics:
1 A geotechnical exclusion zone at the front of the house whose exact location was unknown.
2 Three strange angles (one for solar access, two marking out the block size) making measurement tricky thus tricky locating the exclusion zone.
3 A brick house base and a steel frame to go on top. There was 5 centimetre tolerance for the location of the steel beams.
Get #1 wrong, and start building all over again.
Get #3 wrong, and it's time to re-fabricate the frame.
Could have been costly. Went well but took a lot of care, attention and coordinating across 5 groups of contractors.
As a side note, one of my occasional hobbies is performing super-sketchy surveying methodology. It turned out that my extermely non professional, totally un-certifiable methodology was within 10cm of the actual exclusion zone (whose length is around 10 metres from the front of the block of land).
I feel you have just described the role of management in software development. Management has to compile weekly/monthly progress reports and give estimates of when development will be complete. Then the testers can start doing their thing before the rollout teams start training end users. In big corporate companies, there are many people downstream from the developer who needs to be kept informed of development progress. Management needs a methodology to follow and include in their slides. Something that sounds official and has been proven somewhere else.
Well, you just described waterfall. And the track record of trying to compile accurate progress reports, only starting testing after development is ”completed”, and only involving actual users in a one-way communication... is not exactly great.
No, I have not described the waterfall method. I have listed the role players and processes associated with software development in a big organisation. Perhaps I wasn't clear on what I meant by testing which is a broad term which includes piloting software. Testing in a POS environment involves piloting out the POS software to a limited number of stores and letting it process actual transactions for a period of time. The perennial question which no one has been able to answer definitively is how do you align everyone with the software development process. You cannot roll out software without testing it and writing out a manual whether you use waterfall method or Agile.
There is a move away from the capital 'A'gile processes in use with agile as an adjective to describe how you approach problems and the development process itself should be fluid.
So the answer seems to be use agile to find a fit, or if that doesn't fit other organizational requirements/abilities, then choose the least poorly fitting process.
Software engineering can be much more predictable than it is. It isn't in practice for primarily two reasons: most software projects simply don't need the rigor, and the fraction of developers who think their ability to write a working program makes them smarter than everyone else to the rest of us is quite high.
As someone who is renovating their house: home improvements are not 100% predictable. Although I admit they are easier to predict than software, and easier to explain in layman's terms why something went over the expected time or price.
The big difference is building work can be repeatable, the people that built the garages on the housing development behind me did the same job for each of the 39 houses.
Development is never really like that, why would you write another JSON parser if you already did it yesterday.
To be fair to those who add Garage's to houses, you can't do that with 100% predictability either. Nothing slows down an addition like digging the foundation and hitting a unknown oil tank.
This reads largely like a recapitulation of Boehm's 2003 book "Balance Agility and Discipline" [1]. Have you read this and did this provide any inspiration for the article?
I totally agree with the 'Risk-first' approach. This idea fits in very nicely with risk driven technical assurance, where the goal of project reviews (even including those covering pre-project activities such as bidding) is to quantify and mitigate the risk to the business. Such assurance provides an outer shell for engineering activities such as software development.
Much needed effort, thanks. How do you see the ongoing relationship between the book and multi-contributor website? How did that influence the selection of an Apache 2 (intended for code) vs CC-BY (intended for content) license?
That's an excellent question, and one I'm currently struggling with.
On the one hand, I would like to grow Risk-First as a community, and get other people authoring articles. With this in mind, I am trying to automate the process by which collaborators are added to the github organisation... it's manual at the moment which is already painful.
On the other hand, I wanted to publish this work in order that it could be read off-line (in print form, should be ready end of Feb) or on a kindle (which is currently pre-order). This _probably_ won't generate much income as it essentially is content that is already for free on the website.
Probably, the license is sufficiently permissive that other people could also publish the work as a book for their own means, so long as they retained attribution or copyright notices. I guess this is the usual quandary on making anything open-source.
I expect you're right that the license _should be_ CC-BY. I need to investigate further on this. Do you have any further thoughts on this?
CC licenses have been vetted by content publishing lawyers in many countries. CC-BY 4.0 enables commercial re-use.
The Apache license was designed to manage software specific risks.
For the book, you can have a few chapters which are proprietary, clearly marked as such in the book, with the CC chapters explicitly identified. That allows anyone to republish/derive the CC chapters, but not the proprietary chapters. There might be a natural separation between community-authored content and your analysis/perspective chapters.
CC-BY 4.0 also allows derivatives of the community content to be proprietary, so the entire book can remain commercial. There are other CC licenses (share-alike) which have GPL-like qualities. It depends on which outcomes you want to incentivize, and how much effort you want to put into management of content origin, derivatives and/or issuing DMCA takedown notices to Amazon.
For revenue models, look at softcover.io, which provides free-to-read content with upsells to paid ebook and video. It has generated several hundred $K for the Ruby on Rails tutorial. The author has previously posted about this on HN.
IMO the problem with software methodologies is leaky abstraction.
There just isn't a general framework that tells you how to categorize and deal with every issue that you come up with.
The main thing I get from the various methodologies is general philosophies. Things like "try to get feedback incorporated quickly". Or "Identify in advance the things that are expensive to change".
I kind of wish we applied "micro-methodologies" rather than methodologies. I think we should be doing "import retrospectives" rather than "import scrum" and sharing and experimenting with a diversity of approaches (e.g. various different ways to do retros).
We're essentially treating "methodologies" as software that runs teams. Furthermore, if we are doing software we should follow the UNIX philosophy and the bazaar rather than the cathedral.
Software in the abstract problem solving against varying constraints. It stands to reason there would not be a single method that capture the best means of doing so.
XP wasn't a set of practices, or methodology, it was a set of principles. "Value working software" etc. The "methodology" flows from there: only do the things that help support the principles, get rid of everything else you can (up to and including many of the scrum rituals/meetings).
This whole risk-world-view thing is depressing. Yes, technically the entirety of life on this planet is managing risk. I eat food and breathe air to manage the risk of dying from not doing so. The quality and amount of the food and the air determine the risk factor. Am I really going to choose the food I eat and the air I breathe based solely on risk? Or maybe, I dunno, eat the food that tastes good and breathe air that smells clean?
Really, all of this is bullshit, because the reason we sometimes fail to deliver software projects is humans really suck ass at dealing with complexity. We can deal with one complex thing at a time, but once multiples of them are all being considered at once, we just screw up constantly.
I think the way to pick any methodology is really deceptively simple: 1) look around and see if most of you are experienced at a given methodology, and then 2) use it.
I think it's that second part that people screw up on.
I agree, maybe it does _sound_ depressing. But the food you eat and air you breathe _are_ based on risk! Our bodies try to warn us about the bad air and food by making it smell/taste bad. You can go ahead and eat it if you want!
I agree with you that it's nice that our bodies make things _nice_ to eat as well as recognising nasty stuff. I wonder if there is an evolutionary reason for that too...
Sadly, there are still some things that _don't_ taste bad but will kill you... hidden risks of eating I guess.
> Following a software methodology is therefore an act of trust
That's the key point from my reading. After working with the same people on multiple products at a startup, I came to trust the product research and design steps preceding development and the marketing and customer success. Even if not wholly believing, I at least came to the conclusion that it was closer to an efficient process than I could come up with.
It can take the form of useless meetings. ex: Oh, stand up meetings sound good, but what are we going to talk about?
Only keeping the cheap aspects. Ex: not doing formal test campaigns based on previously defined requirements but forgetting about things like pair programming in XP, up to date automated unit tests, etc...
I don't see how that follows neccessary - the majority of people aren't able to perform calculus but that doesn't mean there is something wrong with it.
Granted it is a matter of where it is expected to be applied and by who. Expecting an artillery gunner to do advanced math calculations from the back lines is fine if not ideal compared to computerization. Expecting a grunt under fire to do so to use his rifle is not no mattet how accurate it would wind up.
Of course part of knowing the rules is when not to follow them ironically. You don't use rior shield walls against cannon or machinegun fire or try to take cover against angry mobs.
It is a principle of art as well at very least of when to break the rules - it should be done for a reason and awareness of how it may backfire instead of "just because".
"Software methodologies are all about handling risk." Not even close. Methodologies should about creating working software with a short feedback loop between customer and engineer. That old blue cool-aid about risk doesn't fly anymore.
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.