Enterprise Architect = Architecture Astronaut
Dave Heinemeir Hansson rips James McGovern's "Enterprise" land grab. Like my post on the subject, David recognizes this inertia for what it is:
So by Enterprise, Architect, and Enterprise Architect standards, this gent must be the top of the pop. Thus, allow me to make this perfectly clear: I would be as happy as a clam never to write a single line of software that guys like James McGovern found worthy of The Enterprise.
I'll second that - if you follow the lead of people like McGovern, expect to find higher costs, lower productivity, and later delievery times. But hey - you'll be part of the "in crowd", using "analyst approved techniques", so everyone will buy you a round when you go bankrupt. That's got to be worth something. I really like David's summary of the McGovern thesis:
With that out of the way, we're faced with a more serious problem. How do we fork the word enterprise? The capitalized version has obviously been hijacked by McGovern and his like-minded to mean something that is synonymous with hurt and pain and torment.
There's a better way - it's here and here.
Update: Not all analysts are stuck in the "Enterprise zone". The guys at Redmonk seem pretty well grounded.
Comments
Dogfood
[Isaac Gouy] March 20, 2006 12:10:26.000
Is VisualWorks product development based on a specific agile approach? Which?
Chicken and egg?
[ Troy Brumley] March 20, 2006 13:14:42.000
Comment by Troy Brumley
Isaac, a few points...
First, so called agile methods trace many of their roots back to the way Smalltalkers always do things, JUnit is a port of SUnit, and so on.
Second, while I can't speak for all of VisualWorks development, it is clear that parts of VisualWorks are developed using many agile principles. Sames, if you are reading, what's the Pollock/Panda test count? I would view c.l.s participation and the various mailing lists as a reasonable compromise to achieve the "on site customer."
Third, agile is as agile does. I see it as more of a philosophy of using "just enough process" for the problem at hand.
Fourth and finally, my group within Cincom, CiBA, which is developing new business products, takes an agile approach.
a specific agile approach? Which?
[Isaac Gouy] March 20, 2006 13:19:00.000
missing the point
[ Troy Brumley] March 20, 2006 15:32:10.000
Comment by Troy Brumley
Isaac, following a specific and strict agile approach seems to me to be the moral equivalent of an anarchist getting a permit to hold a protest.
My reading of agile/xp literature is to take what you want and what works, and move on. If pair programming doesn't or can't work for you and your people, move on.
not answering the question
[Isaac Gouy] March 20, 2006 16:02:15.000
What's so difficult about saying: No we don't follow XP or Scrum or ... use TDD, or yes we do follow XP or Scrum or ... use TDD?
"My reading of agile/xp literature is to take what you want and what works..."
That doesn't seem right. If we take nothing then can we really be agile/xp?
as I said
[ Troy Brumley] March 20, 2006 16:43:33.000
Comment by Troy Brumley
I can't really speak for VW engineering, I'm not in our Smalltalk group. Alan or Sames can speak to their TDDness, and others from the group can chime in, but I think that most of them are agile leaning.
From reading XP Explained (Beck), various websites, and discussions with Ron Jeffries and Joseph Pelrine, I get the consistent message that XP/Agile is not a Procrustean bed. For example, in my group we do TDD, have a high level of customer interaction, but we're not pairing or doing what I'll call externally visible continuous integration because we don't need it yet. I say we're agile.
I'm sure there's a continuum from no process through personal process/team process/agile up to some sort of rigid "process nazi" kind of process that will earn someone an ISO 9xxx rating, but I think there's a whole range between "no process/chaos" and "infinite process/ossification", and somewhere in there lies agility.
can't really speak for
[Isaac Gouy] March 20, 2006 17:11:05.000
"I can't really speak for VW engineering, I'm not in our Smalltalk group.
Maybe there's someone else who can?
When James writes "There's a better way" and links the Agile Manifesto with Cincom, it shouldn't be too surprising when someone asks about the specifics.
(iirc previously I asked whether BottomFeeder development was based on TDD.)
Pragmatic Programming
[Giovanni Corriga] March 20, 2006 17:44:13.000
Isaac, you don't have to use one of the known approaches to be agile. It's enough to follow the values and principles contained in the Agile Manifesto. The pragmatic programmers (Dave Thomas and Andy Hunt) don't really have a methodology, but they signed the manifesto nonetheless.
save the sermons
[Isaac Gouy] March 20, 2006 18:38:44.000
Please save the sermons for someone debating what is or isn't Agile :-)
afaik VisualWorks product development is based on a specific agile approach - I simply asked an obvious (still unanswered) question.
agile requires agility
[ Troy Brumley] March 20, 2006 19:45:06.000
Comment by Troy Brumley
In his original post, Jim (correctly, in my opinion) notes that development is easier if you follow an agile methodology in Smalltalk. However, you can be agile in any langauge if you approach things in an flexible manner. Enterprise thinking seems to rely on fixed, inflexible processes and tools that happen to satisfy some "check off" requirement on a list created by some "enterprise architect" luminary.
Jim has talked about BottomFeeder development many times on this blog, and I don't think it's a secret that the application itself was developed as an experiment by Jim and has followed no formal methodology. I've been teasing Jim about testcases for some time now :)
However, Jim has a relatively transparent process with pretty much "on site" customers. I'd be willing to call his process agile, if imperfect.
not answering the question
[Isaac Gouy] March 20, 2006 20:26:14.000
Ruby Stratospheric Closed Mindedness
[] March 22, 2006 6:30:26.000
Have you seen this post and comments?