I found it very interesting to listen to Seth Winis (who is software development guru). He presented a very eloquent set of principles.
David Weiss, long time researcher in software engineering and IEEE Fellow, encouraged Seth to publish his ideas on YOGA. David has worked in industry, such as Bell Labs, Avaya Labs, the Software Productivity Consortium, Computer Sciences Corp., in government, such as the Naval Research Laboratory and the Office of Technology Assessment, and in academia, where he was professor of software engineering at Iowa State University. He is now retired, with time to step back and inject some humor into his history in software engineering.
YOGA* is a software development process based on ancient principles and derived from many years of experience with software production and introspective research into and measurement of software production.
YOGA stands for
You Only Go Ahead and its theme is to be forward looking. It consists of 10 basic commandments such as:
- Ignore the past and only look ahead. Don't worry about repeating past mistakes.
- Don't try to be rational. There is substantial evidence that there’s no such thing as a rational software production process. Think of yourselves as artists, free to create.
- Each team member should meditate on his/her code for an hour every day. The purpose of the meditation is to become more enlightened about the code and coding. The goal should be to find a place in the code that the team member can modify today.
- Strengthen your core. Your core developers are the ones who make 80% of the changes. Give them coding exercises to do and hold an occasional refactoring contest to see who can refactor fastest
Here are some Q/A ( (Taken from:
http://learning.acm.org/webinar/yoga_qa.cfm).
Q: Can you talk about Slide 17 more? What is NCSL? Was that a typo about off-shoring to project inexperienced group?
A: NCSL is non-commentary source lines of code, i.e., lines of executable code. Not a typo - it happened.
Q: So the idea behind not being rational is to not plan or plan as little as possible?
A: Plan for the unexpected.
Q: How do you promote innovation in a team capacity, rather focus on individualism - using Yoga?
A: Create a team where members respect each otber and encourage new ideas.
Q: What's the main purpose of a stand-up meeting every morning?
A: Team building, Change Selection, Status. It also encourages thought about what to do next and how to present it to others.
Q: How do you control the voting on changes, in order to avoid endless discussions about what is right or wrong to be done? Thanks!
A: In case of controversy or indecision, the senior, most respected team member has final say. Often the chief architect.
Q: Is there a "Witness Protection Program" for Software Gurus? :-)
A: Some create alter egos. Some create gangs of followers who drown out other opinions.
Q: How do you predict changes in software?
A: You can't predict every change, but can predict classes of changes, encode them as variabilities as in the FWS example. To help with prediction, review past changes, think about new technology, and changes in technology. For example, 10 years ago you could have predicted that disk drives would get bigger and faster and might have new protocols for access.
Q: The speaker reminds me of a Guru DMW :-)
A: I have great respect for DMW and often echo his opinions. We have much in common.
Q: How productive were you in rotations? Software is a thinking activity. What was the rate of change for peak performance?
A: Having backups for each team member is a continuing process. When a person becomes expert or senior in one area, rotate her to another area as part of the learning process.
Q: When an issue in a role appears, does everybody assist the actual person in the role?
A: Depends on circumstances, but generally, the backup for the person and perhaps a senior team member.
Q: What about the YAGNI principle in agile software methods in relation to Variability?
A: Start with the minimal useful subset, i.e., variabilities that have most initial value. Then implement next most useful variabilities. Etc. YAGNI is an oversimplified view of this.
Q: I understand how a business environment could change a person's focuses, but what situation would cause an outright descent in productivity? Couldn't you steer that with pay increases or job rotation? I have to ask more questions about slide 17.
A: Decay in morale can be caused by any of a number of reasons (company doing badly, best people leaving, etc.). Anecdote: I know a company where senior developers were told to train new, inexperienced, offshore developers and were told that they would be laid off after they completed the training. Not good for morale or productivity.
Q: How would you sustain tacit system "essential knowledge" with yoga through business decisions that "optimize" organizations through workforce reductions/retirements etc.?
A: The only real response is to maintain good documentation, particularly documentation that records essential decisions and knowledge. See "A Rational Design Process, How and Why To Fake It."
Q: YOGA has a resemblance of Agile methodologies. What are the key differences, for folks want to move from Agile?
A: YOGA encourages more forethought about architecture and potential changes, and encourages more team building; records key decisions and why they were made; tries to put people in a relaxed frame of mind where they can concentrate better.
Q: What do you do when two members of the team have high complaints for each other?
A: Separate them by giving them two distinct and different tasks to do. If one or both continue to ignore team goals in pursuit of local arguments or self-aggrandizement, fire him/her (or them).
Q: What is the exact link between "Salute the Sun" and software engineering?
A: Each requires careful and precise mind and body extension and the ability to look ahead and up.
Q: How well does the YOGA process work with multi-site projects?
A: Excellently. That is, in fact, the subject of a whole other lecture.
Q: What if the project has gaps of coding, design, and testing...then how does the principle of thinking about coding one hour each day hold? Also, rotating roles may mean waste of time.
A: Not sure what the gaps are - do you mean there may be intervals of inactivity between each? Thinking about coding (or testing or design for that matter) helps one to look ahead.
Q: How can one know what the future will require from a piece of software? The Standish Reports revealed that 60% of realized functionality wasn't even used.
A: You need to estimate the value of each variability and apply option theory (see above).
Q: When a new member joins the team, how do you sell them on the benefits of a "strum" meeting? Among other things, the guitar in the background for example.
A: Have other team members be welcoming. Have him/her play the guitar initially.
Q: I see YOGA as complementary to SCRUM/Agile. Where SCRUM/Agile focuses on the process and its artifacts, YOGA is more about the practices. Do you agree?
A: No. They are very different. See answer to number 14 (above).
Q: Any YOGA techniques to get over programmer's block (writer's block)?
A: Deep relaxation to clear and focus the mind. Sun salutations to focus the mind and keep active.
Q: [Do you have an] example of an artifact that is not normally used outside "YOGA in Software," for example in Risk?
A: Risk factor.
Q: What can a project manager take away from saluting the sun?
A: Who is flexible and who is not. Who has endurance and who has not. Who needs coaching and who does not. Is the PM up to standards on these aspects as well?
Q: Workforce reductions usually result in abandonment of the software system. Domain Analysis...commonality/variability analysis is useful...but doesn't necessarily prevent or slow the extinction process.
A: It does if the C/V analysis identifies most valuable features.
Q: How would you adapt these YOGA principles to distributed development teams?
A: That's another hour-long lecture. Architecture plays a key role.
Q: What are the success stories of using the YOGA approach?
A: Most companies are unwilling to disclose information about their software development processes, so I can't give specific examples.
Q: Have you been training/exercising this YOGA principle with all your development teams? And what about developer-"divas" who definitely feel too good for this training?
A: Yes, but it is a continuing work in progress. I have little patience for divas. If they want to, they can go work on their own. Of course, there have been some remarkable successes this way, but almost always the results are inherited by a larger team.
Q: Could you talk more about anticipating the future? This was the part of your talk with which I connected most, since I tend to define good software engineering and programming as being deeply connected to good prognostication of future changes.
A: Your connection is correct. See answers 7 and 14 above. There's another hour-long lecture on this topic. See also "The Modular Design of Complex Systems."
Q: Do you want everyone to have an implant?
A: Absolutely. Then I can control the whole human race! We can get around the limitations of our DNA.
Q: Is the YOGA Master included in the role switching?
A: Certainly.
Q: Is this applicable to a beginner software developer?
A: Yes. In fact, best to teach them YOGA in their first projects.
Q: Are Version Control Systems too tied to history to be used with the YOGA program?
A: No. You need them. How else to control changes?
Q: How can YOGA practices be integrated in the software development cycle?
A: Implement the practices described in my talk.
Q: I am a system administrator. I like networking and systems. Please give me advice from your experience to improve my skills and thinking capability so that I can grasp the concept effectively and fast
A: Read papers by David Parnas on requirements, architecture and design. Read about the GQM method for software measurement. Read Software Product Line Engineering by Weiss and Lai. Find a good mentor.
Q: How effective did you find rotation, and how often should it happen?
A: Very effective. I have seen it save projects, both in time and quality considerations.
Q: We actually had standup meetings where we required the project manager to stand on one leg, because they would otherwise become too long. No kidding.
A: Excellent and very consistent with YOGA. You are forward thinkers.
Q: How effective did you find rotation, and how often should it happen?
A: Very effective. I have seen it save projects, both in time and quality considerations.
Q: I arrived late, but I heard you talking about an interesting paper. Can you please state the title of the paper? Thanks.
A: There were several interesting papers and books that I mentioned. See the source references on the slides.
Q: One of the things that happened to me at yoga class was at relaxing time [when] I fell asleep. That too helped me refresh... Would you recommend cat naps at some point of the day (not necessarily at the meeting which happens...)?
A: Falling asleep during deep relaxation sometimes happens to those new to yoga, sometimes because the yoga session is too physically intense and tiring, sometimes because the yoga teacher does not properly emphasize what the student should be trying to do during relaxation. Cat naps [are ok] only if the person is not getting enough sleep at night, which may be an indication of other troubles.
Q: When rotating roles, how much impact does it have on schedule initially?
A: If no one has ever taken a different role before, and it is a new project, and the developers are inexperienced, it can have some schedule impact, I think. In such a situation there will be schedule impact anyway from these factors.
