8 ms·

AgileFall does sound like an unholy mess, taking the worst aspects of both Agile and Waterfall! However, I still think waterfall is the only approach when tryi

AgileFall does sound like an unholy mess, taking the worst aspects of both Agile and Waterfall! However, I still think waterfall is the only approach when trying to design a hardware product. Electronics require pretty specific requirements up front before you design and order boards, obviously mechanical tooling can be even more expensive. But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept. Within each phase of the design more experiments can be done. But ultimately the project is probably more waterfall than agile!

supahfly_remix 7y ago
I've done both hardware and software projects. My hardware projects began with an analysis phase where feasibility studies were done to answer questions like, can we build it at the desired frequency with current technology? No actual work on the project would be done at this point, since it was at risk of being thrown away. Modern software projects seem to just start with people typing and little upfront documentation. A long time ago there was documentation (flow charts, Booch diagrams). Now whether these are useful seems debatable, but I do not see any upfront analysis done with software.
- mikekchar 7y ago
  With hardware you can check your designs against the laws of physics. With software there usually aren't any such laws. Being a guy who has actually written a 1300 page requirements document in my career as well as large books full of designs, my experience has been that the only thing you can test them against is code. Usually you are wrong :-). It's much better to start off with tiny pieces and make sure to write a lot of code along the way. Exactly how much upfront analysis you need before you start writing code is a judgement call, but I would say that it's almost always safer to err on the side of writing code too soon.
lmm 7y ago
Agile exists for the particular constraints of software development, where requirements are unknown, change is relatively cheap, and feedback loops are very tight. I wouldn't expect it to be appropriate to other domains.
- namdnay 7y ago
  I would go futher and say that Agile exists for the particular constraints of UI software development. User stories, Product Owners and Agility break down if you're building core infrastructure
  - vbtemp 7y ago
    Amen! When your product requires true engineering, agile just causes you to keep chasing your tail. Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor.
    - 0x445442 7y ago
      Agree with you and parent. "Agile", in it's current form, is managements holy grail pursuit of commoditizing software development. It's the latest management fad to circumvent the law of fast, good and cheap. Quality software is engineered and is expensive to develop.
    - InternetOfStuff 7y ago
      Speaking as an aeronautical engineer, I disagree. > Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor. Agile just means closing as many feedback feedback loops as you can as early as you can, and to preserve opportunities to course-correct for as long as you can. All this to keep the destructive effects of surprises (which are sure to catch you) as low as possible. This is good engineering practice, plain and simple.
  - pflenker 7y ago
    I have seen Agile working with pure core infrastructure teams. How does the UI (or lack thereof) change the applicability of agile?
perlgeek 7y ago
> However, I still think waterfall is the only approach when trying to design a hardware product. You can still use some agile ideas when working in electronics, thought it might look quite differently than in software. For example, if you are a startup and your plan is to create a super duper wireless speaker with bluetooth, wifi and AI, you could first build a wireless speaker with only bluetooth, and sell that. That way you build experience with producing speakers, sales channels, manufacturing, sourcing etc., and build a customer base. Then you could ask your customer base if they'd prefer wifi or AI in the next model, and iterate accordingly. This is not the same as doing one-week sprints in software, but it does iterate that you can start small, build and sell small, viable products, and work your way up to the intended product.
- crimsonalucard 7y ago
  This is different. Agile and waterfall seem to be defined over the lifetime of a product. Iterating the concept over several products while doing waterfall on each design sounds like a combination of waterfall and agile. I'll be clever and call this transmogrification "agilefall"
  - pipelineist 7y ago
    But that's the thing behind agile: you do nice, quick two-week (or however long your sprint is) waterfalls. These quick loops are really the only difference, and are precisely where the advantage lies. And having as short feedback loops as you can get away with has been sound engineering practice since before software was a thing.
    - crimsonalucard 7y ago
      Who says I can't have a 2 month sprint and gather feedback and do testing in those 2 months? Engineering has always done this and called it waterfall. The difference now is more bureaucracy under agile.
- crimsonalucard 7y ago
  This is also a good way to build airplanes and bridges.
Fr0styMatt88 7y ago
There's a talk well worth watching by Kevlin Henney called 'Old Is the New New' [1], where he points out that waterfall was initially conceived with design iteration in mind and yet that part was just essentially forgotten and replaced by something overly-simplified in common understanding. [1] https://www.youtube.com/watch?v=AbgsfeGvg3E https://www.youtube.com/watch?v=AbgsfeGvg3E
- aedron 7y ago
  The term "waterfall" is a straw man, software development methodologies have always required iterations. Just look at the Rational Unified Process (the industry standard before agile): https://en.wikipedia.org/wiki/Rational_Unified_Process#Four_project_life-cycle_phases https://en.wikipedia.org/wiki/Rational_Unified_Process#Four_... Every phase of the project has iterations, but iterations stress different things (requirements in the beginning, construction and handover in the latter phases).
  - Jtsummers 7y ago
    Tragicaly, it's not a strawman, it's an enshrined project management method the DoD created from a misunderstanding of Royce, which escaped into the wild. Now, most people who say they do Waterfall are quite mistaken. They don't, they do some sort of iterative method as you say. But they report as if they have distinct, linear phases with distinct linear steps, as if Waterfall were the reality and not an imagining. Which is itself problematic. This means that upper managemnet comes to believe that Waterfall works because they see it working, not realizing that the reports themselves are misleading. Everytime one of the project managers tells me they're doing Waterfall I press until they admit it's "Modified Waterfall", by which they mean the V-model or Spiral or other models with explicit feedback loops/mechanisms. And it frustrates me to no end that they keep using the wrong terms rather than the precise ones, because now upper management has begun enshrining Waterfall again after two decades of improvements. Now we have to fight the same battles, to impress upon them that iterative methods are what we actually do, and that a strict linear flow is impossible.
  - pflenker 7y ago
    Some anecdotal evidence that waterfall is not a straw man: at least 10 years ago, waterfall was taught as waterfall without iterations at some German universities. This was the starting point, and many derived models, like the V-Model, where also taught, but iterations we’re nowhere in sight.
crimsonalucard 7y ago
Its a proper way to design software as well. I get the purpose of agile but inevitably agile code has the tendency to become a giant mess.
- beat 7y ago
  "inevitably all code has the tendency to become a giant mess". There, fixed it for you.
  - crimsonalucard 7y ago
    You didn't fix anything. You mutilated/slaughtered the sentence. News for you: Not all software has the tendency to become a giant mess.
    - beat 7y ago
      #notallsoftware
- AnimalMuppet 7y ago
  "Inevitably" is a bit strong. I have seen it not become a giant mess. It took a team where almost all members had both talent and discipline, though. Without discipline, I'd agree with beat - any process will produce code that becomes a giant mess.
markrages 7y ago
Agile works OK for electronics. I have done it. With quick-turn fab houses, you can do two-week sprints in hardware. You can fix up the circuit with X-acto/bluewire changes, and roll the fixes into the next sprint. Or you can make individual subsystems per sprint. And with firmware, most software methodologies work with minor changes. Usually you can get something working in the first sprint, and iterate from there.
- roland35 7y ago
  Your absolutely right, and with a modular system design it can make it easier to plug in iterations of individual components. But at some point early in the design you need to lay out how the modules will work together, i.e. do we use CAN? 24V power or 48V? All that can be changed as well but at some point it gets complicated! For a simple project all of that can be managed iteratively.
  - InternetOfStuff 7y ago
    > All that can be changed as well but at some point it gets complicated! Not everything has to be changed, that's just a strawman. But not every detail has to be nailed down at the beginning either. The idea behind Agile is to reduce risk. If there is no risk of the bus system changing on you, there's no harm in fixing it right at the beginning. But if there is a chance it might, you'd do well to have systems in place which enable you to react to changes with a minimum (though non-zero, of course) amount of pain.
  - aidenn0 7y ago
    The same is true with software, unless you suggest that Agile will change the implementation language with every sprint...
  - organsnyder 7y ago
    All the more reason to use an agile approach! The only reason you would be making those major changes is in the face of new information: a change in requirements, an unforeseen challenge, etc. It's impossible to foresee those all in advance—better to adopt a system that is structured to anticipate them. "Unknown unknowns" are a fact of life, no matter how disciplined we believe we are with our preparation.
afpx 7y ago
Don’t hardware products evolve in terms of form and function? The iterations may be longer, but it’s still iterative and incremental.
- himynameisdom 7y ago
  Agreed. Look no further than the iPhone.
tobr 7y ago
I have no real experience designing hardware, but I do have a story about extreme waterfall in hardware design. I was once in a meeting with some hardware people who were looking for help with the UX and complementary app for their product. They had already locked the hardware design, but had yet to decided what the buttons would actually do. Essentially, they were looking for help to come up with features for the buttons. Thankfully I didn’t get the job.
- jankotek 7y ago
  Sounds quite valid. Microchip have N inputs for N buttons, functions are solved in firmware, some inputs may not be used.
  - kyllo 7y ago
    It's valid to decide how many buttons the user is going to need, before having any idea what the users might actually want those buttons to do?
    - TeMPOraL 7y ago
      I think it could be. E.g. when making a low-cost consumer appliance. They must have had some idea of what they were building, enough to say that the upper bound on the number of buttons they need is N. This just creates a design constraint - they now have to figure out how to do something useful and ergonomic using no more than N buttons. The exact shape, form and placement of those buttons is orthogonal to the electronics and software part, so they didn't limit themselves there. This is unusual to my taste, but thinking about it, I half expect cheap appliance and toy vendors to work like this - decide on a microchip, and only then figure out what to do with it and how.
    - perl4ever 7y ago
      Looking at almost any car, even in recent years, you will see blanks for features that may or may not be present, that need buttons if they are there. They may be more obvious on some cars than others, but even luxury cars have them.
InternetOfStuff 7y ago
> However, I still think waterfall is the only approach when trying to design a hardware product. Electronics require pretty specific requirements up front before you design and order boards, obviously mechanical tooling can be even more expensive. I disagree, having taken part in agile embedded development. Sure, it looked a bit different from pure-software, but the same underlying principle of short iterations applied. Our definition of "short" was a bit different, but still... And yes, you may have some "very specific" requirements, but you may also have some "pretty loose" ones -- just like software. > But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept See, there you go. The core idea behind Agile isn't to have sacrosanct two week sprints (or even to have sprints in the first place), it is to close as many feedback loops as you can as quickly as you can. Whatever that means in practice. This has been good engineering practice for longer than software exists. I read that the Mercury space project created their software in half-day "sprints". Back in the '60s, on punch-card machines (I guess).
- yitchelle 7y ago
  Maybe I am wrong in my understanding, but for agile to work, observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint. For the hardware where the validation can be quite lengthy, this is feedback loop is much, much longer. Especially true when the project gets closer to start of mass production.
  - whatshisface 7y ago
    The philosophy of making the feedback loop as tight as possible is independent of any one particular value of "possible."
  - InternetOfStuff 7y ago
    > Maybe I am wrong in my understanding No, not at all. Just maybe a little... narrow? > observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint. Quite quickly, yes. The next sprint...maybe? Not necessarily. Sure, you'll stick it in the backlog. But whether you'll start working on this improvement immediately is a separate matter. If that's the best course of action, sure, do it. But maybe you have more pressing matters, and the present implementation will do for now. Or... it's not possible to attack it in the next sprint, because a new board needs to be spun, and that takes preparation. Then it'll be slated for the appropriate time, by necessity. That doesn't mean you forego an agile approach -- it just looks different, because the landscape is different. > Especially true when the project gets closer to start of mass production. Sure. Which is why being able to make, and find, and correct your mistakes early, when it's not so dramatic yet, is the goal of that whole Agile song and dance. As you're intimately familiar of course, surprises in engineering are usually the bad kind, and the later they come, the worse they catch you. So, have as much feedback as you can, as early as you can (and with as much fidelity as you can).
markandrewj 7y ago
This is an interesting comment to me because the Agile process wasn't originally developed for software. https://hbr.org/2016/04/the-secret-history-of-agile-innovation https://hbr.org/2016/04/the-secret-history-of-agile-innovati... On a different note, it is also interesting that stand-up meetings seem to be popular in many companies again, after going through a period where snippets tried to fill role of stand up meetings. http://teche.ltc.mq.edu.au/human-science/getting-s-done-google-snippets-method/ http://teche.ltc.mq.edu.au/human-science/getting-s-done-goog...

supahfly_remix 7y ago

I've done both hardware and software projects. My hardware projects began with an analysis phase where feasibility studies were done to answer questions like, can we build it at the desired frequency with current technology? No actual work on the project would be done at this point, since it was at risk of being thrown away. Modern software projects seem to just start with people typing and little upfront documentation. A long time ago there was documentation (flow charts, Booch diagrams). Now whether these are useful seems debatable, but I do not see any upfront analysis done with software.

mikekchar 7y ago
With hardware you can check your designs against the laws of physics. With software there usually aren't any such laws. Being a guy who has actually written a 1300 page requirements document in my career as well as large books full of designs, my experience has been that the only thing you can test them against is code. Usually you are wrong :-). It's much better to start off with tiny pieces and make sure to write a lot of code along the way. Exactly how much upfront analysis you need before you start writing code is a judgement call, but I would say that it's almost always safer to err on the side of writing code too soon.

lmm 7y ago

Agile exists for the particular constraints of software development, where requirements are unknown, change is relatively cheap, and feedback loops are very tight. I wouldn't expect it to be appropriate to other domains.

namdnay 7y ago
I would go futher and say that Agile exists for the particular constraints of UI software development. User stories, Product Owners and Agility break down if you're building core infrastructure
- vbtemp 7y ago
  Amen! When your product requires true engineering, agile just causes you to keep chasing your tail. Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor.
  - 0x445442 7y ago
    Agree with you and parent. "Agile", in it's current form, is managements holy grail pursuit of commoditizing software development. It's the latest management fad to circumvent the law of fast, good and cheap. Quality software is engineered and is expensive to develop.
  - InternetOfStuff 7y ago
    Speaking as an aeronautical engineer, I disagree. > Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor. Agile just means closing as many feedback feedback loops as you can as early as you can, and to preserve opportunities to course-correct for as long as you can. All this to keep the destructive effects of surprises (which are sure to catch you) as low as possible. This is good engineering practice, plain and simple.
- pflenker 7y ago
  I have seen Agile working with pure core infrastructure teams. How does the UI (or lack thereof) change the applicability of agile?

perlgeek 7y ago

> However, I still think waterfall is the only approach when trying to design a hardware product. You can still use some agile ideas when working in electronics, thought it might look quite differently than in software. For example, if you are a startup and your plan is to create a super duper wireless speaker with bluetooth, wifi and AI, you could first build a wireless speaker with only bluetooth, and sell that. That way you build experience with producing speakers, sales channels, manufacturing, sourcing etc., and build a customer base. Then you could ask your customer base if they'd prefer wifi or AI in the next model, and iterate accordingly. This is not the same as doing one-week sprints in software, but it does iterate that you can start small, build and sell small, viable products, and work your way up to the intended product.

crimsonalucard 7y ago
This is different. Agile and waterfall seem to be defined over the lifetime of a product. Iterating the concept over several products while doing waterfall on each design sounds like a combination of waterfall and agile. I'll be clever and call this transmogrification "agilefall"
- pipelineist 7y ago
  But that's the thing behind agile: you do nice, quick two-week (or however long your sprint is) waterfalls. These quick loops are really the only difference, and are precisely where the advantage lies. And having as short feedback loops as you can get away with has been sound engineering practice since before software was a thing.
  - crimsonalucard 7y ago
    Who says I can't have a 2 month sprint and gather feedback and do testing in those 2 months? Engineering has always done this and called it waterfall. The difference now is more bureaucracy under agile.
crimsonalucard 7y ago
This is also a good way to build airplanes and bridges.

Fr0styMatt88 7y ago

There's a talk well worth watching by Kevlin Henney called 'Old Is the New New' [1], where he points out that waterfall was initially conceived with design iteration in mind and yet that part was just essentially forgotten and replaced by something overly-simplified in common understanding. [1] https://www.youtube.com/watch?v=AbgsfeGvg3E https://www.youtube.com/watch?v=AbgsfeGvg3E

aedron 7y ago
The term "waterfall" is a straw man, software development methodologies have always required iterations. Just look at the Rational Unified Process (the industry standard before agile): https://en.wikipedia.org/wiki/Rational_Unified_Process#Four_project_life-cycle_phases https://en.wikipedia.org/wiki/Rational_Unified_Process#Four_... Every phase of the project has iterations, but iterations stress different things (requirements in the beginning, construction and handover in the latter phases).
- Jtsummers 7y ago
  Tragicaly, it's not a strawman, it's an enshrined project management method the DoD created from a misunderstanding of Royce, which escaped into the wild. Now, most people who say they do Waterfall are quite mistaken. They don't, they do some sort of iterative method as you say. But they report as if they have distinct, linear phases with distinct linear steps, as if Waterfall were the reality and not an imagining. Which is itself problematic. This means that upper managemnet comes to believe that Waterfall works because they see it working, not realizing that the reports themselves are misleading. Everytime one of the project managers tells me they're doing Waterfall I press until they admit it's "Modified Waterfall", by which they mean the V-model or Spiral or other models with explicit feedback loops/mechanisms. And it frustrates me to no end that they keep using the wrong terms rather than the precise ones, because now upper management has begun enshrining Waterfall again after two decades of improvements. Now we have to fight the same battles, to impress upon them that iterative methods are what we actually do, and that a strict linear flow is impossible.
- pflenker 7y ago
  Some anecdotal evidence that waterfall is not a straw man: at least 10 years ago, waterfall was taught as waterfall without iterations at some German universities. This was the starting point, and many derived models, like the V-Model, where also taught, but iterations we’re nowhere in sight.

crimsonalucard 7y ago

Its a proper way to design software as well. I get the purpose of agile but inevitably agile code has the tendency to become a giant mess.

beat 7y ago
"inevitably all code has the tendency to become a giant mess". There, fixed it for you.
- crimsonalucard 7y ago
  You didn't fix anything. You mutilated/slaughtered the sentence. News for you: Not all software has the tendency to become a giant mess.
  - beat 7y ago
    #notallsoftware
AnimalMuppet 7y ago
"Inevitably" is a bit strong. I have seen it not become a giant mess. It took a team where almost all members had both talent and discipline, though. Without discipline, I'd agree with beat - any process will produce code that becomes a giant mess.

markrages 7y ago

Agile works OK for electronics. I have done it. With quick-turn fab houses, you can do two-week sprints in hardware. You can fix up the circuit with X-acto/bluewire changes, and roll the fixes into the next sprint. Or you can make individual subsystems per sprint. And with firmware, most software methodologies work with minor changes. Usually you can get something working in the first sprint, and iterate from there.

roland35 7y ago
Your absolutely right, and with a modular system design it can make it easier to plug in iterations of individual components. But at some point early in the design you need to lay out how the modules will work together, i.e. do we use CAN? 24V power or 48V? All that can be changed as well but at some point it gets complicated! For a simple project all of that can be managed iteratively.
- InternetOfStuff 7y ago
  > All that can be changed as well but at some point it gets complicated! Not everything has to be changed, that's just a strawman. But not every detail has to be nailed down at the beginning either. The idea behind Agile is to reduce risk. If there is no risk of the bus system changing on you, there's no harm in fixing it right at the beginning. But if there is a chance it might, you'd do well to have systems in place which enable you to react to changes with a minimum (though non-zero, of course) amount of pain.
- aidenn0 7y ago
  The same is true with software, unless you suggest that Agile will change the implementation language with every sprint...
- organsnyder 7y ago
  All the more reason to use an agile approach! The only reason you would be making those major changes is in the face of new information: a change in requirements, an unforeseen challenge, etc. It's impossible to foresee those all in advance—better to adopt a system that is structured to anticipate them. "Unknown unknowns" are a fact of life, no matter how disciplined we believe we are with our preparation.

afpx 7y ago

Don’t hardware products evolve in terms of form and function? The iterations may be longer, but it’s still iterative and incremental.

himynameisdom 7y ago
Agreed. Look no further than the iPhone.

tobr 7y ago

I have no real experience designing hardware, but I do have a story about extreme waterfall in hardware design. I was once in a meeting with some hardware people who were looking for help with the UX and complementary app for their product. They had already locked the hardware design, but had yet to decided what the buttons would actually do. Essentially, they were looking for help to come up with features for the buttons. Thankfully I didn’t get the job.

jankotek 7y ago
Sounds quite valid. Microchip have N inputs for N buttons, functions are solved in firmware, some inputs may not be used.
- kyllo 7y ago
  It's valid to decide how many buttons the user is going to need, before having any idea what the users might actually want those buttons to do?
  - TeMPOraL 7y ago
    I think it could be. E.g. when making a low-cost consumer appliance. They must have had some idea of what they were building, enough to say that the upper bound on the number of buttons they need is N. This just creates a design constraint - they now have to figure out how to do something useful and ergonomic using no more than N buttons. The exact shape, form and placement of those buttons is orthogonal to the electronics and software part, so they didn't limit themselves there. This is unusual to my taste, but thinking about it, I half expect cheap appliance and toy vendors to work like this - decide on a microchip, and only then figure out what to do with it and how.
  - perl4ever 7y ago
    Looking at almost any car, even in recent years, you will see blanks for features that may or may not be present, that need buttons if they are there. They may be more obvious on some cars than others, but even luxury cars have them.

InternetOfStuff 7y ago

> However, I still think waterfall is the only approach when trying to design a hardware product. Electronics require pretty specific requirements up front before you design and order boards, obviously mechanical tooling can be even more expensive. I disagree, having taken part in agile embedded development. Sure, it looked a bit different from pure-software, but the same underlying principle of short iterations applied. Our definition of "short" was a bit different, but still... And yes, you may have some "very specific" requirements, but you may also have some "pretty loose" ones -- just like software. > But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept See, there you go. The core idea behind Agile isn't to have sacrosanct two week sprints (or even to have sprints in the first place), it is to close as many feedback loops as you can as quickly as you can. Whatever that means in practice. This has been good engineering practice for longer than software exists. I read that the Mercury space project created their software in half-day "sprints". Back in the '60s, on punch-card machines (I guess).

yitchelle 7y ago
Maybe I am wrong in my understanding, but for agile to work, observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint. For the hardware where the validation can be quite lengthy, this is feedback loop is much, much longer. Especially true when the project gets closer to start of mass production.
- whatshisface 7y ago
  The philosophy of making the feedback loop as tight as possible is independent of any one particular value of "possible."
- InternetOfStuff 7y ago
  > Maybe I am wrong in my understanding No, not at all. Just maybe a little... narrow? > observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint. Quite quickly, yes. The next sprint...maybe? Not necessarily. Sure, you'll stick it in the backlog. But whether you'll start working on this improvement immediately is a separate matter. If that's the best course of action, sure, do it. But maybe you have more pressing matters, and the present implementation will do for now. Or... it's not possible to attack it in the next sprint, because a new board needs to be spun, and that takes preparation. Then it'll be slated for the appropriate time, by necessity. That doesn't mean you forego an agile approach -- it just looks different, because the landscape is different. > Especially true when the project gets closer to start of mass production. Sure. Which is why being able to make, and find, and correct your mistakes early, when it's not so dramatic yet, is the goal of that whole Agile song and dance. As you're intimately familiar of course, surprises in engineering are usually the bad kind, and the later they come, the worse they catch you. So, have as much feedback as you can, as early as you can (and with as much fidelity as you can).

markandrewj 7y ago

This is an interesting comment to me because the Agile process wasn't originally developed for software. https://hbr.org/2016/04/the-secret-history-of-agile-innovation https://hbr.org/2016/04/the-secret-history-of-agile-innovati... On a different note, it is also interesting that stand-up meetings seem to be popular in many companies again, after going through a period where snippets tried to fill role of stand up meetings. http://teche.ltc.mq.edu.au/human-science/getting-s-done-google-snippets-method/ http://teche.ltc.mq.edu.au/human-science/getting-s-done-goog...