Home > Archive > Software Engineering > September 2006 > Agile Adoption in Silicon Valley
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Agile Adoption in Silicon Valley
|
|
| bill turner 2006-08-13, 7:00 pm |
| Way back on 22.June.2006, I posted a message questioning how widely XP
(eXtreme Programming) had been adopted. You can see the original post
at
http://groups.google.com/group/comp...2c0a946df348c7.
Phlip responded that there had been some radio advertising in the
Valley s ing XP/Agile folk, and that the Valley was a bellweather
for industry trends. Shortly after that, I was between projects and
went to visit some people I know who live there and work in the field.
None had heard the advertisement to which Phlip referred, though I
don't doubt that it may have been broadcast (for what it is worth,
Phlip's statement regarding the ad was hearsay, he didn't claim to her
it himself).
Being both intrigued by our discussion, and the fact that the seventh
anniversary of the publication of Kent Beck's article in IEEE Software
introduced the world to XP, I thought I would do a little more
rigorous research. I am no scientiest, so take what follows with a
grain of salt. It is my belief that if XP and the Agile methods are
demonstratively superior, and if Silicon Valley is truly an industry
bellweather, then we should see significant penetration in the market.
I felt the most impartial way to assess this, and the easiest way for
a lay researcher, was to evaluate job postings. It is believed that
Agile practices are new and unique enough that if a shop had adopted
one of the Agile methodologies, the posting would mention the
methodology. Traditional software engineering methodologies, or a lack
of any methodology, is presumed when no methodology is mentioned.
I perused the postings of three job sites, concentrating specifically
on Silicon Valley. The three were www.bajobs.com (Bay Area Jobs),
http://sfbay.craigslist.org/sof/ (Craigslist), and
([url]http://ser.dice.com/jobsearch/gentwo/metrosearch.jsp?ma=1[/url] (Dice).
I always used java as one of my search terms. This, I felt, would be
the language area in which Agile methods would be most likely used and
the number of postings returned would yield greater statistical
significance. For obvious reasons I did not use COBOL. And, other than
C/C++, I didn't think any other language would produce enough
postings. I cannot say the specific day I did this research, but
believe, with a high level of confidence, that I did it on
6.July.2006. I did not use the search term XP. The results were too
ambiguous, returning results for words such as eXPerienced (my
emphasis), as well as the Windows XP operating system. The results of
my research are below. I'd like to hear what, if any, conclusions can
be drawn from this data. Critiques of my methodology are welcome, too,
but please offer suggestions for improving the survey, if you feel my
methodology is suspect.
Search Term: java
BAJOBS: 41
Craigslist: 709
Dice: 2016
Search Term: java "extreme programing"
BAJOBS: 1 - 2.44%
Craigslist: 15 - 2.12%
Dice: 17 - 0.84%
Search Term: java "test driven"
BAJOBS: 3 - 7.32%
Craigslist: 10 - 1.41%
Dice: 27 - 1.34%
Search Term: java "TDD"
BAJOBS: 0 - 0.00%
Craigslist: 1 - 0.14%
Dice: 2 - 00.10%
Search Term: java scrum
BAJOBS: 0 - 0.00%
Craigslist: 8 - 1.13%
Dice: 16 - 0.79%
Search Term: java "crystal clear"
BAJOBS: 0 - 0.00%
Craigslist: 1 - 0.14%
Dice: 1 - 0.05%
Search Term: java "dynamic systems development method"
BAJOBS: 0 - 0.00%
Craigslist: 0 - 0.00%
Dice: 0 - 0.00%
Search Term: java "feature driven development"
BAJOBS: 0 - 0.00%
Craigslist: 0 - 0.00%
Dice: 0 - 0.00%
Search Term: java "FDD"
BAJOBS: 0 - 0.00%
Craigslist: 0 - 0.00%
Dice: 0 - 0.00%
Note that one BAJOBS posting asked for RUP, Extreme Programming, Test
Driven Development and Agile Model Driven Development knowledge or
experience. It is not clear from such a statement that an Agile
practice was adopted. It was not included in the counts.
These numbers do not show much penetration, especially if one throws
out the BAJOBS outlier for "test driven" (and, it should be considered
a suspect value based upon the small sample). Even if all the postings
that mentioned one of the above Agile methods were counted, the
percentage of jobs mentioning them would still be exceedingly small.
After seven years of books, articles and conferences, this is
surprising.
In conclusion, it seems the Valley does not believe there is enough
payback to broadly adopt Agile methods, or that there are other
unresolved concerns regarding its use.
Bill Turner
"Everyone is entitled to their own opinion, but not their own facts."
- Senator Daniel Patrick Moynihan
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
|
| bill turner wrote:
> Phlip responded that there had been some radio advertising in the
> Valley sing XP/Agile folk, and that the Valley was a bellweather
> for industry trends. Shortly after that, I was between projects and
> went to visit some people I know who live there and work in the field.
> None had heard the advertisement to which Phlip referred, though I
> don't doubt that it may have been broadcast (for what it is worth,
> Phlip's statement regarding the ad was hearsay, he didn't claim to her
> it himself).
Confession: KFOG runs web-only advertisements in their station breaks on
their online streaming broadcast. I heard it there.
The point: Such ads must cost a similar amount of money, with the
expectation of reaching a more technocratic demographic. Disregarding the
listeners on other continents...
> These numbers do not show much penetration
Yup. Then the fun starts when you interview and need to reveal your TDD
chops to compete. If a shop gives me a programming test, I'm set. If not,
then simply denouncing Debugger-Driven Development can sound too much like
idle USENET zealotry.
However, shops that practice pure XP often recruit directly in the
community, the way books like /What Color is your Parachute/ say is better
than job listings.
XP is probably now in the same position as Linux was 8 years ago, as OO was
20 years ago. It is now crossing from the early-adopter curve to the
emerging technology curve. And those technologies, at that time, probably
did not register prominently in the job listings. And the XP mailing list
doesn't ring with multiple wails "where are the jobs doing this?"
Next, thought-leaders like Google, Microsoft, Sun, Time-Warner, etc. are
starting to use it. The same as Linux 8 years ago or OO 20 years ago, for
similar companies.
> In conclusion, it seems the Valley does not believe there is enough
> payback to broadly adopt Agile methods, or that there are other
> unresolved concerns regarding its use.
I really doubt any of the Agile consultants who work the Valley would allow
you to connect your survey to that conclusion.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
|
| bill turner wrote:
> Search Term: java "TDD"
> BAJOBS: 0 - 0.00%
> Craigslist: 1 - 0.14%
> Dice: 2 - 00.10%
Here's a little survey for you. Divide the world's software jobs into two
camps - the Code-and-Fixers, and the Declared Processes. No matter what
process is on top, everyone knows most shops will merrily Code-and-Fix to
the wee hours.
Within the Declared Process job listings, using your "Java" search term as
the sea anchor, we get this:
__Hits__ __Google Terms__
44,800,000 java careers
26,700 java careers "design by contract"
30,300 java careers "dbc"
188,000 java careers tdd
1,850,000 java careers "UML"
6,210,000 java careers XP (could be WinXP!)
168,000 java careers "extreme programming"
152,000 java careers "scrum"
248,000 java careers "spiral"
203,000 java careers "test driven"
207,000 java careers "rup"
That leads to a new question: What search term do we use to detect the
non-Agile but non-Code-and-Fix citations? Note that RUP and Spiral can
qualify...
BTW the same survey without the "java careers" part will place Extreme
Programming at the top of the list. Admittedly, this is the rate at which
people add pages to the 'net about XP, not the rate they actually use it.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| bill turner 2006-08-14, 9:59 pm |
| Phlip wrote:
> bill turner wrote:
>
>
> Here's a little survey for you. Divide the world's software jobs into two
> camps - the Code-and-Fixers, and the Declared Processes. No matter what
> process is on top, everyone knows most shops will merrily Code-and-Fix to
> the wee hours.
>
> Within the Declared Process job listings, using your "Java" search term as
> the sea anchor, we get this:
>
> __Hits__ __Google Terms__
> 44,800,000 java careers
> 26,700 java careers "design by contract"
> 30,300 java careers "dbc"
> 188,000 java careers tdd
> 1,850,000 java careers "UML"
> 6,210,000 java careers XP (could be WinXP!)
> 168,000 java careers "extreme programming"
> 152,000 java careers "scrum"
> 248,000 java careers "spiral"
> 203,000 java careers "test driven"
> 207,000 java careers "rup"
>
> That leads to a new question: What search term do we use to detect the
> non-Agile but non-Code-and-Fix citations? Note that RUP and Spiral can
> qualify...
>
> BTW the same survey without the "java careers" part will place Extreme
> Programming at the top of the list. Admittedly, this is the rate at which
> people add pages to the 'net about XP, not the rate they actually use it.
>
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
Certainly most shops will claim to have process when in fact they do
not. There is no easy way to differentiate from the code-and-fix shops
and those that use non-Agile methods that I can see. What terms does
one use? RUP? RAD? Spiral? My belief, though, is that these will not
even be listed in most job descriptions because if used, they are part
of the expected knowledge set.
You make a valid point that Agile community may do most of its
recruiting from within the community as in What Color Is Your
Parachute. However, the lack of a broader advertising base leads to the
conclusion that the community is insular and small.
You seem to agree that here that there is not widespread adoption of
Agile practices yet.
I do not agree with your linux adoption analogy. The adoption of
unsupported (kind of) open source OS seemed quite risky. Adopting any
development methodology would seem far less risky to the executive set.
The analogy to the shift to OO seems more apt. Both are paradigm shifts
to what came before. For the most part I would say that XP is the
smaller shift, but there are some pretty big leaps of faith for those
who are comfortable with more traditional approaches.
One must not forget, too, that this discussion leaves out the COBOL
world, the last of which I knew was still the most widely used
principal software language. I mean, more developers use it than any
other language. My reference to that info is old, so that may no longer
be true. But, it is still large. Most COBOL developers would still be
using Structured techniques, which demonstrates that those tools were
not so horrible, just not the best tool to use for development using
java, or for many of types of products being built today.
| |
| S Perryman 2006-08-14, 9:59 pm |
| "bill turner" <google@changent.com> wrote in message
news:1155564864.374586.77610@b28g2000cwb.googlegroups.com...
> Certainly most shops will claim to have process when in fact they do
> not. There is no easy way to differentiate from the code-and-fix shops
> and those that use non-Agile methods that I can see. What terms does
> one use? RUP? RAD? Spiral? My belief, though, is that these will not
> even be listed in most job descriptions because if used, they are part
> of the expected knowledge set.
Of the two 'methodologies' presented so far, yours has greater credence.
Using "FDD" as a search term found nothing. As would terms such as
"design by contract" (which contrasts to the mention of the terms on the
wider Internet) .
> You make a valid point that Agile community may do most of its
> recruiting from within the community as in What Color Is Your
> Parachute. However, the lack of a broader advertising base leads to the
> conclusion that the community is insular and small.
> You seem to agree that here that there is not widespread adoption of
> Agile practices yet.
> I do not agree with your linux adoption analogy. The adoption of
> unsupported (kind of) open source OS seemed quite risky. Adopting any
> development methodology would seem far less risky to the executive set.
Even with Linux coming from a Unix lineage (with Unix having been a long-
proven industry component) , the risk was still high.
But change of development method can be risky.
How much lower (in orders of magnitude) would you say the risk was
compared to a move of OS from a Unix to Linux ??
> The analogy to the shift to OO seems more apt. Both are paradigm shifts
> to what came before. For the most part I would say that XP is the
> smaller shift, but there are some pretty big leaps of faith for those
> who are comfortable with more traditional approaches.
The move to OO was a very big shift for most companies.
> One must not forget, too, that this discussion leaves out the COBOL
> world, the last of which I knew was still the most widely used
> principal software language. I mean, more developers use it than any
> other language. My reference to that info is old, so that may no longer
> be true. But, it is still large. Most COBOL developers would still be
> using Structured techniques, which demonstrates that those tools were
> not so horrible, just not the best tool to use for development using
> java, or for many of types of products being built today.
The first successful OO project that I saw in industry was using structured
analysis techniques. The first failure was for a company where someone
tried to impose "evolutionary design" + no std OO method + C++ on a
client that was already churning out similar systems quite nicely using
structured techniques.
Regards,
Steven Perryman
| |
| Krasicki@gmail.com 2006-08-15, 4:00 am |
| > In conclusion, it seems the Valley does not believe there is enough
> payback to broadly adopt Agile methods, or that there are other
> unresolved concerns regarding its use.
>
> Bill Turner
>
Bill,
I think what you're documenting is the reality of the situation. I
work in New England and there is always chatter about these
technologies here and there but mostly empty salutes to relatively
meaningless jargon.
RUP is a common interview topic - usually as a free tutorial dialogue
so that the interviewer learns some of the lingo. In house, occasional
lip-service is paid to these things and virtually no follow-through.
I've been in the business for twenty-five years and I'm running into
shops that run bare-bones more than agile. And incoherently.
Sometimes there are no version control systems in place or they are
incorrectly used. Obfuscating code and development practice is being
revived as a job security measure.
In other cases, unwitting software architects demand that a very
specific pattern is used to implement a solution. Upon inspection the
pattern may not fit but to save face the implementation team has to use
something else but pretend the pattern is the same.
I recently ran across a development position ad that announced that
"Some agile techniques are in use". That could mean they test the
code.
I had this discussion recently with an IBM consultant who sees a fair
share of IT shops and he said, "All I have to do is hear that they're
using Agile development and I know I'm walking into a mess."
My recent experience leads me to believe that the software development
profession in general is in the dumps for a variety of reasons having
nothing to do with XP or Agile advocates. I think primary among these
reasons is post-modern programming tools and practice.
XP and Agile are cyphers for bottom-up software design paradigms.
Today, that bottom-up phenomenon incorporates global influences, exotic
programming zealotries, and project integration that resemble Rube
Goldberg contraptions. This cacophony of implementation activity defies
a uniform and consistent methodology. The industry offers no job
security beyond quarterly business cycles and therefore the end
sanctifies the means. Nobody cares *how* it got done, only that it did
get done.
To me the mistake that's always been made is to package these
bare-bones, resource starved efforts as examples of streamlined
software development methodologies. It too often sounds as though a
heroic group of people who capsized at sea manage to get to shore
half-dead to discover that the lifeguards were busy marketing their
desperate swimming activity as a new swimming mastery methodology.
Rather than payback, maybe the Valley is smart enough to recognize that
developing code remains a far more esoteric exercise than ever before
and formalizing the activity is largely thankless and hopeless.
Frank Krasicki
| |
|
|
"bill turner" <username@mn.rr.com> wrote in message
news:p3dvd2d8sulmqoo1816qhf09r1u9ooegdr@
4ax.com...
> For obvious reasons I did not use COBOL.
I am not sure what those obvious reasons would be other
than bias against the language. COBOL continues to be
the preferred language for a large number of data processing
shops.
COBOL has evolved. It now supports object-oriented
programming. The current version of the language is not
the old COBOL that many might remember from the early
1980's or 1970's. The same is true of Fortran, another
language that has continued to evolve quite nicely.
The only interesting thing about Java is that it updated the
notion of P-Code, an early Pascal concept, to something
they now call bytecode to run on a JVM that corresponds
to the engine that ran P-Code. As a language it is clunky,
overly-burreacratic, and retains some of the worst features
of its ancestral language, C.
Java does include some good ideas that contribute to the
advance of language design, particularly "interfaces." But,
as a language for software development, it falls short of
more elegant language designs such as Eiffel. It has been
the beneficiary of excessive media hype, and there is
reason for containing one's exuberance when choosing
a language on the basis of its publicity instead of doing
a careful analysis of the alternatives.
Richard Riehle
| |
| bill turner 2006-08-16, 9:59 pm |
|
adaworks@sbcglobal.net wrote:
> "bill turner" <username@mn.rr.com> wrote in message
> news:p3dvd2d8sulmqoo1816qhf09r1u9ooegdr@
4ax.com...
>
>
> I am not sure what those obvious reasons would be other
> than bias against the language. COBOL continues to be
> the preferred language for a large number of data processing
> shops.
>
I don't disagree with anything you've pointed out. COBOL is much
maligned. However, event though it now can do OO, almost none of the
COBOL people I am in touch with have ever used any of the concepts or
features.
Back in the 80's or early 90's COBOL II and COBOL 390 were becoming
quite widespread. I quickly and excitedly learned the new features and
began using them. No one I worked with in any of the shops I was in
picked up on any of the features unless they happenned upon my code.
Being that the OO features of COBOL are not widely adopted, it seems
unlikely that these shops and developers would migrate to Agile
methods. Nor am I aware of a COBUnit (I've thought of building one, but
have never been in a place where I could get my hands on OO COBOL).
Since java, with all of its detractions, is a widely used language, and
because it seems so closely linked to the Agile community, it seems
obvious that this would be the first choice.
> COBOL has evolved. It now supports object-oriented
> programming. The current version of the language is not
> the old COBOL that many might remember from the early
> 1980's or 1970's. The same is true of Fortran, another
> language that has continued to evolve quite nicely.
>
> The only interesting thing about Java is that it updated the
> notion of P-Code, an early Pascal concept, to something
> they now call bytecode to run on a JVM that corresponds
> to the engine that ran P-Code. As a language it is clunky,
> overly-burreacratic, and retains some of the worst features
> of its ancestral language, C.
>
> Java does include some good ideas that contribute to the
> advance of language design, particularly "interfaces." But,
> as a language for software development, it falls short of
> more elegant language designs such as Eiffel. It has been
> the beneficiary of excessive media hype, and there is
> reason for containing one's exuberance when choosing
> a language on the basis of its publicity instead of doing
> a careful analysis of the alternatives.
>
> Richard Riehle
| |
| bill turner 2006-08-16, 9:59 pm |
|
S Perryman wrote:
> "bill turner" <google@changent.com> wrote in message
> news:1155564864.374586.77610@b28g2000cwb.googlegroups.com...
>
>
> Of the two 'methodologies' presented so far, yours has greater credence.
> Using "FDD" as a search term found nothing. As would terms such as
> "design by contract" (which contrasts to the mention of the terms on the
> wider Internet) .
>
Well, I tend to agree! :-)
>
>
>
>
> Even with Linux coming from a Unix lineage (with Unix having been a long-
> proven industry component) , the risk was still high.
>
> But change of development method can be risky.
> How much lower (in orders of magnitude) would you say the risk was
> compared to a move of OS from a Unix to Linux ??
>From a CIO standpoint, the adoption of Linux would have presented much
greater risk. The only real risks one would have with a new methodology
would be that projects might be delivered late, buggy, or not having
fulfilled the requirements. Each new project would show varying degrees
of these issues. Also, the methodology would start with pilots (yes,
rolling out Linux would have started small, but for different reasons,
that wouldn't matter), so a lot of those risks could be assessed and
resolved. Rolling out Linux, on the other hand, was rolling out a black
box. Who knew what quality and stability there was? Also, if mission
critical apps were running and there server crashed and there is no one
you can call, heads would roll. No CIO in his right mind would want to
take such risks.
I cannot quantify the risk. I do not know how would even go about doing
so. But, being that one could risk millions of dollars, and the
existence of the corporation, and the other could only mean cost
overruns, then the risk would have to be large.
>
>
>
> The move to OO was a very big shift for most companies.
>
Yes. And many companies have not done it all, while others still retain
a large repository of legacy apps, which continue to be updated with
small to very large enhancements (essentially new projects).
>
>
> The first successful OO project that I saw in industry was using structured
> analysis techniques. The first failure was for a company where someone
> tried to impose "evolutionary design" + no std OO method + C++ on a
> client that was already churning out similar systems quite nicely using
> structured techniques.
>
I think I've heard you state this before. It is very interesting to me,
but, of course, I'll never see what was done.
Many years ago, I, too, saw some interesting stuff done with good ol'
COBOL, things that mimicked OO to a much greater degree than many
people probably even realize could be done.
>
> Regards,
> Steven Perryman
| |
| S Perryman 2006-08-17, 3:59 am |
| "bill turner" <google@changent.com> wrote in message
news:1155773889.953804.318680@h48g2000cwc.googlegroups.com...
> S Perryman wrote:
[color=darkred]
[color=darkred]
> greater risk. The only real risks one would have with a new methodology
> would be that projects might be delivered late, buggy, or not having
> fulfilled the requirements. Each new project would show varying degrees
> of these issues. Also, the methodology would start with pilots (yes,
> rolling out Linux would have started small, but for different reasons,
> that wouldn't matter), so a lot of those risks could be assessed and
> resolved. Rolling out Linux, on the other hand, was rolling out a black
> box. Who knew what quality and stability there was? Also, if mission
> critical apps were running and there server crashed and there is no one
> you can call, heads would roll. No CIO in his right mind would want to
> take such risks.
> I cannot quantify the risk. I do not know how would even go about doing
> so. But, being that one could risk millions of dollars, and the
> existence of the corporation, and the other could only mean cost
> overruns, then the risk would have to be large
I was only asking in terms of, say, you believe change of development
method is perhaps 100 times less risky than changing target deployment
platform to new HW/OS.
[color=darkred]
> Yes. And many companies have not done it all, while others still retain
> a large repository of legacy apps, which continue to be updated with
> small to very large enhancements (essentially new projects).
Some of that "legacy" actually remains because OO cannot do it better
(as well as the usual issues such as cost of migration etc) .
BT> Most COBOL developers would still be
BT> using Structured techniques, which demonstrates that those tools were
BT> not so horrible, just not the best tool to use for development using
BT> java, or for many of types of products being built today.
[color=darkred]
> I think I've heard you state this before. It is very interesting to me,
> but, of course, I'll never see what was done.
All the OO-related buzzwords consuming a client employee beyond common
sense and the limits of his OO expertise (which wasn't all that) . Among
other things.
Regards,
Steven Perryman
| |
|
|
"bill turner" <google@changent.com> wrote in message
news:1155564864.374586.77610@b28g2000cwb.googlegroups.com...
> Most COBOL developers would still be
> using Structured techniques, which demonstrates that those tools were
> not so horrible, just not the best tool to use for development using
> java, or for many of types of products being built today.
>
With the advent of the ANSI-1985 COBOL standard (a pallid
version of which IBM called COBOL II), a lot of defects in the
original language design were corrected. Also, one of the most
powerful constructs of any language found its way into the new
standard, a construct that is difficult to emulate as elegantly with
any existing OOP language: EVALUATE.
Without going into detail, the EVALUATE statement bridges the
gap between users designer/developer by simplifying the conditional
aspects of a program. A very large percentage of programming
errors are a consequence of the complexity of conditional statements.
Sometimes those conditional statements are incorrectly stated by the
user. Sometimes they are misinterpreted by the designer. EVALUATE
helps the user, the designer, and the programmer reduce the problem
of "linguistic discontinuity." I have an article in Software Engineering
Notes (ACM SigSoft publication) about Linguistic Discontinuity for
anyone who might be interested in its implications in software.
Original COBOL was problematic because it depended entirely
on global data. Even later versions that allowed CALL depended
on call-by-reference only. That was fixed with ANSI-85 COBOL.
There were many other improvements to the language at that time. Yet
I recall many COBOL programmers asking, "Why would anyone want
to have _name-the-feature-not-understood-here_. For example, the
standard added an in-line iteration capability (PERFORM ... END-PERFORM)
and experienced COBOL programmers had no idea why it was useful.
The benefits of these improvements began to become evident when new,
freshly minted programmers entered the workplace and began to use
them. Eventually, some of the old-timers noticed their usefulness (after
much grousing about these "upstarts" writing obscure code) and now,
in many large COBOL shops, the programs are better structured, more
readable, more modular, and more easily "maintained."
It will require another influx of programmers from academia and elsewhere
before the capabilities of OO COBOL are fully realized. However, that
will happen, and COBOL will continue to evolve.
At present, OO COBOL is still a more effective language for business data
processing applications than C++, Java, or most other alternatives. The
fact that so many people outside the COBOL world don't know about this
is not an indication that COBOL is out-of-date.
As for incremental-iterative development, COBOL, in its current form, is
as useful a tool for that approach as any other language.
Disclaimer. I am not currently in the world of COBOL. I do keep up on
the goings on in that world because of my role as a professor of computer
science. One of the courses I teach is comparative programming languages
and language design. One thing I have noticed is that a language must continue
to evolve, or die. Languages that have evolved well include COBOL, Fortran,
Ada, and Java (not a complete list). I don't particularly care for the way
C++ and PL/I have evolved, but realize that many people disagree with me,
even a fair number of my students.
Richard Riehle
| |
| gds@best.cut.here.com 2006-08-17, 7:00 pm |
| bill turner <username@mn.rr.com> wrote:
>In conclusion, it seems the Valley does not believe there is enough
>payback to broadly adopt Agile methods, or that there are other
>unresolved concerns regarding its use.
You may find http://www.christiansepulveda.com/agileblog/
interesting.
| |
|
| gds wrote:
> bill turner wrote:
>
> You may find http://www.christiansepulveda.com/agileblog/
> interesting.
What is its Silicon Valley angle? The latest article just says that a
software project must align itself with business needs or perish.
We should hope that's not up for debate!
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
|
| > gds wrote:
>
>
>
> What is its Silicon Valley angle? The latest article just says that a
> software project must align itself with business needs or perish.
Sorry - I just found it:
"One of my former clients (when I was a consultant) ... feels that their
agile adoption was a key facilitator of their IPO last year. I also know
some very large, high profile, Bay Area web companies who are adopting agile
software development and see it as necessary to remain competitive."
The IPO angle is important, too. In my personal and anecdotal experience,
Venture Capitalists are starting to ask for XP by name, specifically because
they are tired of dropping their money into a blender set to "liquify".
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| bill turner 2006-08-18, 6:59 pm |
| On Thu, 17 Aug 2006 21:00:30 GMT, gds@best.cut.here.com wrote:
>http://www.christiansepulveda.com/agileblog/
Was there something in particulary you were suggesting I read?
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
| bill turner 2006-08-18, 6:59 pm |
| On Thu, 17 Aug 2006 21:15:54 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:
>
>Sorry - I just found it:
>
>"One of my former clients (when I was a consultant) ... feels that their
>agile adoption was a key facilitator of their IPO last year. I also know
>some very large, high profile, Bay Area web companies who are adopting agile
>software development and see it as necessary to remain competitive."
>
>The IPO angle is important, too. In my personal and anecdotal experience,
>Venture Capitalists are starting to ask for XP by name, specifically because
>they are tired of dropping their money into a blender set to "liquify".
Ultimately, this is just anecdotal evidence, not the empirical
evidence on which I based my original post. If there was some way you
could demonstrate the percentages of VC capital going to startups that
was dependent upon the use of an Agile methodology, I would be more
interested.
While I'd like to think differently, I don't truly believe that just
because someone has a lot of money means that they are any more
intelligent. One only need look at things like RJR Nabisco or AOL Time
Warner. Nor do I believe that VC's are any less prone to fad surfing
than board room's in general. But, these are entirely different
subjects.
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
| bill turner 2006-08-22, 7:59 am |
| On Fri, 18 Aug 2006 23:36:37 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:
>bill turner wrote:
>
>
>Gee. It's almost like I didn't already say "anecdotal".
I stand corrected.
>
>
>If all the VCs just ... jumped off a cliff, would you do it too?
What? Not sure what you mean by this? I think you are saying that if
all VC's are requiring something, then it its a good idea. Well, let
alone that is not necessarily the case at all, my point was that I
don't know, nor have you provided, any information regarding the
amount of fundings predicated on the use of Agile methods and how it
has grown over time. It would be interesting to see. I'd like to see
the numbers in two ways: 1) the number of fundings to separate
enterprises predicated on the use of Agile development, and 2) the
amount of dollars predicated on the use of Agile development.
While I have nothing to base it upon, my guess is that VC money is
rarely predicated upon the software development methodology used. The
VC analysts would likely be more interested in the business model,
financing, marketing and pricing strategies, potential market, target
markets, cost control and the ability to obtain identified goals. Even
if the firm is producing a software product, all the normal business
concerns are what would be deemed critical. The methodology used to
development the software would likely be considered superfluous as
long as the costs were controlled and targets were met. Now, the VC
analyst would likely be concerned if a shop was not using widely
accepted best practices. But I am not even sure about that. Having
been in a VC funded startup, no real analysis was ever done in our
area, and we were producing a software product. At best the CIO was
asked questions. How closely his responses reflected reality is
questionable. But I gaurantee that he knew little of what was
happenning on the ground, how closely we were following methodology
and our success with it, nor many other things.
FWIW, when our company looked at merging with a competitor, there was
much more due diligence done in regards to our IT department. This is
likely because it was necessary to determine how costly it would be to
merge.
>
>You might instead try a few pilot projects, the way most adopters of Agile
>technique were converted.
>
>But what, again, was the problem with the ones you already tried? I suspect
>they were power grabs. That doesn't work.
I don't understand this at all. What are you talking about? How is
this related to my original post or to anything said before? I am
truly do not understand the context.
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
|
| bill turner wrote:
> While I have nothing to base it upon, my guess is that VC money is
> rarely predicated upon the software development methodology used.
We have learned so far that the demand "show the numbers" won't work for the
Agile percent of Silicon Valley, so I won't try to use it for VCs.
I can personally recall money lenders specifically requesting RUP,
(Waterfall-style) CMM, XP, XP, and several more situations that indeed
specified no methodology.
> The
> VC analysts would likely be more interested in the business model,
> financing, marketing and pricing strategies, potential market, target
> markets, cost control and the ability to obtain identified goals. Even
> if the firm is producing a software product, all the normal business
> concerns are what would be deemed critical. The methodology used to
> development the software would likely be considered superfluous as
> long as the costs were controlled and targets were met.
Now the problem is the VCs belief in how software development works. If they
indeed believe that a team must run for a quarter without showing any
results (in running, bug-free, high-value code), then they might look to
other indicators. They might demand inflated market forecasts, to offset the
huge risk that such black-out development causes.
If they instead required short iterations, they could incubate small
start-ups, essentially in-house, and then use the live software as their
feasibility study.
> Now, the VC
> analyst would likely be concerned if a shop was not using widely
> accepted best practices. But I am not even sure about that. Having
> been in a VC funded startup, no real analysis was ever done in our
> area, and we were producing a software product. At best the CIO was
> asked questions. How closely his responses reflected reality is
> questionable. But I gaurantee that he knew little of what was
> happenning on the ground, how closely we were following methodology
> and our success with it, nor many other things.
It might be possible for us to agree that situation was not ideal.
> I don't understand this at all. What are you talking about? How is
> this related to my original post or to anything said before? I am
> truly do not understand the context.
Among people who question XP, the three categories are those who have seen
it working well, those who had unfortunate experiences with it, and those
who have not used it yet.
The first group is obviously more likely to be convinced.
I suspect you are from the middle group.
The demand "prove it works" is laudable in some fields, but software
methodologies aren't among them. So if you s some number (such as 15% of
all Silicon Valley firms use XP!) then none are available. No such numbers
would have statistical relevance.
So we are back to the question whether you would like to try the experiment
on yourself. You could then correlate your experiences with others'.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
|
| Phlip wrote:
> I can personally recall money lenders specifically requesting RUP,
> (Waterfall-style) CMM, XP, XP, and several more situations that indeed
> specified no methodology.
I forgot to mention one went for the Microsoft Certified Software Provider
whatever plaque. That one turned out to be a regular nightmare!
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Scott Frye 2006-08-23, 8:00 am |
|
Phlip wrote:
> Among people who question XP, the three categories are those who have seen
> it working well, those who had unfortunate experiences with it, and those
> who have not used it yet.
>
> The first group is obviously more likely to be convinced.
>
> I suspect you are from the middle group.
>
hmm...very disturbing. Your seem to be playing down the importance of
the those in the first group that have seen it work well but are not
convinced its a good methodology.
And you have excluded the group of those that have seen it applied
properly (therefore not and unfortunate experience) but don't consider
the outcome a success or desirable and and therefore can't fall into
category one or two as you describe.
But, such blindess is often seen in zealots.
-Scott Frye
-------------------------------------------------
"The person who says it cannot be done should not interrupt the person
doing it."
Chinese Proverb.
-------------------------------------------------
| |
| bill turner 2006-08-24, 7:00 pm |
| On Tue, 22 Aug 2006 17:49:26 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:
>bill turner wrote:
>
>
>We have learned so far that the demand "show the numbers" won't work for the
>Agile percent of Silicon Valley, so I won't try to use it for VCs.
What do you mean by this? That people in the Agile community reject
scientific methods? That the Agile community rejects numbers when they
are not flattering to Agile practices? This seems to me what you are
saying, but I don't believe that is what you meant.
>
>I can personally recall money lenders specifically requesting RUP,
>(Waterfall-style) CMM, XP, XP, and several more situations that indeed
>specified no methodology.
I think you would agree that this is likely not a representative
sample. What is the point?
>
>
>Now the problem is the VCs belief in how software development works. If they
>indeed believe that a team must run for a quarter without showing any
>results (in running, bug-free, high-value code), then they might look to
>other indicators. They might demand inflated market forecasts, to offset the
>huge risk that such black-out development causes.
>
I've never said the VC's were the problem, nor do I think that. I just
proposed a method for determining the extent of Agile adoption in the
valley. Since neither you nor I have any numbers related to the VC
demands, this provides no real value.
As for my questioning what VC's demand, I can only conjecture for the
most part and thought I made that clear. I've worked in one VC funded
startup, as stated previously, and, as stated previously, they paid
scant attention to development practices. My experience with the
merger did care more about the practices, but this was due more to the
cost of integration of the two organizations. It was not predicated
upon any particular methodology.
I do, in fact, believe my suspicions about what VC's require in a
startup is fairly accurate. Yes, there may be some that do demand
specific practices. It is far more likely that the other things, and
the reality of the other things as verified by the VC analysts, is
much more a determining factor in any funding provided.
To be honest, I am not sure why you brought up VC funding in the first
place. Is it to obscure the fact that the numbers produced are not
favorable to your position? I would hope that is not the case. Do you
have any other suggestions that mere lay people like you and I could
determine the level of penetration?
>If they instead required short iterations, they could incubate small
>start-ups, essentially in-house, and then use the live software as their
>feasibility study.
>
>
>It might be possible for us to agree that situation was not ideal.
>
>
>Among people who question XP, the three categories are those who have seen
>it working well, those who had unfortunate experiences with it, and those
>who have not used it yet.
>
>The first group is obviously more likely to be convinced.
>
>I suspect you are from the middle group.
I imagine that there could be further segmentation. Which group I am
from is irrelevant to the topic. My interest in determining the rate
of adoption was as an indicator to the value of the practices.
..
>
>The demand "prove it works" is laudable in some fields, but software
>methodologies aren't among them.
Why not? That is what an awful lot of valuable academic research has
done over the years. I don't understand the wariness you display to
subjecting methodologies to testing. If it cannot be tested, how can
it be improved? You wouldn't do that with code, why should it be
different with methodology? Yes, testing a methodology is difficult,
but it is not impossible.
>So if you s some number (such as 15% of
>all Silicon Valley firms use XP!) then none are available. No such numbers
>would have statistical relevance.
Why wouldn't such numbers have statistical relevance? If a technique
or practice had high rewards relative to the risks, I would think that
rapid adoption would be expected, and especially in area that
represents that heart, the leading edge, of the industry.
>
>So we are back to the question whether you would like to try the experiment
>on yourself. You could then correlate your experiences with others'.
I experiment on myself all the time. :-) Why, pray tell, does it come
back to this?
You might be pretty surprised by the practices I employ. In fact, you
might be surprised to know that within reach I have Beck's "Test
Driven Development", Fowler's "Refactoring", and Rainsberger's "JUnit
Recipes", and I have several other XP books in my library.
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
| |
|
| bill turner wrote:
>
> What do you mean by this? That people in the Agile community reject
> scientific methods? That the Agile community rejects numbers when they
> are not flattering to Agile practices? This seems to me what you are
> saying, but I don't believe that is what you meant.
Specifically, I don't think there's a survey out there for Agile adoption in
Silicon Valley.
Generally, all software engineering cannot use the same metrics that we can
use for, say, killing rats with aspartame. If we can't do true controlled
experiments, then pretending we do just causes more trouble.
>
> I think you would agree that this is likely not a representative
> sample. What is the point?
That our anecdotal evidence is more useful - when we are talking to each
other - than any number hallowed by an Authority, and graven in stone.
> As for my questioning what VC's demand, I can only conjecture for the
> most part and thought I made that clear. I've worked in one VC funded
> startup, as stated previously, and, as stated previously, they paid
> scant attention to development practices. My experience with the
> merger did care more about the practices, but this was due more to the
> cost of integration of the two organizations. It was not predicated
> upon any particular methodology.
Thanks for sharing. Both situations should have instead asked their teams to
return value more often.
> To be honest, I am not sure why you brought up VC funding in the first
> place. Is it to obscure the fact that the numbers produced are not
> favorable to your position?
Some numbers produced were quite favorable, but that's not the reason.
The reason is, in a murky situation, a good way to get a signal is to go
upstream from the effect, to the cause. The capital system - VCs, in-house
budgeting, etc. - is upstream from development. So it's also a good place to
collect anecdotal numbers.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
|
| bill, et al:
http://uk.theinquirer.net/?article=34128
I just had to cite that - it's too funny.
It's a survey of executives who say they would rather use habaneros eyedrops
than open a software shop in Silicon Valley. So I guess this refutes any
refutation that attempts to hold SV up as a paragon! ;-)
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
|
|
|
|
|