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
Posted by Amr Elssamadisy on Feb 05, 2008 09:00 PM
Damon Poole wrote recently that many of us maybe practicing Agile development without even realizing it:
The funny thing is that most shops are unconsciously flirting with Agile Development. They do a release on a regular basis which is very similar to what Agile teams do without even realizing it and then feel ashamed that they had to do it. Afterwards, they hope they won’t have to do another one.
When is it that most teams do this, even if they are not Agile?
I am speaking of maintenance releases, patches, and hotfixes. Forget for the moment that these are created out of necessity due to problems with “the big release” and that they are often done under intense pressure. Forget for the moment that sometimes you have to redo a hotfix with another hotfix. The need for the second hotfix is often found by the intense scrutiny that is in place during the aftermath of the first hotfix and due to the fact that the hotfix probably didn’t get the full spin cycle of the normal QA process.
This should sound familiar to every one of us, even if we don't practice Agile.... Funny - isn't it? The point that Damon made, that most of us feel guilty afterwards and don't want to do it again should also seem familiar. Why?
I believe that the reason that most shops drift towards and then away from Agile development is that it is the natural rhythm of software development and it is hard to resist it. The challenge is to sustain it. In order to sustain it, you need two things: understanding of Agile and conscious intent. Without conscious intent and the synchronizing signal of short iterations it is hard to notice the difference between being on the path and off the path unless you stay on the path for a while. The other problem is that while everybody in an organization might from time to time all be synchronized into an Agile rhythm by pure chance, the synchronizing signal of the project plan, habits, and entrenched process interferes with the natural rhythm. Thus, the natural rhythm doesn’t get a chance to take hold.
So the rhythm is one of the keys to successful Agile development - and it is exhausting. (It is also very effective.) This fits what others have reported about Agile software development. In Rhythms as Agile Diagnostics, this idea was inverted, suggesting that a way to know if you are on-track in your Agile development or not is to take a look at the major rhythms:
A healthy agile project has several typical rhythms such as releases, iterations, stand-up meetings, builds kicked off by continuous integration, and the red-green-red test cycle of a developer. These rhythms have healthy ranges (such as a stand up meeting lasting less than 15 minutes) and characteristics (such as that same stand up meeting not containing design discussions). When they fall out of these ranges or do not display the appropriate characteristics, they indicate that something is wrong with the agile process. As a doctor takes a patient's pulse or blood pressure reading to determine if the patient is ill, we take readings of our rhythms to let us know if something is wrong with our agile process. The rhythms, when off, sometimes need to be addressed directly, and in other cases point us towards areas of the process where we need to dig more deeply to find and correct the root cause of the problem.
Does this idea of rhythms and Agile development match your experience? Have you or your team practiced Agile without intending to do so? If you are already practicing Agile, or in the process of adopting a few practices, what rhythms are present?
IBM Agile Development eKit: Free Articles, Expert Q&A, Educational Resources
Fighter Jets and Agile Development at Lockheed Martin (Case study)
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
I have been thinking about this a lot, specifically when it came up on an article about whether the iteration was necessary. It really makes sense that in order to have everyone moving in one direction, "in lock step", there is a rhythm required. There are such things as irregular rhythms (for those of you that want a flexible iteration length/ feature iterations), but I am betting that even inside of those irregular rhythms you can find a regular rhythm, like the daily stand-up, that keeps everyone checked in with each other and on task towards the common goal. I just see the rhythms really as the key to why Agile seems to work, it is not the process, because we value the working software over the process, it is those oh so subtle rhythms. Tim Ferguson, xaware.org
I've seen highly advanced teams that have a great working relationships work without iterations, but they still have all of the other rhythms. For the rest of us mortals, the iteration works very well, and without it things start to trip up.
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.
2 comments
Reply