|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
.NET architecture
.NET architecture
.NET architecture
|
Messages: 5
Messages: 5
Messages: 5
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Is Agile Programming a Stepping Strone to Software Factories?
All,
I am presenting on this topic at the 'Better Software Conference 2005' in San Fran. I wanted to see what your feedback was.
I am making the claim (as I do in my upcoming book) that Agile Processes, with their roots in Lean Manufacturing (so well spelled out bt the Poppendiecks), is a fundamental stepping stone to Software Factories.
My claim is that by 'delaying decisions to the last moment', eliminating waste, etc. are all elements which psychologically and practically will prepare an organization for the move to Factories and Product Line concepts as these will provide the benefits of Agile, while operating at a much higher level of abstraction.
I believe my talk can only be greatly improved by the feedback you all provide, as this is the forum with by far the strongest readers I believe, and the discussion we have on this idea and this post. From my studies at Columbia to my 15 years as a practitioner, I believe this in my bones to be true.
Also, if you are intersted in the Software Factory movement in VS 2005 come over to GotDotNet and join our almost 100 member user group here:
http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=15536008-e1a7-4c7f-b7c1-dc148491e2c6
Kind Regards,
Damon Carr, CEO and Chief Technologist
agilefactor
www.agilefactor.com
|
|
|
Message #174126
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I think you need to be pragmatic.
Agile development in my view is not prescriptive and many organisations have embraced their own style to fit with their culture which has been an evolving process that is in itself improving with every project as more is learnt. For instance many organisations find some Agile Development techniques such as pair development contentious and therefore are not adopted, whilst many of the practices of Software Factories are far less contentious and therefore easier to adopt.
The reason for this is most I.T management is extremely formalist in thinking and Agile Development being essential a hermeneutic practice can seem too revolutionary for the tastes of many. Being firmly in the Hermeneutic camp I am a strong believer in Agile Development and if the choice was up to me I would throw caution to the wind and fully adopt, sadly this strategy is to risky for many and I fear my views are not yet mainstream.
Also to consider the relationship between Agile Development and Software Factories is undeniable, but are we saying that the new MSF Formal couldn’t be used in a Software Factory?
So in answer to your question I believe many practices of Software Factories will be easier to adopt than many practices of Agile Development, so it would be easier to move ahead with building the Software Factory without fully adopting Agile Development. So no, Agile Development isn’t completely a stepping stone to Software Factories, we have to be pragmatic.
Originally posted at: http://geekswithblogs.net/sabotsshell/archive/2005/06/12/43162.aspx
|
|
|
Message #174140
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is Agile Programming a Stepping Strone to Software Factories?
Your claim falls short when you suggest that software factories will allow software development to evolve toward operating at a much higher level of abstraction over agile development while maintaining agile development’s benefits.
Agile is necessarily and explicitly low-level and concrete because it seeks to fill in the missing methodological guidance that drives toward the recognition and formalization of low-level design along the lines of how Jack Reeves and Martin Fowler have defined low-level design. Unless you can remove the need for low-level design through a fundamental software development paradigm shift, then you can’t really say that practices like TDD are stops along the way to software factories. In fact, some agile practices are at odds with some software factories practices.
I’ve yet to see anything in either Greenfield’s work or Clements’ work to suggest that either software factories or SPL is intended as an abstraction evolution on low-level design as much as it is an evolution on architecture and governance in the context of a disciplined reuse initiative.
Agile will deliver reusable bits, and software factories and SPL will provide a means to manage the artifacts and the product assembly manifests of families of products composed of these artifacts. Software factories won’t allow us to operate at a higher level of abstraction over agile development since they don’t entirely address the same problem set, and the one doesn’t de-necessitate the practices of the other for the practices that fall outside of the intersection of the practice sets.
Done with the appropriate level of rigor and discipline, agile development will improve the success of a software factories or SPL initiative in the same way that it improves the success of initiatives outside of software factories and SPL, but that’s really the limit of the relationship between agile and software factories and SPL. One tangentially improves the inputs of the other, but I don’t see anything that suggests that one supersedes the other from the perspective of either composition or abstraction.
I would also say that your suggestion that agile development has its roots in lean manufacturing is off-base. The Poppendiecks surfaced and communicated valuable parallels between lean manufacturing and agile development when they communicated their Lean Software Development ideas, but agile development no more comes from lean manufacturing than peanut butter comes from bread. Agile development and lean manufacturing respectively surface from values common to agility. They share common roots and therefore agile development and lean manufacturing express commonalities just as any siblings express the traits of their progenitors, even if those siblings are born in different years. Someone from Whole Foods Market might have beat the Poppendiecks to the punch with an analogy based on just-in-time inventory management, but that still wouldn’t make agile development rooted in the lean grocery business.
I think you’re beginning to reify some important ideas surrounding agile development and software factories, but I also think you run the risk of taking rather liberal license with the topics at hand if you pursue the notion of software factories allowing software development to evolve toward operating at a much higher level of abstraction than agile development. I think you also may risk your credibility with folks with a much deeper perspective of agile development than the perspective surfaced in the second wave of agile books that focused more on higher-level issues like management of agile development as the Poppendiecks’ work does.
Ultimately I don’t think you can substantiate your proposition unless you talk about agile development and software factories from incompatible levels of magnitude. It would be like comparing the size of the moon as seen through a telescope to this size of a grain of sand as seen in a microscope. They may appear to be the same size in the eyepieces of the respective optical devices you’re using, but any comparative discourses on the sizes of these bodies in reality would have to be done based on a more absolute measure. You would have to cut away practices like Test-Driven Development & Design and Continuous Integration (among others) from the agile development practice set before you arrived at something that you could draw inferences between.
I simply don’t see the evolutionary relationship between agile and software factories and SPL that you’re putting forth. Although I could see it if I limited my perspective of agile to what Lean Development talks about.
|
|
|
Message #176128
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Please Provide Evidence
Your claim falls short when you suggest that software factories will allow software development to evolve toward operating at a much higher level of abstraction over agile development while maintaining agile development’s benefits.
What do you base that comment on? What do you think we will loose from Agile? You are not performing an apples to apples comparison. Agile is a Dev process. Factories are a conceptual leap in abstraction with incredibly powerful tools to facilite it. You still need a process and Agile is it. That is why my book is called "Agile Software Factories".
Agile is necessarily and explicitly low-level and concrete because it seeks to fill in the missing methodological guidance that drives toward the recognition and formalization of low-level design along the lines of how Jack Reeves and Martin Fowler have defined low-level design.
It sounds like you are trying really hard to sound like you have a theoretical foundation and handle on this but what you just said doesn't make sense. Agile is about allowing dramatic change at any time with TDD and C.I. as your safety nets. TDD is not just low level design, it is also driving Service Oriented Architecture contracts.
Unless you can remove the need for low-level design through a fundamental software development paradigm shift, then you can’t really say that practices like TDD are stops along the way to software factories. In fact, some agile practices are at odds with some software factories practices.
Can you name some? The low level design happens in the construction of the factory and the consumers of the factory (the other developers) are hidden from the details for the most part.
I’ve yet to see anything in either Greenfield’s work or Clements’ work to suggest that either software factories or SPL is intended as an abstraction evolution on low-level design as much as it is an evolution on architecture and governance in the context of a disciplined reuse initiative.
It is absolutely an increase in abstraction evolution across the board. The low-level work comes in the implementation of the abstraction using vastly more powerful constructs like the DSL and the Guidance Automation Toolkit. I have been working with Keith Short since the I.E.F. tool from Texas Instruments and the concepts are not new, they are just now working.
Agile will deliver reusable bits,
It will? Agile is not a component driven process necessarilly....Do you mean Agile delivers incremental bits?
and software factories and SPL will provide a means to manage the artifacts and the product assembly manifests of families of products composed of these artifacts.
That is the core of my book, with a massive focus on Design Patterns and Refactoring to Patterns yes...
Software factories won’t allow us to operate at a higher level of abstraction over agile development since they don’t entirely address the same problem set, and the one doesn’t de-necessitate the practices of the other for the practices that fall outside of the intersection of the practice sets.
That is categorically incorrect. Software Factories BY DEFINITION allow us to operate at a higher level of abstraction then any Agile practice.
Agile is how I propose we BUILD the higher levels of abstraction using totally new tools.
What my book is about is applying Agile development process techniques in the development of the Software Factory deliverables. They are still very much applicable and as far as I know I am the first person to put in book format a development process for the creation of Factories. This is an apples to oranges discussion.
Factories do not describe a software dev process as much as a way to manage and deploy conceptual elements that STILL MUST BE CREATED. The difference is that these elements are unlike anything developers are today used to working with. UML is a far cry as are most components. However you still need to build the deliverables and using Agile process techniques (with my proprietary enhancements targeted to the unique needs of Factory deliverables) is what has created the buzz around the book.
For those not ready to go to factories, it just so happens the same process elements I introduce will produce tremendous rewards even if you are just doing Agile. So you can leverage the improvements today and when you go to factories you will already have the process framework in place to excell at building your factories.
Might I ask, where do you draw your conclusions you state with such conviction? I have both Academic (Master's level) and 15 years of practical application with over six years of dedicated research, data collection and field work. Have you focused your career on this as I have?
Kind Regards,
Damon Carr, CTO
agilefactor
Done with the appropriate level of rigor and discipline, agile development will improve the success of a software factories or SPL initiative in the same way that it improves the success of initiatives outside of software factories and SPL, but that’s really the limit of the relationship between agile and software factories and SPL. One tangentially improves the inputs of the other, but I don’t see anything that suggests that one supersedes the other from the perspective of either composition or abstraction.
I would also say that your suggestion that agile development has its roots in lean manufacturing is off-base. The Poppendiecks surfaced and communicated valuable parallels between lean manufacturing and agile development when they communicated their Lean Software Development ideas, but agile development no more comes from lean manufacturing than peanut butter comes from bread. Agile development and lean manufacturing respectively surface from values common to agility. They share common roots and therefore agile development and lean manufacturing express commonalities just as any siblings express the traits of their progenitors, even if those siblings are born in different years. Someone from Whole Foods Market might have beat the Poppendiecks to the punch with an analogy based on just-in-time inventory management, but that still wouldn’t make agile development rooted in the lean grocery business.
I think you’re beginning to reify some important ideas surrounding agile development and software factories, but I also think you run the risk of taking rather liberal license with the topics at hand if you pursue the notion of software factories allowing software development to evolve toward operating at a much higher level of abstraction than agile development. I think you also may risk your credibility with folks with a much deeper perspective of agile development than the perspective surfaced in the second wave of agile books that focused more on higher-level issues like management of agile development as the Poppendiecks’ work does.
Ultimately I don’t think you can substantiate your proposition unless you talk about agile development and software factories from incompatible levels of magnitude. It would be like comparing the size of the moon as seen through a telescope to this size of a grain of sand as seen in a microscope. They may appear to be the same size in the eyepieces of the respective optical devices you’re using, but any comparative discourses on the sizes of these bodies in reality would have to be done based on a more absolute measure. You would have to cut away practices like Test-Driven Development & Design and Continuous Integration (among others) from the agile development practice set before you arrived at something that you could draw inferences between.
I simply don’t see the evolutionary relationship between agile and software factories and SPL that you’re putting forth. Although I could see it if I limited my perspective of agile to what Lean Development talks about.
|
|
|
Message #184846
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Steping stine?
I don't thing you can say one methodilogy is best for any organization. Each methodoloty is right for the time span for which the methodology applies.
1. waterfall - years
2. spiral - months
3. weeks - agile
4/ days - extreme
Agile techniques drive the model because longer term plans and shorter term plans prove to be wrong.
User centric agile techneques are the success formula for sucsessful oreganizations that so not ignore the necessity of other methodologies where they apply.
They are stepping stones because they evolve into the becomming of the the long term statigies.
Jim
|
|
|
Message #189913
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yes but statistically....
If you had to say what was statistically the most likely Process for all Corporate Development the Agile family would be it. There is no other Process or Process Family that can claim the results that the Agile family can.
Most Software is very Similar
Most Projects engage in so much waste
Planning upfront we know is almost always waste
Statistically is what I was speaking to
Of course if I could analyze each company, each situation, then the majority would be Agile but NOT EVERY ONE definitely.
Damon Carr
|
|
|
|
Hot threads
Hot threads
Hot threads
|
More hot threads
More hot threads
More hot threads
|
|
Speaking at EclipseCon 2006, Java developer and independent consultant Madhu Siddalingaiah compared Microsoft's Visual Studio IDE to the open source development environment of Eclipse.
(32 comments,
last posted
December 29, 2007)
In this tech talk, Microsoft's Peter Provost talks about the design of the Composite UI Application Block and how the p&p team has led Microsoft in the adoption of Agile methodologies.
(0 comments,
last posted
April 17, 2006)
Chapter 4 of Framework Design Guidelines, titled "Type Design Guidelines," presents patterns that describe when and how to design classes, constructs and interfaces. In this chapter, Abrams and Cwalina divide types into four groups and discuss the do's and don'ts of type design.
(2 comments,
last posted
July 07, 2006)
Paul Ferrill caught up with prime open-source .NET applications driver Miguel De Icaza at Novell's BrainShare conference last week. They discussed the status of Windows Forms for Mono (it's coming along) and VB.NET for Mono (it looks like it's out).
(5 comments,
last posted
March 30, 2006)
In this tech talk, Microsoft Visual Studio architect Jack Greenfield discusses the company's approach to Domain-Specific Languages, or DSLs, and the part they play in software factories.
(0 comments,
last posted
March 15, 2006)
More hot threads »
|
|
