> I no longer think of developers as professional if they fail to use these practices.
So anyone who doesn't use pair programming is not being professional?
No: if you are using Scrum and if you are not using the complete set of Agile Engineering practices, then you are not being professional. Sorry if the context wasn't completely clear.
FWIW, adding staff to improve productivity is anti-Agile and no good Agile consultant, trainer, coach or ScrumMaster should recommend this course of action. Hopefully every single person who is in a position of "expertise" around Agile has read "The Mythical Man-Month" by Brooks and Martin Fowler's article about Scaling Agile. Both of these provide significant arguments against growing software teams/organizations to solve productivity problems.
Actually, what I stated is that if you are using Scrum, you must also use the Agile Engineering practices to be successful and if you are not, then I do not consider you to be a professional developer.
If you aren't using Scrum, then I have no opinion about your engineering practices or your professionalism. I suspect that the engineering practices are valuable outside of a Scrum environment, but I don't have enough experience with non-Agile environments to be able to comment with any degree of certainty.
Yes, it is strong. Do you disagree with my statement about surgeons? Assuming you do not, then think about it from my perspective: I've worked on several large-scale mission-critical software systems where I personally used most of the practices I listed. I have also seen others use these practices to the same degree. In every case, the results have been clear: zero-defect software is possible and can be done _faster_ than "normal" development. By "zero-defect" I mean that the handoff from development to QA, then to pre-production then to production all resulted in zero defects found over the course of, in one case, several years. Just to be clear, the software I'm talking about is distributed, high-availability, high-transaction rate, multithreaded software running on thousands of servers and in all cases delivered either on-time or early. If you can find specific examples of this level of quality and productivity without using the practices I list, then I stand corrected: it is possible to be a software professional without those practices.
Actually, top individual contributors are tasked with two separate part-time jobs. So, no, they don't get paid a lot more for this. I suppose if they were working 80 hour weeks and truly doing two jobs then it might make sense to pay them more, but most Agile methods (including Scrum) include the important rule that everyone needs to work at a sustainable pace. Additionally, they aren't getting "nothing" in return: what they get is a team that quickly learns how to avoid dumb-ass errors so that the senior person doesn't have to constantly fix idiots' work and instead can focus on the cool work.
Since this seems to be addressed to me, but is arguing about something I didn't say, I'm not sure how to reply... can you clarify please where I unconditionally asserted "the need for a given practice or methodology"? Or perhaps alternatively, can you point out how what I have described "is a soulless, creativity sapping mess of ass covering."?
True enough... and often forgotten by organization that are adopting Scrum. Scrum is by far at its best when it is used for product development (software or otherwise) and if it is used in other situations (e.g. IT projects, operations, etc.) it needs to either be modified or its results won't be very impressive.
Oh no, are we still harping on about this? I though it had died 10 years ago.
Paired programming: one compenent programmer carries the lazy one. Why should I have to explain every line of code because he is too lazy or thick to read it himself?
In the end the competent guys went off and coded the app on their own in a quarter of the time.
Actually, I also recommend this to most organizations: if you have 100 people working on a system, you can probably find the top 10, get them to work together and let the other 90 surf the web... and you will get a better product faster.
Still, most organizations don't have this luxury (for whatever reason, good or bad) and so they need a system and tools to help with the problem of poor performers. A good agile environment forces (yes forces) efficient cross training. If you are a top individual contributor, maybe you resent this. That, in my opinion, is also unprofessional.
I teach and coach teams on how to adopt Agile for their work. I have a computer science degree and worked as a software developer and architect for several years... using Agile methods. I no longer do lots of hands on work, but I mention all this to help you understand that what I am saying is based on experience, not theory.
Scrum is one Agile method. It is good for creating high-performance product development teams. Unfortunately, it cannot succeed without some additional things: you _must_ also use the Agile Engineering practices from Extreme Programming: refactoring, test driven development, pair programming, continuous integration, user stories, architectural spikes, agile modelling, and acceptance test driven development. These are the practices that directly address your concerns about the problem with changing an existing software system.
Probably the most important, and the least understood is refactoring. Refactoring is defined, in agile methods, as changing the design of the system without changing its function. There are different types of refactoring: UI refactoring (e.g. radio buttons to drop-down selection list), code refactoring (e.g. pulling a method from a subclass into its parent class) and database refactoring (e.g. splitting a table into two or more tables along columns). Refactoring can be done on its own, but it is much better to do it with the other practices, particularly TDD and Pair Programming. Refactoring is essential for maintaining internal quality of a system in the face of constant change (which normally results in ever-increasing amounts of cruft and technical debt).
In my practice with software teams, I no longer think of developers as professional if they fail to use these practices. They are hackers in the most pejorative sense of the word. Think of a surgeon. If a surgeon fails to wash her hands before operating, she is failing as a professional. These agile engineering practices are like surgeons washing their hands.
FWIW, OpenAgile was designed for non-software agile use including management, sales, marketing, operations, etc. and there are some very interesting uses out there. I'm on the board of directors for the OpenAgile Center for Learning so I'm a bit biased, but I strongly recommend this approach to any organization or team that wishes to improve effectiveness. I think it's very exciting that Agile is spreading beyond software, but there are also many challenges. In particular, Scrum is really best for new product development and many practices are not applicable outside that environment.
The best and easiest way to deal with bugs is to not have them in the first place. Build quality in. This means you need to read two books at a minimum: "Refactoring" by Martin Fowler and "Test Driven Development by Example" by Kent Beck. If you properly understand and apply the techniques in those books your defect rates should quickly drop to manageable levels: less than one new bug per month and an average fix time for bugs of far faster than that (e.g. 2 hours). Most programming languages/platforms have appropriate test frameworks. Here's a good list of unit testing frameworks that are compatible with the techniques in these books: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks.
Hardly trivial. I've worked in large systems in finance with billions of dollars of transactions being processed daily. Numerous times I have made QA redundant for anything but a pro-forma checkbox: no defects found. Now, I will admit that for the last five years I haven't been actively coding as a profession, but I still consider it critical to let people know that zero defects is possible.
Like I said; anything less than zero known defects is unprofessional. You deserve to support your crap if you can't build good software.
Seriously. If you aren't using ATDD (Acceptance Test Driven Development) and TDD (Test Driven Development), then you have no excuses. Support them forever. I consider it unprofessional to release software with any known bugs and I have been doing this successfully for 10+ years. ATDD proves to the client that you have built what they want and that it functions as they expect (this is your contract) and TDD proves to you yourself that the internal quality of the code will hold up as well (very low rates of unexpected problems). Defects are preventable.
Think of this like surgery: if you are being rushed into the OR, you don't yell at the surgeons and nurses to NOT wash their hands and just dig into you. And even if you did, they would ignore you. ATDD and TDD are a lot like washing your hands before surgery. If you don't do it, don't be surprised at the consequences... it can be fatal.
Heh! I don't have any easy solutions for that. I suspect that it might be possible for such a government to be chartered such that: 1. Campaigning of any sort is not allowed for elected members. 2. Elected members are not members of political parties nor members of special interest groups nor executives of large organizations nor major shareholders of such. 3. Elected members are not "representatives" but rather people who are free to vote their conscience.
The USA government is just one form of democracy that has been subverted over centuries by corporate interests. Maybe after all that experience and history we can come up with a democratic system that is (at least) harder to subvert.
I know a lot of people here are anti-world-government. But isn't this just one of a growing list of examples of the need for a world government of some sort? I suspect a federalist, democratic world state that has some global jurisdiction would be better than the growing injustice of US business hegemony. Two groups that seem to have workable ideas are the World Federalists and the Baha'is (which, because it is religious is almost certainly going to be dismissed out of hand by lots here, but hopefully we can learn from a _working_ global system).
Anyway, this type of American dominance frightens me. I'm a Canadian citizen where certain types of file sharing are allowed... we pay a tax for this in fact. If the Americans can prosecute me for something that I am doing legally in my own country, then we have a major failure of global governance.
Indeed, the spirit of the age we live in seems to have us moving more and more towards recognition of our fundamental interconnectedness. That said, recognition of interconnectedness needs to be followed up by practical action to account for that interconnectedness. You asked specifically about power, charm and effectiveness. I certainly don't think that a casual glance at what Baha'is have accomplished would answer that which is why I suggested a deeper investigation. Suffice it to say that we are not in a hurry (mostly) as developing a global civilization is not something that happens in mere decades! I suspect that fossil fuels, the environment and many other things will become crises that we deal with (for better or worse) before a "golden age" of civilization is established. But I do believe strongly in the power of individual action to make a difference, in the power of communities to make a difference... and even in the power of institutions to make a difference.
The betterment of the world can be accomplished through pure and goodly deeds, through commendable and seemly conduct.
Pretty simple.
I'm not deeply knowledgable of the TM movement but based on what you have described, it does seem to be a reflection of this "spirit of the age". I also agree that that our ability to act collectively is pretty poor. But I also think that it is improving (sloooowly) and that there is real hope for humanity. Compared to the 19th century, we are experts at collective action. Compared to what we can imagine, we still have a long way to go!
Please consider investigating this deeply and using your _reason_ to do so. For the last 150 years, followers of Baha'u'llah have quietly been building a sustainable, unified, world civilization that acknowledges the value of science, art _and_ spirit, that recognizes that individuals, communities and institutions all need to develop, that is based on principles such as truthfulness, unity in diversity, elimination of prejudice, equality of men and women. The purpose of the teachings of Baha'u'llah is to unite all the races and peoples of the world in one universal cause and one common faith.
I agree completely. Some in-house studies that I have been privy to have shown 2-1 or 3-1 productivity difference between good co-located teams and "good" virtual teams. Creating a true, high-performance virtual team is incredibly hard emotionally, incredibly time-consuming, and costs a lot in terms of tools and travel. If this is being done for convenience of the team members or for cost savings, it's a bad idea. The only good reason to have distributed teams is if there is a compelling strategic reason that trumps the hit you will take financially and morale-wise.
That said, one thing that is worth trying is to create an environment as close as possible to what you would get with a co-located team. To do this, here are some things to try:
1. Set core hours (at least 3) every day when everyone on the team, regardless of time zone, will be at work simultaneously.
2. During core hours, use a good video conferencing tool (e.g. Office Communicator), in an always-on state for all team members - be in the same space at the same time.
3. During core hours, all team members agree to forego the use of headphones or anything else that would prevent them from instantly being aware of something happening with any of the other team members.
4. Have a live update task tracking tool that all team members use. (A wiki does not work because you have to refresh to see updates. Cardmeeting.com is a decent virtual wall that has live updates.)
5. Have a second (or third) monitor for every team member that is dedicated to the always-on communication tools (video conferencing, task tracking). These always-on tools should _never_ be covered by anything else.
Basically, these suggestions are designed to maximize the quality, bandwidth and minimize the latency of communication among the team members.
I can't prove it, but I believe that people in the US _are_ some of the most oppressed in the world. The problem is that the oppression is subtle: consumerism. It is pervasive and it is not considered oppression (by most people). This is far worse than overt oppression where people are conscious of the oppression and can make choices about when and how to struggle against the oppression.
That's why time boxes are so important. By doing a breakdown into tasks that are _estimated_ to be one day of work or less, inside of a 10 day iteration, then you have effectively created finite variance in your estimates. This is an important part of the method. As well, you have to keep some other variables constant, all of which are under the control of the team/management.
Basically this is the slope of the line of estimated remaining work over a fixed timebox (such as an iteration or sprint). It's based on an application of the Central Limit Theorem and therefore it requires a few things to be in place in order to be accurate. I'm hoping to do a presentation on Commitment Velocity at the Agile 2010 conference in Nashville (link is to my session proposal).
This goes far beyond IBM's employees. Many other large organizations are strongly influenced by IBM still. In my work as a process improvement consultant, I have seen many people using the Lotus environment, particularly in financial institutions. Does this mean that they too will start using ODF?
As well, as a Mac user myself, and for others using non-MS systems, it will be nice to be able to tell people that IBM uses OpenOffice.org (which will be the shortcut way of telling them that they are using an in-house customized version...) as an incentive / emotional proof that OOo is viable for their own use.
I was really interested in sleep stuff when I was in college. A bunch of friends and I started a club called the "8 Year Club". We figured out that if we could train ourselves to work with just 4 hours of sleep per night, we could gain back 8 years of extra "life". We were really excited about this and figured that if we could support each other, we'd be able to get through the tough part and make it a real habit in our lives.
We stopped after about a week.
Slashdot Mirror
> I no longer think of developers as professional if they fail to use these practices.
So anyone who doesn't use pair programming is not being professional?
No: if you are using Scrum and if you are not using the complete set of Agile Engineering practices, then you are not being professional. Sorry if the context wasn't completely clear.
FWIW, adding staff to improve productivity is anti-Agile and no good Agile consultant, trainer, coach or ScrumMaster should recommend this course of action. Hopefully every single person who is in a position of "expertise" around Agile has read "The Mythical Man-Month" by Brooks and Martin Fowler's article about Scaling Agile. Both of these provide significant arguments against growing software teams/organizations to solve productivity problems.
Actually, what I stated is that if you are using Scrum, you must also use the Agile Engineering practices to be successful and if you are not, then I do not consider you to be a professional developer.
If you aren't using Scrum, then I have no opinion about your engineering practices or your professionalism. I suspect that the engineering practices are valuable outside of a Scrum environment, but I don't have enough experience with non-Agile environments to be able to comment with any degree of certainty.
Yes, it is strong. Do you disagree with my statement about surgeons? Assuming you do not, then think about it from my perspective: I've worked on several large-scale mission-critical software systems where I personally used most of the practices I listed. I have also seen others use these practices to the same degree. In every case, the results have been clear: zero-defect software is possible and can be done _faster_ than "normal" development. By "zero-defect" I mean that the handoff from development to QA, then to pre-production then to production all resulted in zero defects found over the course of, in one case, several years. Just to be clear, the software I'm talking about is distributed, high-availability, high-transaction rate, multithreaded software running on thousands of servers and in all cases delivered either on-time or early. If you can find specific examples of this level of quality and productivity without using the practices I list, then I stand corrected: it is possible to be a software professional without those practices.
Actually, top individual contributors are tasked with two separate part-time jobs. So, no, they don't get paid a lot more for this. I suppose if they were working 80 hour weeks and truly doing two jobs then it might make sense to pay them more, but most Agile methods (including Scrum) include the important rule that everyone needs to work at a sustainable pace. Additionally, they aren't getting "nothing" in return: what they get is a team that quickly learns how to avoid dumb-ass errors so that the senior person doesn't have to constantly fix idiots' work and instead can focus on the cool work.
Since this seems to be addressed to me, but is arguing about something I didn't say, I'm not sure how to reply... can you clarify please where I unconditionally asserted "the need for a given practice or methodology"? Or perhaps alternatively, can you point out how what I have described "is a soulless, creativity sapping mess of ass covering."?
True enough... and often forgotten by organization that are adopting Scrum. Scrum is by far at its best when it is used for product development (software or otherwise) and if it is used in other situations (e.g. IT projects, operations, etc.) it needs to either be modified or its results won't be very impressive.
pair programming
Oh no, are we still harping on about this? I though it had died 10 years ago.
Paired programming: one compenent programmer carries the lazy one. Why should I have to explain every line of code because he is too lazy or thick to read it himself?
In the end the competent guys went off and coded the app on their own in a quarter of the time.
Actually, I also recommend this to most organizations: if you have 100 people working on a system, you can probably find the top 10, get them to work together and let the other 90 surf the web... and you will get a better product faster.
Still, most organizations don't have this luxury (for whatever reason, good or bad) and so they need a system and tools to help with the problem of poor performers. A good agile environment forces (yes forces) efficient cross training. If you are a top individual contributor, maybe you resent this. That, in my opinion, is also unprofessional.
I teach and coach teams on how to adopt Agile for their work. I have a computer science degree and worked as a software developer and architect for several years... using Agile methods. I no longer do lots of hands on work, but I mention all this to help you understand that what I am saying is based on experience, not theory.
Scrum is one Agile method. It is good for creating high-performance product development teams. Unfortunately, it cannot succeed without some additional things: you _must_ also use the Agile Engineering practices from Extreme Programming: refactoring, test driven development, pair programming, continuous integration, user stories, architectural spikes, agile modelling, and acceptance test driven development. These are the practices that directly address your concerns about the problem with changing an existing software system.
Probably the most important, and the least understood is refactoring. Refactoring is defined, in agile methods, as changing the design of the system without changing its function. There are different types of refactoring: UI refactoring (e.g. radio buttons to drop-down selection list), code refactoring (e.g. pulling a method from a subclass into its parent class) and database refactoring (e.g. splitting a table into two or more tables along columns). Refactoring can be done on its own, but it is much better to do it with the other practices, particularly TDD and Pair Programming. Refactoring is essential for maintaining internal quality of a system in the face of constant change (which normally results in ever-increasing amounts of cruft and technical debt).
In my practice with software teams, I no longer think of developers as professional if they fail to use these practices. They are hackers in the most pejorative sense of the word. Think of a surgeon. If a surgeon fails to wash her hands before operating, she is failing as a professional. These agile engineering practices are like surgeons washing their hands.
FWIW, OpenAgile was designed for non-software agile use including management, sales, marketing, operations, etc. and there are some very interesting uses out there. I'm on the board of directors for the OpenAgile Center for Learning so I'm a bit biased, but I strongly recommend this approach to any organization or team that wishes to improve effectiveness. I think it's very exciting that Agile is spreading beyond software, but there are also many challenges. In particular, Scrum is really best for new product development and many practices are not applicable outside that environment.
The best and easiest way to deal with bugs is to not have them in the first place. Build quality in. This means you need to read two books at a minimum: "Refactoring" by Martin Fowler and "Test Driven Development by Example" by Kent Beck. If you properly understand and apply the techniques in those books your defect rates should quickly drop to manageable levels: less than one new bug per month and an average fix time for bugs of far faster than that (e.g. 2 hours). Most programming languages/platforms have appropriate test frameworks. Here's a good list of unit testing frameworks that are compatible with the techniques in these books: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks.
Hardly trivial. I've worked in large systems in finance with billions of dollars of transactions being processed daily. Numerous times I have made QA redundant for anything but a pro-forma checkbox: no defects found. Now, I will admit that for the last five years I haven't been actively coding as a profession, but I still consider it critical to let people know that zero defects is possible.
Like I said; anything less than zero known defects is unprofessional. You deserve to support your crap if you can't build good software.
Seriously. If you aren't using ATDD (Acceptance Test Driven Development) and TDD (Test Driven Development), then you have no excuses. Support them forever. I consider it unprofessional to release software with any known bugs and I have been doing this successfully for 10+ years. ATDD proves to the client that you have built what they want and that it functions as they expect (this is your contract) and TDD proves to you yourself that the internal quality of the code will hold up as well (very low rates of unexpected problems). Defects are preventable.
Think of this like surgery: if you are being rushed into the OR, you don't yell at the surgeons and nurses to NOT wash their hands and just dig into you. And even if you did, they would ignore you. ATDD and TDD are a lot like washing your hands before surgery. If you don't do it, don't be surprised at the consequences... it can be fatal.
Heh! I don't have any easy solutions for that. I suspect that it might be possible for such a government to be chartered such that:
1. Campaigning of any sort is not allowed for elected members.
2. Elected members are not members of political parties nor members of special interest groups nor executives of large organizations nor major shareholders of such.
3. Elected members are not "representatives" but rather people who are free to vote their conscience.
The USA government is just one form of democracy that has been subverted over centuries by corporate interests. Maybe after all that experience and history we can come up with a democratic system that is (at least) harder to subvert.
I know a lot of people here are anti-world-government. But isn't this just one of a growing list of examples of the need for a world government of some sort? I suspect a federalist, democratic world state that has some global jurisdiction would be better than the growing injustice of US business hegemony. Two groups that seem to have workable ideas are the World Federalists and the Baha'is (which, because it is religious is almost certainly going to be dismissed out of hand by lots here, but hopefully we can learn from a _working_ global system).
Anyway, this type of American dominance frightens me. I'm a Canadian citizen where certain types of file sharing are allowed... we pay a tax for this in fact. If the Americans can prosecute me for something that I am doing legally in my own country, then we have a major failure of global governance.
Indeed, the spirit of the age we live in seems to have us moving more and more towards recognition of our fundamental interconnectedness. That said, recognition of interconnectedness needs to be followed up by practical action to account for that interconnectedness. You asked specifically about power, charm and effectiveness. I certainly don't think that a casual glance at what Baha'is have accomplished would answer that which is why I suggested a deeper investigation. Suffice it to say that we are not in a hurry (mostly) as developing a global civilization is not something that happens in mere decades! I suspect that fossil fuels, the environment and many other things will become crises that we deal with (for better or worse) before a "golden age" of civilization is established. But I do believe strongly in the power of individual action to make a difference, in the power of communities to make a difference... and even in the power of institutions to make a difference.
The betterment of the world can be accomplished through pure and goodly deeds, through commendable and seemly conduct.
Pretty simple.
I'm not deeply knowledgable of the TM movement but based on what you have described, it does seem to be a reflection of this "spirit of the age". I also agree that that our ability to act collectively is pretty poor. But I also think that it is improving (sloooowly) and that there is real hope for humanity. Compared to the 19th century, we are experts at collective action. Compared to what we can imagine, we still have a long way to go!
And I don't expect world government to change any time soon. Who or what would be powerful, charming and effective enough to change mankind's nature?
Answer: Baha'u'llah.
Please consider investigating this deeply and using your _reason_ to do so. For the last 150 years, followers of Baha'u'llah have quietly been building a sustainable, unified, world civilization that acknowledges the value of science, art _and_ spirit, that recognizes that individuals, communities and institutions all need to develop, that is based on principles such as truthfulness, unity in diversity, elimination of prejudice, equality of men and women. The purpose of the teachings of Baha'u'llah is to unite all the races and peoples of the world in one universal cause and one common faith.
I agree completely. Some in-house studies that I have been privy to have shown 2-1 or 3-1 productivity difference between good co-located teams and "good" virtual teams. Creating a true, high-performance virtual team is incredibly hard emotionally, incredibly time-consuming, and costs a lot in terms of tools and travel. If this is being done for convenience of the team members or for cost savings, it's a bad idea. The only good reason to have distributed teams is if there is a compelling strategic reason that trumps the hit you will take financially and morale-wise.
That said, one thing that is worth trying is to create an environment as close as possible to what you would get with a co-located team. To do this, here are some things to try:
1. Set core hours (at least 3) every day when everyone on the team, regardless of time zone, will be at work simultaneously.
2. During core hours, use a good video conferencing tool (e.g. Office Communicator), in an always-on state for all team members - be in the same space at the same time.
3. During core hours, all team members agree to forego the use of headphones or anything else that would prevent them from instantly being aware of something happening with any of the other team members.
4. Have a live update task tracking tool that all team members use. (A wiki does not work because you have to refresh to see updates. Cardmeeting.com is a decent virtual wall that has live updates.)
5. Have a second (or third) monitor for every team member that is dedicated to the always-on communication tools (video conferencing, task tracking). These always-on tools should _never_ be covered by anything else.
Basically, these suggestions are designed to maximize the quality, bandwidth and minimize the latency of communication among the team members.
I can't prove it, but I believe that people in the US _are_ some of the most oppressed in the world. The problem is that the oppression is subtle: consumerism. It is pervasive and it is not considered oppression (by most people). This is far worse than overt oppression where people are conscious of the oppression and can make choices about when and how to struggle against the oppression.
Maybe the explanation is simple: http://en.wikipedia.org/wiki/Paradox_of_hedonism
That's why time boxes are so important. By doing a breakdown into tasks that are _estimated_ to be one day of work or less, inside of a 10 day iteration, then you have effectively created finite variance in your estimates. This is an important part of the method. As well, you have to keep some other variables constant, all of which are under the control of the team/management.
Basically this is the slope of the line of estimated remaining work over a fixed timebox (such as an iteration or sprint). It's based on an application of the Central Limit Theorem and therefore it requires a few things to be in place in order to be accurate. I'm hoping to do a presentation on Commitment Velocity at the Agile 2010 conference in Nashville (link is to my session proposal).
As well, as a Mac user myself, and for others using non-MS systems, it will be nice to be able to tell people that IBM uses OpenOffice.org (which will be the shortcut way of telling them that they are using an in-house customized version...) as an incentive / emotional proof that OOo is viable for their own use.
I was really interested in sleep stuff when I was in college. A bunch of friends and I started a club called the "8 Year Club". We figured out that if we could train ourselves to work with just 4 hours of sleep per night, we could gain back 8 years of extra "life". We were really excited about this and figured that if we could support each other, we'd be able to get through the tough part and make it a real habit in our lives. We stopped after about a week.
You said:
Reason, which is the only mechanism through which we ever make progress...
Music, drama, storytelling, paintings, sculpture, dance, video games, comics, movies, child rearing,...
Nope, no progress coming from those. I guess you must be right - reason is the only mechanism.