Tapestry for Nonbelievers
A new article by I. Drobiazko and R. Zubairov introduces v. 5 of the Apache Tapestry component-oriented web framework. The tutorial shows how to create a component and covers IoC in Tapestry and Ajax.
Tracking change and innovation in the enterprise software development community
Interview with Linda Rising by on May 19, 2007 01:48 AM
Fighter Jets and Agile Development at Lockheed Martin (Case study)
Evaluation Guide: Is Your SCM Tool Ready for Agile?
In my opinion the bonobo or chimpanse analogy I take it just as analogy, I have seen both behaviors on humans so I cannot think this differents behaviors came from diferent genetic ascendants, don´t like to push metaphors too far, but they are usefull. Maybe I don´t know all the details, so. Anyway I think this is good to have a metaphor that we can use to reason, to free us from other models, and for me that´s enough, this ideias resonates with my own experience. I think we are not prepared yet is to fully understand the constraints we have in effetive communication, thinking, conceptualizing, we tend to see human comunication, human behavior and thinking skills as unconstained activities but they are not. Problably, don´t really read about it, but my experience supports that our brain have a lot of constraints, we don´t really understand yet. Also analysis wich is our conciense prefered tool, is not a good tool for understanding complex systems, so we need to start creating ways to tap into the unrealized potential of our subconcient and intuition that are more adequate for this tasks. I see intution, as a powerfull processor for deep cause and effect parrallel boolean evaluations, every time we ask a question to ourselves we have an answer a gut response for yes or no without detailed analitical explanation of facts, when we start analysing we mess things up. If this is a constraint maybe is better not to try to explain things in a lot of detail but to use a ritual of food sharing would be more effective, to improve our believing skills in other people ideias even not understanding them fully. This constraints are like physical constraints, we are equiped with intuition about rules in a physical world, it´s just plain stupid to make a machine do two things simultaneusly, but we try to do it all the time with people, we really can´t see this kind of constrain in people. Or be in two places at the same time, in our physical world we understand this is impossible, but we try to do it on our conceptual worlds. So constraints are not bad thing, they are very real and part of our reality, but we tend not to recognize that they "exists", and effectly subordinate everything to this constraints, like face to face communication, and then elevate this constraints, like skill and team building in a team thru peer programming. It´s good to know that the software industry problably will be one of the introducers of principles, values and practices more effectible aligned with kwnoledge workers constraints massivally, this is a welcome and needed revolution in our work world. Juan.
Juan, thank you for your thoughts. You wrote: > ...my experience supports that our brain have a lot of > constraints, we don´t really understand yet. > ... > This constraints are like physical constraints, we are > equiped with intuition about rules in a physical world, > it´s just plain stupid to make a machine do two things > simultaneusly, but we try to do it all the time with > people, we really can´t see this kind of constrain in > people. Or be in two places at the same time, in our > physical world we understand this is impossible, but we > try to do it on our conceptual worlds. I laughed when I saw this, because I am currently in the middle of facilitating a 3-day RecentChangesCamp event in Montreal (called RoCoCoCamp), with people who are very used to collaborating "in two places" (both where they are internationally, and on wikis which are virtual workplaces). Something I've heard a couple of times during the event how our meeting face-to-face here is generating some amazing breakthroughs for them - even for people who have collaborated before online, and for subjects discussed many times before! We're using the OpenSpace method to run the conference... which explicitly encourages people to listen to their "gut feeling" and follow their intuition to find fruitful synergies and like-minded discussions. This is very strange for some, at first. And yet, it works every time. When we make space for the unconscious to contribute to what we are doing, some amazing things happen, seemingly by magic! Oh, and "do food" is an important part of this conference - by design! :-) I don't understand what you are getting at here, in relating this to TOC: > So constraints are not bad thing, they are very real and part of our reality, but we tend not to recognize that they "exists", and effectly subordinate everything to this constraints, like face to face communication, and then elevate this constraints, like skill and team building in a team thru peer programming. Can you say more about this "subordinating" we do? Is it a positive or negative thing, in your opinion? Are you talking about sub-optimization, or something else? I am interested to hear more. thanks deb
Deb, The problem cames when we don´t "subordinate" things to existing constraints. Theory of constraints talks about system improvement and subordinating is one of the 5 focusing steps to cause improvements in a complex system. Take a look at it: http://en.wikipedia.org/wiki/Theory_of_constraints A constraint is like a broken car in a road, even the capacity of the whole road is big, one single broken car is limiting the trougthput of all the "system", we cannot improve the system trying to go faster, it would makes us slower, so we need to subordinate to this constraint, so we slowdown first. So intuitively we already learned this 5 steps in the physical world, need to learn how to apply to the knowledge world. Note the use of the word "cause improvement", we can´t just improve systems directly, when we try more problems are created, but we can cause improvements, sometimes changing something not directly related, like for instance software development life cycle. My experience with organizations, teams and people, including my self is that when I try to push for a change I normally get the same amount of resistance that I´m pushing, or it doesn´t show resistance, it moves but after a while it returns to the same behavior or state it was before. So TOC says that these are undesired effects of some low level cause, and TOC normally relates this very source of a lot of udesired effects to a paradigm, or how we meassure the system, that is aligned to the paradigm in use, for instance if we meassure sucess as not deviation from planned. If really there are constraints in our brains, things we are hardwired, and we really have concrete limits, better listen to them and "subordinate" everything to this constraints, not try to work against them or ignore them as they are "real". So the way we work, communicate, plan, learn, execute or whatever has to be designed around this constraints, they must be "subordinated" to them, and not try to ignore them. If you ignore them you will get a lot of undesirable effects and you will be lost into a lot of fire figthing, things you created in first moment for not "subordinating" things to the constraints we have. For instance there are some evidence that our learning habilities are dramatically dropped when facts are separated in time and cause and effect are deal by different people, so our brains cannot capture cause and effect and we cannot relate one to another, so we simply don´t learn, even we reapeat again and again the same uneffective thing, at vomitum. That´s the only explannation possible for some organization that try waterfall once, fail and continue trying and failing, things are really far away in time so our brains cannot relate cause to effect and effectibly learn. The ones who experiment the undesirable effects are not the same as the ones that caused it, and things are separated in time, so no learning can happen. So having the people that defines what to do and the ones that produces together and the definition the realization close in time too will take care of this constraint and solve a lot of undesirable effects too. What do you think? Juan
Too bad the bonobos are dying out . . .
I've linked to it from here: http://danube.com/blog/michaeljames/aping_the_bonobos I'd like to see more studies of social behavior as applies to Agile development and teamwork. --mj
Thanks, Michael. I just taped one with Joseph Pelrine, but it will be a while before it's edited and written up :-)
My first review of the Linda Rising interview was too risqué or something, and had to be rewritten. I guess the topic does make people uncomfortable, which could be a clue that it's important. My other favorite was your interview with Ron Jeffries on Running Tested Features. I give out that link to my students. --mj
We're having technical difficulties with the layout of this page, for some mysterious reason. Please enjoy the video and bear with us on the layout issue while we investigate. Thanks. Deb
Problem fixed. Now, isn't that better? :-)
A new article by I. Drobiazko and R. Zubairov introduces v. 5 of the Apache Tapestry component-oriented web framework. The tutorial shows how to create a component and covers IoC in Tapestry and Ajax.
In this interview, Burton Group consultant Pete Lacey talks to Stefan Tilkov about his disillusionment with SOAP, his opinion on REST, and addresses some of the perceived shortcomings REST vs. WS-*.
Jay Fields presents his concept of Business Natural Languages - a type of Domain Specific Languages geared towards being readable by domain experts.
Adoption and interest for Distributed Version Control Systems is constantly rising. We will introduce the concept of DVCS and have a look at 3 actors in the area: git, Mercurial and Bazaar.
Deborah Hartmann interviewed Segundo Velasquez about his experience as customer with an Agile team during the initial phase of software design of a product.
David Cooksey shows how to fine grained versioning to a ClickOnce deployment using an HttpHandler written with ASP.NET, making partial rollouts to a test audience much easier.
Windows workflow (WF) is an excellent framework for implementing business processes, but lacks support for human activities. This article describes a completely generic approach for changing this.
In this interview taken during OOPSLA 2007, Markus Voelter talks about the importance of documenting the software architecture, and gives some good and also bad examples on how it could be done.
9 comments
Reply