Interview with USA CIO Vivek Kundra
769 views
Skip to first unread message
DrQ
Sep 19, 2009, 1:13:55 PM9/19/09
to Guerrilla Capacity Planning
SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundra
http://bit.ly/1bv1LW
Agile software, rapid prototyping, cloud computing, . . . rather than
waiting for perfection, Kundra launches beta versions, expecting
improvements later. Gov 2.0 setting the pace for Corp. America IT?
http://bit.ly/1bv1LW
Agile software, rapid prototyping, cloud computing, . . . rather than
waiting for perfection, Kundra launches beta versions, expecting
improvements later. Gov 2.0 setting the pace for Corp. America IT?
rml...@gmail.com
Sep 22, 2009, 1:33:44 PM9/22/09
to Guerrilla Capacity Planning
I was at a company that still embraced the agile software model. I
have a negative impression of agile development for a number of
reasons.
1. Agile programming emphasizes programming over engineering. This
results in software that does not have clean interfaces and is
intertwined with other code. Of course, such code is difficult to
maintain, debug, and replace. Expensive code bloat is the consequence.
2. Agile programming emphasizes coding. The more code that a
programmer produces, the more productive he/she is. This emphasis on
production introduces unnecessary bugs. Studies show that for every
100 lines of code written by a good programmer, 2.7 to 3.2 bugs are
introduced. Many of these are edge cases and not detectable by
testing. The more code that is written, the more bugs that programmers
introduce unless they perform comprehensive function and unit testing;
unfortunately, this is a skill that is rarely taught. The consequences
are bizarre intermittent failures, Heissenbugs, and unpredictable
interactions and other undesirable side-effects.
3. Agile programming is inappropriate for product development where
companies will live with an architecture for a long time. It's better
to engineer an architecture and design clean interfaces than to crank
out code that will soon become problematic. The agile model may be
appropriate for making incremental changes to mature software
products.
4. Agile programming deemphasizes designing performance into products.
After all, the packages and libraries can be replaced in the future.
The problem is that the future never comes unless there is a crisis.
5. Agile programming never views a program or project as complete.
There's always room to tinker and add new levels of abstraction and
modify the mechanics of a program. Expenses around programming become
a sucking black hole.
6. Agile programming is a model that rewards software churn. It's a
great model for building fiefdoms in a corporation and employ busy
programmers; it's terrible for corporations who want to produce
maintainable stable quality products that will not incur high
overheads.
7. Agile programming deemphasizes quality. Deploying software that
works after a fashion "rather than waiting for perfection" introduces
a dangerous slippery slope. I doubt that many managers can define
"acceptable imperfection." Quality should be job one. Apple
demonstrates that customers will pay a premium for well designed and
implemented software.
8. Agile programming over emphasizes schedules. Production schedules
and engineering requirements should be balanced by management.
9. When there are many projects to add asssorted features to a
product, code become difficult to manage. Code merges and
inconsistencies become difficult to manage so all the pieces play
together. Merging code down can take several days given high rates of
code churn. Costs associated with code management are not linear as
the number of projects increase. I suspect that the cost function is
exponential.
10. Agile programming uses customers as the test bed. Customers don't
appreciate being treated as guinea pigs.
11. The agile programming model creates an unstable expensive house of
cards. The house of cards will eventually collapse despite efforts to
keep it standing.
Bob
On Sep 19, 10:13 am, DrQ <redr...@yahoo.com> wrote:
> SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW
have a negative impression of agile development for a number of
reasons.
1. Agile programming emphasizes programming over engineering. This
results in software that does not have clean interfaces and is
intertwined with other code. Of course, such code is difficult to
maintain, debug, and replace. Expensive code bloat is the consequence.
2. Agile programming emphasizes coding. The more code that a
programmer produces, the more productive he/she is. This emphasis on
production introduces unnecessary bugs. Studies show that for every
100 lines of code written by a good programmer, 2.7 to 3.2 bugs are
introduced. Many of these are edge cases and not detectable by
testing. The more code that is written, the more bugs that programmers
introduce unless they perform comprehensive function and unit testing;
unfortunately, this is a skill that is rarely taught. The consequences
are bizarre intermittent failures, Heissenbugs, and unpredictable
interactions and other undesirable side-effects.
3. Agile programming is inappropriate for product development where
companies will live with an architecture for a long time. It's better
to engineer an architecture and design clean interfaces than to crank
out code that will soon become problematic. The agile model may be
appropriate for making incremental changes to mature software
products.
4. Agile programming deemphasizes designing performance into products.
After all, the packages and libraries can be replaced in the future.
The problem is that the future never comes unless there is a crisis.
5. Agile programming never views a program or project as complete.
There's always room to tinker and add new levels of abstraction and
modify the mechanics of a program. Expenses around programming become
a sucking black hole.
6. Agile programming is a model that rewards software churn. It's a
great model for building fiefdoms in a corporation and employ busy
programmers; it's terrible for corporations who want to produce
maintainable stable quality products that will not incur high
overheads.
7. Agile programming deemphasizes quality. Deploying software that
works after a fashion "rather than waiting for perfection" introduces
a dangerous slippery slope. I doubt that many managers can define
"acceptable imperfection." Quality should be job one. Apple
demonstrates that customers will pay a premium for well designed and
implemented software.
8. Agile programming over emphasizes schedules. Production schedules
and engineering requirements should be balanced by management.
9. When there are many projects to add asssorted features to a
product, code become difficult to manage. Code merges and
inconsistencies become difficult to manage so all the pieces play
together. Merging code down can take several days given high rates of
code churn. Costs associated with code management are not linear as
the number of projects increase. I suspect that the cost function is
exponential.
10. Agile programming uses customers as the test bed. Customers don't
appreciate being treated as guinea pigs.
11. The agile programming model creates an unstable expensive house of
cards. The house of cards will eventually collapse despite efforts to
keep it standing.
Bob
On Sep 19, 10:13 am, DrQ <redr...@yahoo.com> wrote:
> SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW
steve jenkin
Sep 22, 2009, 7:05:45 PM9/22/09
to guerrilla-cap...@googlegroups.com
Bob,
I heard a quote once, but can't track it down.
Something along the lines of:
"all Software Methodologies can produce successful projects, and all
Methodologies have projects that fail"
Could've been Capers Jones, Jim Highsmith or another of the well known
project management experts.
The point he was making: good people trump bad process & vice-versa.
Alistair Cockburn writes definitively on "per project methodologies":
<http://alistair.cockburn.us/Just-in-time+methodology+construction>
You've raised many correct and valuable points about professional
programming - it's not enough to just get something into production,
it's probably going to run for *decades*. Little things like Design,
Quality and Maintainability matter in the long term - but aren't
measured or reported.
I've seen just one study looking at the common factors in IT departments
that succeed. The factor they found?
- Project Reviews
Pretty much the conclusion Jerry Weinberg came to in the early 70's (and
wrote about extensively)
See "Handbook of Walkthroughs, Inspections, and Technical Reviews:
Evaluating Programs, Projects, and Products"
Alistair Cockburn quotes Norm Kerth's book on the subject as well.
[Norm was one of the leading lights in the Object Oriented world in the
90's. He may have gone onto Agile or XP]
Here is a working Program/Project Manager, Glen B. Alleman, who works
for NASA amongst others and they've made Agile work for them. I've found
his writing concrete, useful and insightful.
<http://herdingcats.typepad.com/>
<http://www.niwotridge.com/>
Summary:
You're right: poor programmers produce poor code, not withstanding any
Methodology.
Hope this helps
s
rml...@gmail.com wrote on 23/9/09 3:33 AM:
> I was at a company that still embraced the agile software model. I
> have a negative impression of agile development for a number of
> reasons.
>
> <snip>
>
> Bob
>
>
> On Sep 19, 10:13 am, DrQ <redr...@yahoo.com> wrote:
>
>> SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW
>>
>> Agile software, rapid prototyping, cloud computing, . . . rather than
>> waiting for perfection, Kundra launches beta versions, expecting
>> improvements later. Gov 2.0 setting the pace for Corp. America IT?
>>
>
>
--
Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA
metasoft
Sep 23, 2009, 12:29:01 PM9/23/09
to Guerrilla Capacity Planning
hi bob,
i'm in complete agreement w/ steve w.r.t. it's the people that counts.
a good process reduce additional wastes and makes the team operates
more efficiently.
unfortunately, misuse is always possible, especially without
understanding or critical review.
IMHO, agile methods have some assumptions that is not stated
sufficiently clear up front.
and agile methods are not w/o its own controversies. my own pet
example being paired-programming.
what is paired programming? is it not instant code review? research
results indicate code review
is the best tool to reduce bugs, so the results are not surprising,
but then there is the need
focus and get into the flow in programming too, which paired
programming distracts from.
so our adoption with paired programming is to use it when it is
needed, e.g.,
making emergency changes to fix a critical bugs to be deployed
immediately into production,
instead of making paired programming a daily practice.
i think we should all be open to new ways, and try them out for
ourselves to see if it works better
in the environment we are in. if not, chuck it and find something else
better. but keep looking.
one thing that's good about agile is that some of the past practices
that's been handed down from older
and experienced programmer is now written down and has a common name.
i remember starting my
first job doing continous integration, but there wasn't a name for it,
and the sr. programmer who showed
me said he was shown the way earlier too, so many agile practices are
not all that new, but was undocumented.
wen
> sjen...@canb.auug.org.auhttp://members.tip.net.au/~sjenkin- Hide quoted text -
>
> - Show quoted text -
i'm in complete agreement w/ steve w.r.t. it's the people that counts.
a good process reduce additional wastes and makes the team operates
more efficiently.
unfortunately, misuse is always possible, especially without
understanding or critical review.
IMHO, agile methods have some assumptions that is not stated
sufficiently clear up front.
and agile methods are not w/o its own controversies. my own pet
example being paired-programming.
what is paired programming? is it not instant code review? research
results indicate code review
is the best tool to reduce bugs, so the results are not surprising,
but then there is the need
focus and get into the flow in programming too, which paired
programming distracts from.
so our adoption with paired programming is to use it when it is
needed, e.g.,
making emergency changes to fix a critical bugs to be deployed
immediately into production,
instead of making paired programming a daily practice.
i think we should all be open to new ways, and try them out for
ourselves to see if it works better
in the environment we are in. if not, chuck it and find something else
better. but keep looking.
one thing that's good about agile is that some of the past practices
that's been handed down from older
and experienced programmer is now written down and has a common name.
i remember starting my
first job doing continous integration, but there wasn't a name for it,
and the sr. programmer who showed
me said he was shown the way earlier too, so many agile practices are
not all that new, but was undocumented.
wen
>
> - Show quoted text -
Neil Gunther
Sep 23, 2009, 7:33:04 PM9/23/09
to Guerrilla Capacity Planning
The anti anti-agile ante has been raised over at
http://www.cfwhisperer.com/post.cfm/thinking-of-agile-xp-please-read-this-first
(with permission).
> SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW
http://www.cfwhisperer.com/post.cfm/thinking-of-agile-xp-please-read-this-first
(with permission).
> SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW
steve jenkin
Sep 23, 2009, 8:23:25 PM9/23/09
to guerrilla-cap...@googlegroups.com
Wen, Bob et al,
Good points. Agile & XP aren't "The Silver Bullet", as Fred Brooks
commented in the mid-80's.
I remember in the mid 80's when zillions of "ground-breaking & new"
68000-based Unix boxes were coming out of Silicon Valley, that the hype
in Software was "Unix will improve productivity 10-fold".
Good people got good results. Everyone else just kept doing things the
same way.
There'd be huge promises from 4GL's and in the early nineties people
were being suckered by "CASE" (Comp. Aided Software Engineering) - with
the promise of "click on the pretty pictures and it'll generate
thousands of lines of perfect code".
yeah, that went well... "Lower-CASE and "upper-CASE" were the first
There have been sooo many fads, fashions and enthusiasms in
Computing/Programming that they can't be inventoried.
I looked at this a while back when someone famous did a collection.
My conclusion was you can't pick the winners...
Fortran & COBOL took years to go from 'fad' to staple.
PL/1 and ADA had immense backing and got used in large/complex projects
- and still remain a sideshow.
Recently a friend commented that new technologies get picked up and
embraced (like GOSIP vs TCP/IP) when
a) they work and
b) the price/availability is right.
I can't shed light on why the market picks what it picks...
I think the central question is:
Why don't 'good' ideas get picked up, and why aren't what's picked up
'good'?
The corollary is:
After decades of hype & unrealised claims,
where's Industry Scepticism and proof-of-claims demands?
There has been a very important anniversary slip by unremarked.
"Software Engineering" turned 40.
The original NATO conferences were in Germany, 1968 and Rome, 1969.
<http://homepages.cs.ncl.ac.uk/brian.randell/NATO/>
The SE field has failed to address/correct *in practice* the central
issues raised in those first papers.
[E.g. the Microsoft Longhorn 'Reset' in 2004. Predictable and Inexcusable.]
Taking a long view, the questions aren't about Methodologies but:
- Why isn't the Profession demonstrably improving
[ie. Show me the Numbers]
- Why aren't Lessons Learned by each generation passed on?
[In fact, it seems the reverse is happening in general practice]
- Why do Managers, Businesses, Educators and Government do nothing to
correct this?
[Not because they don't complain enough or want better]
That better is possible is shown by the Aviation industry.
Those in developed countries understand that Safety and Profitability
are both necessary and related.
The exception making the rule is third world countries like Indonesia.
Same planes, same technology, same training but huge numbers of accidents.
You can look up figures for incidents, injuries & deaths per route-mile,
passenger-mile and take-off.
Plus the NTSB/FAA have detailed accident investigations on-line.
Aviation has improved because they count the numbers, investigate causes
of faults & failures and woe betide anyone that repeats a known error or
goes "off script" and causes problems.
They care about Industry Performances and can make penalties stick.
Yep - the Agile/XP debate is real and useful. I'm encouraging you to
keep on with that.
But unless you think of a new angle, it will follow many, many fine
efforts into obscurity like the SEI, CMM, TSP, ...
regards
steve j
metasoft wrote on 24/9/09 2:29 AM:
>> rml...@gmail.com wrote on 23/9/09 3:33 AM:
>>
>>
>>> I was at a company that still embraced the agile software model. I
>>> have a negative impression of agile development for a number of
>>> reasons.
>>>
>>> <snip>
>>>
>>> Bob
>>>
>>> On Sep 19, 10:13 am, DrQ <redr...@yahoo.com> wrote:
>>>
>>>> SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW
>>>>
>>>> Agile software, rapid prototyping, cloud computing, . . . rather than
>>>> waiting for perfection, Kundra launches beta versions, expecting
>>>> improvements later. Gov 2.0 setting the pace for Corp. America IT?
--
Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA
Mike Brunt
Sep 23, 2009, 8:50:50 PM9/23/09
to guerrilla-cap...@googlegroups.com
Steve you asked the holy grail questions or rather stated them...
" - Why isn't the Profession demonstrably improving
[ie. Show me the Numbers]
- Why aren't Lessons Learned by each generation passed on?
[In fact, it seems the reverse is happening in general practice]
- Why do Managers, Businesses, Educators and Government do nothing to
correct this?
[Not because they don't complain enough or want better]
"
I work exclusively in the web realm as far as the view tier goes and
of course HTML begs to be massacred, as ludicrous as it is, if
ludicrous be the word, the only thing we need do to erect a web site
is create a single .HTML, .CFML .JSP, .ASP, .ASPx, .PHP file in a
directory, be it 10 lines long or 10 million lines long, with
malformed table tags, CSS that only works in some browsers etc etc
etc. It is truly appalling the number of absolutely ill designed and
functionally unusable web sites are out there and many belong to
multi-national blue-chip companies. We are still relying on browser
specificity and then along comes Web 2.0 and turns much of the
engineering of the web realm on its head. Web technology was built on
rapid request-response via a limited number of discreet ports, with
all requests emanating from the browser now we have heaven knows how
many ports being kept open and "requests" being generated by the
server, polling etc. Piling onto this we have an almost total
disregard for any kind of testing that is of any use, so applications
roll out into what is now becoming unknown and uncontrolled
client-server apps in the wild west (Web 2.0 is what I class as
client-server in the wild west). The solutions are just really so
simple and so cost effective, perhaps HAL was right after all and we
need intelligent machines to bring some sense into all of this.
--
Kind Regards - Mike Brunt
Senior Server Engineer
Cell: 562.243.6255
http://www.cfwhisperer.com
Twitter @cfwhisperer
" - Why isn't the Profession demonstrably improving
[ie. Show me the Numbers]
- Why aren't Lessons Learned by each generation passed on?
[In fact, it seems the reverse is happening in general practice]
- Why do Managers, Businesses, Educators and Government do nothing to
correct this?
[Not because they don't complain enough or want better]
"
of course HTML begs to be massacred, as ludicrous as it is, if
ludicrous be the word, the only thing we need do to erect a web site
is create a single .HTML, .CFML .JSP, .ASP, .ASPx, .PHP file in a
directory, be it 10 lines long or 10 million lines long, with
malformed table tags, CSS that only works in some browsers etc etc
etc. It is truly appalling the number of absolutely ill designed and
functionally unusable web sites are out there and many belong to
multi-national blue-chip companies. We are still relying on browser
specificity and then along comes Web 2.0 and turns much of the
engineering of the web realm on its head. Web technology was built on
rapid request-response via a limited number of discreet ports, with
all requests emanating from the browser now we have heaven knows how
many ports being kept open and "requests" being generated by the
server, polling etc. Piling onto this we have an almost total
disregard for any kind of testing that is of any use, so applications
roll out into what is now becoming unknown and uncontrolled
client-server apps in the wild west (Web 2.0 is what I class as
client-server in the wild west). The solutions are just really so
simple and so cost effective, perhaps HAL was right after all and we
need intelligent machines to bring some sense into all of this.
Kind Regards - Mike Brunt
Senior Server Engineer
Cell: 562.243.6255
http://www.cfwhisperer.com
Twitter @cfwhisperer
steve jenkin
Sep 24, 2009, 6:33:49 PM9/24/09
to guerrilla-cap...@googlegroups.com
I was sent this piece recently and was wondering if this list had
comments on it in the light of this discussion.
Question: Is work on Open Source Software "Software Engineering"?
Is what this author is talking about "Software Engineering"?
"How I Work - Software Design as a weak Scientific Process"
<http://use.perl.org/~Alias/journal/39661>
How is Software & its production linked to "Capacity Planning", the erstwhile list topic.
Via Performance.
CapPlan is the Ongoing Operational forecast/planning of system performance.
(A Sum over Time? or what?).
I assert that besides Functionality, there are 4 primary primary areas that must be addressed in Design/Specification, that cannot be added on 'later':
- Quality
- Performance
- Safety/Security
- Usability
My experience says these cannot be retrofitted.
[On 'Quality', it's more than 'defect level'. Don't have a better definition.]
"If you didn't design it in, Why would you expect it to show up?"
Performance is a critical aspect of Professional Software production.
All Engineering disciplines must at their core (also) address Product Economics.
As in "An engineer does for a $1 what any fool can do for $10".
A very important part of every commercial Software System is speed & cost.
We don't write Databases in BASIC, well not the compute intensive core.
regards
steve
Mike Brunt wrote on 24/9/09 10:50 AM:
Question: Is work on Open Source Software "Software Engineering"?
Is what this author is talking about "Software Engineering"?
"How I Work - Software Design as a weak Scientific Process"
<http://use.perl.org/~Alias/journal/39661>
How is Software & its production linked to "Capacity Planning", the erstwhile list topic.
Via Performance.
CapPlan is the Ongoing Operational forecast/planning of system performance.
(A Sum over Time? or what?).
I assert that besides Functionality, there are 4 primary primary areas that must be addressed in Design/Specification, that cannot be added on 'later':
- Quality
- Performance
- Safety/Security
- Usability
My experience says these cannot be retrofitted.
[On 'Quality', it's more than 'defect level'. Don't have a better definition.]
"If you didn't design it in, Why would you expect it to show up?"
Performance is a critical aspect of Professional Software production.
All Engineering disciplines must at their core (also) address Product Economics.
As in "An engineer does for a $1 what any fool can do for $10".
A very important part of every commercial Software System is speed & cost.
We don't write Databases in BASIC, well not the compute intensive core.
regards
steve
Mike Brunt wrote on 24/9/09 10:50 AM:
metasoft wrote on 24/9/09 2:29 AM:hi bob, i'm in complete agreement w/ steve w.r.t. it's the people that counts. a good process reduce additional wastes and makes the team operates more efficiently. unfortunately, misuse is always possible, especially without understanding or critical review. IMHO, agile methods have some assumptions that is not stated sufficiently clear up front. <snip> and the sr. programmer who showed me said he was shown the way earlier too, so many agile practices are not all that new, but was undocumented. wen
rml...@gmail.com wrote on 23/9/09 3:33 AM:I was at a company that still embraced the agile software model. I have a negative impression of agile development for a number of reasons. <snip> Bob On Sep 19, 10:13 am, DrQ <redr...@yahoo.com> wrote:SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW Agile software, rapid prototyping, cloud computing, . . . rather than waiting for perfection, Kundra launches beta versions, expecting improvements later. Gov 2.0 setting the pace for Corp. America IT?
rml...@gmail.com
Sep 24, 2009, 8:49:19 PM9/24/09
to Guerrilla Capacity Planning
Agile proponents seem to forget history and as Santayana wrote, "Those
who cannot remember the past are condemned to repeat it." (George
Santayana, The Life of Reason, Volume 1, 1905).
The Chrysler Comprehensive Compensation System (C3) was a project to
replace several Chrysler payroll applications with a single system.
Kent Beck and Ron Jeffries developed a work style that is now
popularized as Extreme Programming. The project was delivered late and
under performing. The customer representative burned out and quit. Two
years of development followed its original release. There was never a
second release. C3 was a failure and never fully implemented. It was
shutdown.
As a performance engineer, I take special note of its performance
characteristics. Wikipedia snidely says, "Performance was something of
a problem; during development it looked like it would take 1000 hours
to run the payroll, but profiling activities reduced this to around 40
hours; another month's effort reduced this to 18 hours and by the time
the system was launched the figure was 12 hours. During the first year
of production the performance was improved to 9 hours."
Beck published "Extreme Programming Explained" in 1999 using C3 as a
success story. DaimlerChrysler cancelled the C3 project 1 February
2000 and banned XP. The 3C system only paid 10,000 of the anticipated
87,000 employees. Agile is an outgrowth of extreme programming.
XP and Agile promote churn and focus on payable hours. The techniques
are about consultants and scheduling, not development. Agile was
against design until it made a ball of mud out of the C3 project. It
is extremely difficult to engineer performance into a product after it
is released. Performance must be engineered into project DNA and never
treated as an afterthought.
Every software project methodology wants to deliver high value, high
quality products quickly now and into the future. A basic point of
tension is inherent in agile methodology as expressed in the comments:
Quality vs. Delivery Speed. Small well-constrained projects do not
feel this tension to the same degree as large complex systems with
dozens of concurrent projects.
Supporters emphasize the negatives as positives: "Deliver a continuous
stream of potentially shippable product." Again my criticism of agile
programming is well-placed: code churn, unstable code base, frequent
need to integrate code changes (which can be time consuming), and
products of questionable quality. If fails to understand customer
perceptions of frequent product point releases.
Someone wrote, "[Agile methodologies] have an emphasis on design and
architecture - although they defer it to the last responsible moment."
This causes me heartburn. Software engineers cannot defer design and
architecture to the last moment. This reflects a basic difference in
the philosophy of engineers and programmers. High discipline and
strong engineering processes are found in mature organizations with
engineering backgrounds. These terms are antithetical with fast,
quick, good enough, etc. Connie Smith in Software Performance
Engineering has written about the need to do design and architecture
up front with progress reviews. She has great anecdotes about failures
to do this.
If products can be over engineered, they can be under engineered. The
amount of engineering that is required is dependent on the products
use. I certainly would not want to be an astronaut or passenger who
is dependent on under engineered software. NASA has had spectacular
failures due to simple coding errors that were not found in testing.
Banks better not under engineer software to manage my accounts (unless
the errors are in my favor). I am puzzled by agile advocates who laud
agile programming for not over engineering products but fail to see
that the flip side of the coin is under engineering. The degree of
engineering in a product is a balancing act and I've seen too many
instances of agile programming resulting in under engineered code that
fails to integrate cleanly into the core product, scales poorly under
load, has abysmal response times, unintended code interactions
inefficiently use memory and processor resources, Heisenbugs plague
users, incorrect results are periodically produced, etc. If Six Sigma
encourages over engineered software, agile programming encourages
under engineered products.
I feel like laughing when someone claims to have written a product
than only had five bugs. Such a product is trivial or unused. It is a
fact of life that all serious computer programs contain deep
intractable errors. Periodic errors are expected in production code.
The studies are clear. Published estimates of the number of bugs
remaining in typical delivered code range from 4 to 50 bugs per
thousand lines of source code (cf. C. B. Jones, Programming
Productivity; Steve McConnell, Code Complete). Steve McConnell has a
section about error expectations:
(a) Industry Average: "about 15 - 50 errors per 1000 lines of
delivered code." This is usually code that has some level of
structured programming behind it, but may use a mix of coding
techniques.
(b) Microsoft Applications: "about 10 - 20 defects per 1000 lines of
code during in-house testing, and 0.5 defects per KLOC [1000 lines of
code] in released product."
(c) "[Cleanroom development] has been able to achieve rates as low as
3 defects per 1000 lines of code during in-house testing and 0.1
defect per 1000 lines of code in released product."
I assert that the cited defect rates for (b) and (c) are low.
Intractable bugs remain buried in software until the Sun, Moon, and
stars align to trigger them. These bugs are undetectable by QA
methods, are often subtle edge cases and interactions, and failures to
account for certain hardware limitations (e.g., Programmers almost
never check for hardware register overflow). QA testing is not
comprehensive enough to catch all bugs. All too often software is
trained to pass QA tests without addressing fundamental underlying
issues.
According to Li, et al., empirical data indicates that production
software has around two bugs per thousand lines of source code, and
even programs used on space missions by NASA are believed to have
around 0.1 bugs per thousand lines of code. (Michael Naixin Li,
Yashwant K. Malaiya, and Jason Denton. Estimating The Number of
Defects: A Simple and Intuitive Approach. In Proc. 7th Int’l Symposium
on Software Reliability Engineering (ISSRE), 1998.) In the wrong
place, you're a hope and a prayer from that bug causing a catastrophic
failure. It's more than hope and prayer; it's a matter of probability
that an undetected coding bug will be hit. Various statistical models
predict the likelihood of hitting such a bug.
I also find comments about paired or team programming curious. The
method fails to account for small group dynamics. A form of coding co-
dependence often develops as an unintended consequence of programmers
approving each other's code. Greater rigor is required (e.g., formal
code reviews). In addition, programmers are an expensive resource and
having one look over the shoulder of the other is costly.
One blog compares agile programming to teen sex:
Agile is like Teen Sex because:
* Everyone wants to do it
* Many say they’re doing it
* You always exaggerate how much of it you’re doing
* Most people aren’t actually doing it (despite their best
efforts)
* Everybody else seems to be doing more than you
* You get a kick out of telling your friends how they can do it
better
* You spend a lot of time thinking about it
* Your first time never quite goes to plan
* You can’t wait until you experience the real deal
* Very few of you/your friends are doing it correctly
* You do everything you can to please your Product Owner
* It takes you a while before you find your velocity
* You always make sure to hold a retrospective afterwards
* Everyone says they’ll ‘do it better next time’
* Your start getting a bad reputation when you spend too much time
‘Doing it’
"Agile programming doesn't mean doing more work with fewer people" -
Dilbert
The pointy-hair boss commands Dilbert’s team to start using Agile
programming. In the boss’s description, he states that Agile
programming means "no more planning and no more documentation." The
boss goes on saying that the programmers can "start writing code and
complaining." Sadly, if there were no truth in this Dilbert cartoon,
it wouldn't be funny.
I find Agile principles (cf. http://agilemanifesto.org) to be
formulated for consultants to bleed clients by promoting an
uncontrolled undisciplined chaotic processless style of making costly
changes to a moving target. Furthermore, there is insufficient up
front design and specification that leads to gross coding inefficiency
brought about by iterative recoding and coding duplication. If you
intend to produce a serious complex product using agile, just remember
the C3 "success" story that started the movement.
Bob
Scientist
American National Laboratories
who cannot remember the past are condemned to repeat it." (George
Santayana, The Life of Reason, Volume 1, 1905).
The Chrysler Comprehensive Compensation System (C3) was a project to
replace several Chrysler payroll applications with a single system.
Kent Beck and Ron Jeffries developed a work style that is now
popularized as Extreme Programming. The project was delivered late and
under performing. The customer representative burned out and quit. Two
years of development followed its original release. There was never a
second release. C3 was a failure and never fully implemented. It was
shutdown.
As a performance engineer, I take special note of its performance
characteristics. Wikipedia snidely says, "Performance was something of
a problem; during development it looked like it would take 1000 hours
to run the payroll, but profiling activities reduced this to around 40
hours; another month's effort reduced this to 18 hours and by the time
the system was launched the figure was 12 hours. During the first year
of production the performance was improved to 9 hours."
Beck published "Extreme Programming Explained" in 1999 using C3 as a
success story. DaimlerChrysler cancelled the C3 project 1 February
2000 and banned XP. The 3C system only paid 10,000 of the anticipated
87,000 employees. Agile is an outgrowth of extreme programming.
XP and Agile promote churn and focus on payable hours. The techniques
are about consultants and scheduling, not development. Agile was
against design until it made a ball of mud out of the C3 project. It
is extremely difficult to engineer performance into a product after it
is released. Performance must be engineered into project DNA and never
treated as an afterthought.
Every software project methodology wants to deliver high value, high
quality products quickly now and into the future. A basic point of
tension is inherent in agile methodology as expressed in the comments:
Quality vs. Delivery Speed. Small well-constrained projects do not
feel this tension to the same degree as large complex systems with
dozens of concurrent projects.
Supporters emphasize the negatives as positives: "Deliver a continuous
stream of potentially shippable product." Again my criticism of agile
programming is well-placed: code churn, unstable code base, frequent
need to integrate code changes (which can be time consuming), and
products of questionable quality. If fails to understand customer
perceptions of frequent product point releases.
Someone wrote, "[Agile methodologies] have an emphasis on design and
architecture - although they defer it to the last responsible moment."
This causes me heartburn. Software engineers cannot defer design and
architecture to the last moment. This reflects a basic difference in
the philosophy of engineers and programmers. High discipline and
strong engineering processes are found in mature organizations with
engineering backgrounds. These terms are antithetical with fast,
quick, good enough, etc. Connie Smith in Software Performance
Engineering has written about the need to do design and architecture
up front with progress reviews. She has great anecdotes about failures
to do this.
If products can be over engineered, they can be under engineered. The
amount of engineering that is required is dependent on the products
use. I certainly would not want to be an astronaut or passenger who
is dependent on under engineered software. NASA has had spectacular
failures due to simple coding errors that were not found in testing.
Banks better not under engineer software to manage my accounts (unless
the errors are in my favor). I am puzzled by agile advocates who laud
agile programming for not over engineering products but fail to see
that the flip side of the coin is under engineering. The degree of
engineering in a product is a balancing act and I've seen too many
instances of agile programming resulting in under engineered code that
fails to integrate cleanly into the core product, scales poorly under
load, has abysmal response times, unintended code interactions
inefficiently use memory and processor resources, Heisenbugs plague
users, incorrect results are periodically produced, etc. If Six Sigma
encourages over engineered software, agile programming encourages
under engineered products.
I feel like laughing when someone claims to have written a product
than only had five bugs. Such a product is trivial or unused. It is a
fact of life that all serious computer programs contain deep
intractable errors. Periodic errors are expected in production code.
The studies are clear. Published estimates of the number of bugs
remaining in typical delivered code range from 4 to 50 bugs per
thousand lines of source code (cf. C. B. Jones, Programming
Productivity; Steve McConnell, Code Complete). Steve McConnell has a
section about error expectations:
(a) Industry Average: "about 15 - 50 errors per 1000 lines of
delivered code." This is usually code that has some level of
structured programming behind it, but may use a mix of coding
techniques.
(b) Microsoft Applications: "about 10 - 20 defects per 1000 lines of
code during in-house testing, and 0.5 defects per KLOC [1000 lines of
code] in released product."
(c) "[Cleanroom development] has been able to achieve rates as low as
3 defects per 1000 lines of code during in-house testing and 0.1
defect per 1000 lines of code in released product."
I assert that the cited defect rates for (b) and (c) are low.
Intractable bugs remain buried in software until the Sun, Moon, and
stars align to trigger them. These bugs are undetectable by QA
methods, are often subtle edge cases and interactions, and failures to
account for certain hardware limitations (e.g., Programmers almost
never check for hardware register overflow). QA testing is not
comprehensive enough to catch all bugs. All too often software is
trained to pass QA tests without addressing fundamental underlying
issues.
According to Li, et al., empirical data indicates that production
software has around two bugs per thousand lines of source code, and
even programs used on space missions by NASA are believed to have
around 0.1 bugs per thousand lines of code. (Michael Naixin Li,
Yashwant K. Malaiya, and Jason Denton. Estimating The Number of
Defects: A Simple and Intuitive Approach. In Proc. 7th Int’l Symposium
on Software Reliability Engineering (ISSRE), 1998.) In the wrong
place, you're a hope and a prayer from that bug causing a catastrophic
failure. It's more than hope and prayer; it's a matter of probability
that an undetected coding bug will be hit. Various statistical models
predict the likelihood of hitting such a bug.
I also find comments about paired or team programming curious. The
method fails to account for small group dynamics. A form of coding co-
dependence often develops as an unintended consequence of programmers
approving each other's code. Greater rigor is required (e.g., formal
code reviews). In addition, programmers are an expensive resource and
having one look over the shoulder of the other is costly.
One blog compares agile programming to teen sex:
Agile is like Teen Sex because:
* Everyone wants to do it
* Many say they’re doing it
* You always exaggerate how much of it you’re doing
* Most people aren’t actually doing it (despite their best
efforts)
* Everybody else seems to be doing more than you
* You get a kick out of telling your friends how they can do it
better
* You spend a lot of time thinking about it
* Your first time never quite goes to plan
* You can’t wait until you experience the real deal
* Very few of you/your friends are doing it correctly
* You do everything you can to please your Product Owner
* It takes you a while before you find your velocity
* You always make sure to hold a retrospective afterwards
* Everyone says they’ll ‘do it better next time’
* Your start getting a bad reputation when you spend too much time
‘Doing it’
"Agile programming doesn't mean doing more work with fewer people" -
Dilbert
The pointy-hair boss commands Dilbert’s team to start using Agile
programming. In the boss’s description, he states that Agile
programming means "no more planning and no more documentation." The
boss goes on saying that the programmers can "start writing code and
complaining." Sadly, if there were no truth in this Dilbert cartoon,
it wouldn't be funny.
I find Agile principles (cf. http://agilemanifesto.org) to be
formulated for consultants to bleed clients by promoting an
uncontrolled undisciplined chaotic processless style of making costly
changes to a moving target. Furthermore, there is insufficient up
front design and specification that leads to gross coding inefficiency
brought about by iterative recoding and coding duplication. If you
intend to produce a serious complex product using agile, just remember
the C3 "success" story that started the movement.
Bob
Scientist
American National Laboratories
Mike Brunt
Sep 24, 2009, 11:58:14 PM9/24/09
to Guerrilla Capacity Planning
I just have one thing to say relating this part of the thread, in the
Java world where I exist, software-code is absolutely relative to
capacity planning and scalability it is very easy to negatively impact
thread and memory behavior by poor coding practices. Another area
which can also have negative impacts on thread and memory behavior is
badly written SQL code. To be honest ORM's such as Hibernate concern
me greatly as they also concern my DBA friends. My opinion is the
more that is handled via Stored Procedures the better but I am taking
us off topic now.
On Sep 24, 3:33 pm, steve jenkin <stevej...@gmail.com> wrote:
> I was sent this piece recently and was wondering if this list had comments on it in the light of this discussion.
> Question: Is work on Open Source Software "Software Engineering"?
> Is what this author is talking about "Software Engineering"?
> "How I Work - Software Design as a weak Scientific Process"<http://use.perl.org/~Alias/journal/39661>
> How is Software & its production linked to "Capacity Planning", the erstwhile list topic.
> Via Performance.
> CapPlan is the Ongoing Operational forecast/planning of system performance.
> (A Sum over Time? or what?).
> I assert that besides Functionality, there are 4 primary primary areas that must be addressed inDesign/Specification, that cannot be added on 'later':
Java world where I exist, software-code is absolutely relative to
capacity planning and scalability it is very easy to negatively impact
thread and memory behavior by poor coding practices. Another area
which can also have negative impacts on thread and memory behavior is
badly written SQL code. To be honest ORM's such as Hibernate concern
me greatly as they also concern my DBA friends. My opinion is the
more that is handled via Stored Procedures the better but I am taking
us off topic now.
On Sep 24, 3:33 pm, steve jenkin <stevej...@gmail.com> wrote:
> I was sent this piece recently and was wondering if this list had comments on it in the light of this discussion.
> Question: Is work on Open Source Software "Software Engineering"?
> Is what this author is talking about "Software Engineering"?
> "How I Work - Software Design as a weak Scientific Process"<http://use.perl.org/~Alias/journal/39661>
> How is Software & its production linked to "Capacity Planning", the erstwhile list topic.
> Via Performance.
> CapPlan is the Ongoing Operational forecast/planning of system performance.
> (A Sum over Time? or what?).
> - Quality
> - Performance
> - Safety/Security
> - Usability
> My experience says these cannot be retrofitted.
> [On 'Quality', it's more than 'defect level'. Don't have a better definition.]
> "If you didn't design it in, Why would you expect it to show up?"
> Performance is a critical aspect of Professional Software production.
> All Engineering disciplines must at their core (also) address Product Economics.
> As in "An engineer does for a $1 what any fool can do for $10".
> A very important part of every commercial Software System is speed & cost.
> We don't write Databases in BASIC, well not the compute intensive core.
> regards
> steve
> Mike Brunt wrote on 24/9/09 10:50 AM:Steve you asked the holy grail questions or rather stated them... " - Why isn't the Profession demonstrably improving [ie. Show me the Numbers] - Why aren't Lessons Learned by each generation passed on? [In fact, it seems the reverse is happening in general practice] - Why do Managers, Businesses, Educators and Government do nothing to correct this? [Not because they don't complain enough or want better] " I work exclusively in the web realm as far as the view tier goes and of course HTML begs to be massacred, as ludicrous as it is, if ludicrous be the word, the only thing we need do to erect a web site is create a single .HTML, .CFML .JSP, .ASP, .ASPx, .PHP file in a directory, be it 10 lines long or 10 million lines long, with malformed table tags, CSS that only works in some browsers etc etc etc. It is truly appalling the number of absolutely ill designed and functionally unusable web sites are out there and many belong to multi-national blue-chip companies. We are still relying on browser specificity and then along comes Web 2.0 and turns much of the engineering of the web realm on its head. Web technology was built on rapid request-response via a limited number of discreet ports, with all requests emanating from the browser now we have heaven knows how many ports being kept open and "requests" being generated by the server, polling etc. Piling onto this we have an almost total disregard for any kind of testing that is of any use, so applications roll out into what is now becoming unknown and uncontrolled client-server apps in the wild west (Web 2.0 is what I class as client-server in the wild west). The solutions are just really so simple and so cost effective, perhaps HAL was right after all and we need intelligent machines to bring some sense into all of this.metasoft wrote on 24/9/09 2:29 AM:hi bob, i'm in complete agreement w/ steve w.r.t. it's the people that counts. a good process reduce additional wastes and makes the team operates more efficiently. unfortunately, misuse is always possible, especially without understanding or critical review. IMHO, agile methods have some assumptions that is not stated sufficiently clear up front. <snip> and the sr. programmer who showed me said he was shown the way earlier too, so many agile practices are not all that new, but was undocumented. wenrml...@gmail.comwrote on 23/9/09 3:33 AM:I was at a company that still embraced the agile software model. I have a negative impression of agile development for a number of reasons. <snip> Bob On Sep 19, 10:13 am, DrQ<redr...@yahoo.com>wrote:SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW Agile software, rapid prototyping, cloud computing, . . . rather than waiting for perfection, Kundra launches beta versions, expecting improvements later. Gov 2.0 setting the pace for Corp. America IT?-- Steve Jenkin, Info Tech, Systems and Design Specialist. 0412 786 915 (+61 412 786 915) PO Box 48, Kippax ACT 2615, AUSTRALIAsjenkin@canb.auug.org.auhttp://members.tip.net.au/~sjenkin
> - Performance
> - Safety/Security
> - Usability
> My experience says these cannot be retrofitted.
> [On 'Quality', it's more than 'defect level'. Don't have a better definition.]
> "If you didn't design it in, Why would you expect it to show up?"
> Performance is a critical aspect of Professional Software production.
> All Engineering disciplines must at their core (also) address Product Economics.
> As in "An engineer does for a $1 what any fool can do for $10".
> A very important part of every commercial Software System is speed & cost.
> We don't write Databases in BASIC, well not the compute intensive core.
> regards
> steve
rml...@gmail.com
Sep 26, 2009, 2:54:41 PM9/26/09
to Guerrilla Capacity Planning
Barry Boehm and Victor Basili's Software Defect Reduction Top 10 List
(http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf) should
be read annually by programmers and project managers. Its insights and
principles should be applied throughout the software engineering and
product development process. When this is done, agile programming is
declared DOA in the enterprise simply because of the number of
principles it violates. Well, maybe that's a slight overstatement. It
cannot be used for any but the simplest noncritical projects.
Agile's emphasis on quickly producing working code backloads real
costs into product maintenance. Contractors can claim that they have
produced product with time and cost savings and programmers can move
to their next projects. Maintenance tasks are left to sustaining or
other engineers. Boehm and Basili observe, "A typical life-cycle cost
distribution of 30 percent development and 70 percent maintenance."
Agile programming shifts real project costs from the least expensive
to the most expensive part of product life-cycle where costs can be
100 times more expensive to find and fix.
Those responsible for creating the software engineering messes often
move to bigger and better projects or jobs before their software IEDs
start exploding. I've witnessed agile programmers be lauded and
promoted when their package is produced and leave the company for
greener pastures right before new features seriously began to use
their packages. Staff and managers discover too late that the packages
hamstring dependent applications when used in any significant way. Of
course, the agile programmers highlight their "successful" project
during interviews and references speak glowingly of their
contributions and timely package delivery. Once they are gone, their
previous employers are seriously constrained by the performance and
software defects in the packages and may not be able to meet
contracted service level agreements for months while design and
architectural defects are reworked.
Agile programming advocates continually refactor code. If the code had
been written after careful design and specification, much rework could
be avoided. This is a significant avoidable cost. Software craftsmen
spend much time on the architecture, design, interfaces, and
specification before a single line of code is written. Such code is
tight and maintainable. They focus on getting it right, avoiding
costly rework, satisfying needs, and saving money. In their view,
rework is an evil to be avoided, not a value to be embraced.
One would not build a house using agile programming methods. Imagine
the consequences if a land owner went to the Agile Building
Construction Company to build a dream home. After describing the
characteristics of the new home, the contractor soon starts building
the simplest parts of the home so that he quickly has results to show
his client. The client explains that the builder's incremental
offerings need rework: locations are wrong; pieces are improperly fit
together, dimensions are incorrect, features and fixtures are not what
the client had in mind, color schemes are wrong, etc. After
redescribing and clarifying what is desired ABC Company reworks what
has been done: razing and rebuilding some construction, and adding to,
deleting from, and moving other construction. This process of
iteratively building portions of the dream home is kludgy and
expensive. The final product is a monstrosity because it was
improperly architected, designed, and specified (cf. www.theugliesthouse.com).
The costs of retrofitting and building a new house with the latest
technology and the modern conveniences are quite different: tearing
out walls and ceilings for new insulation, replace aluminum wiring
with copper, radiant heat flooring, instant water heaters,
thermostatically controlled showers, solar electricity and heating,
radiant foil in the ceilings and exterior facing walls, etc. The
retrofitted house is going to be more expensive and kludgy compared
with the house that has features and technology designed into it.
Agile programming constantly retrofits software and the result is an
expensive, kludgy house that requires costly maintenance and updates.
Software, like a home, requires craftsmanship. A craftman gathers and
analyzes requirements, creates a functional architecture, creates a
preliminary design before fleshing out design details, models and
verifies correctness, codes, unit tests, and tests integration before
moving to maintenance and operation. Agile programming reminds me of
someone with attention deficity disorder/Hyperactive subtype. Insead
of going through the well-defined steps of "Ready, Aim, Fire," agile
programmers go "R...fire, fire, fire."
Robert Lane
Scientist
American National Laboratories
(http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf) should
be read annually by programmers and project managers. Its insights and
principles should be applied throughout the software engineering and
product development process. When this is done, agile programming is
declared DOA in the enterprise simply because of the number of
principles it violates. Well, maybe that's a slight overstatement. It
cannot be used for any but the simplest noncritical projects.
Agile's emphasis on quickly producing working code backloads real
costs into product maintenance. Contractors can claim that they have
produced product with time and cost savings and programmers can move
to their next projects. Maintenance tasks are left to sustaining or
other engineers. Boehm and Basili observe, "A typical life-cycle cost
distribution of 30 percent development and 70 percent maintenance."
Agile programming shifts real project costs from the least expensive
to the most expensive part of product life-cycle where costs can be
100 times more expensive to find and fix.
Those responsible for creating the software engineering messes often
move to bigger and better projects or jobs before their software IEDs
start exploding. I've witnessed agile programmers be lauded and
promoted when their package is produced and leave the company for
greener pastures right before new features seriously began to use
their packages. Staff and managers discover too late that the packages
hamstring dependent applications when used in any significant way. Of
course, the agile programmers highlight their "successful" project
during interviews and references speak glowingly of their
contributions and timely package delivery. Once they are gone, their
previous employers are seriously constrained by the performance and
software defects in the packages and may not be able to meet
contracted service level agreements for months while design and
architectural defects are reworked.
Agile programming advocates continually refactor code. If the code had
been written after careful design and specification, much rework could
be avoided. This is a significant avoidable cost. Software craftsmen
spend much time on the architecture, design, interfaces, and
specification before a single line of code is written. Such code is
tight and maintainable. They focus on getting it right, avoiding
costly rework, satisfying needs, and saving money. In their view,
rework is an evil to be avoided, not a value to be embraced.
One would not build a house using agile programming methods. Imagine
the consequences if a land owner went to the Agile Building
Construction Company to build a dream home. After describing the
characteristics of the new home, the contractor soon starts building
the simplest parts of the home so that he quickly has results to show
his client. The client explains that the builder's incremental
offerings need rework: locations are wrong; pieces are improperly fit
together, dimensions are incorrect, features and fixtures are not what
the client had in mind, color schemes are wrong, etc. After
redescribing and clarifying what is desired ABC Company reworks what
has been done: razing and rebuilding some construction, and adding to,
deleting from, and moving other construction. This process of
iteratively building portions of the dream home is kludgy and
expensive. The final product is a monstrosity because it was
improperly architected, designed, and specified (cf. www.theugliesthouse.com).
The costs of retrofitting and building a new house with the latest
technology and the modern conveniences are quite different: tearing
out walls and ceilings for new insulation, replace aluminum wiring
with copper, radiant heat flooring, instant water heaters,
thermostatically controlled showers, solar electricity and heating,
radiant foil in the ceilings and exterior facing walls, etc. The
retrofitted house is going to be more expensive and kludgy compared
with the house that has features and technology designed into it.
Agile programming constantly retrofits software and the result is an
expensive, kludgy house that requires costly maintenance and updates.
Software, like a home, requires craftsmanship. A craftman gathers and
analyzes requirements, creates a functional architecture, creates a
preliminary design before fleshing out design details, models and
verifies correctness, codes, unit tests, and tests integration before
moving to maintenance and operation. Agile programming reminds me of
someone with attention deficity disorder/Hyperactive subtype. Insead
of going through the well-defined steps of "Ready, Aim, Fire," agile
programmers go "R...fire, fire, fire."
Robert Lane
Scientist
American National Laboratories
Neil Gunther
Sep 28, 2009, 12:26:53 PM9/28/09
to Guerrilla Capacity Planning
IEEE Software, September/October 2009, pp. 6–9
VOICE OF EVIDENCE: "What Do We Know about Agile Software Development?"
<http://www2.computer.org/portal/web/computingnow/0909/whatsnew/
software>
> SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW
VOICE OF EVIDENCE: "What Do We Know about Agile Software Development?"
<http://www2.computer.org/portal/web/computingnow/0909/whatsnew/
software>
> SJ Mercury News columnist Chris O'Brien's interviews Vivek Kundrahttp://bit.ly/1bv1LW
rml...@gmail.com
Sep 29, 2009, 12:19:31 PM9/29/09
to Guerrilla Capacity Planning
Check this out: http://www.joelonsoftware.com/items/2009/09/23.html.
The author advocates duct tape and WD-40 software project management.
He analogizes agile using a go-cart held together and being patched
with duct tape while careening down hill and other go-cart builders
are still designing in their workshops. He writes, "You might have a
messy go-cart, but it’ll sure as hell fly." What an exhilarating
experience until ... the go-cart falls apart going 60 MPH. Its
occupant dies. Dozens of spectators are injured.
The author quotes Netscape's Zawinski as saying, “At the end of the
day, ship the f---ing thing! It’s great to rewrite your code and make
it cleaner and by the third time it’ll actually be pretty. But that’s
not the point—you’re not here to write code; you’re here to ship
products.” Cut the non-essential, anything not in the customer's
experience, like unit tests. Shipping a 50% solution is better than
having 99%. It's better to write what's going to be good enough than
to use "a host of other [proven] technologies that are all totally
reasonable ... but are, honestly, just a little bit too hard for the
human brain." The author's disparaging attitude software toward design
is succinct: "goddamn 'Design Patterns' meetup."
What has this got to do with performance? Everything. Performance is
engineered into products from the beginning. It cannot be an
afterthought. Engineered performance stretches and stresses the human
mind. It assigns a performance budget to software tasks during design
and specification that programmers are expected to meet. Software
performance engineering recognizes that a quality product is designed
for the long haul. There are times when corners are cut due to the
needs of the business. When corners are cut, are duct tape and WD-40
really the appropriate solution? Rarely.
Whose code is going to finish the race and whose code is going to be a
disaster that keeps the industry abuzz for years? Whose code is going
to function under extreme customer loads? Do you want your business
driven on this code http://farm1.static.flickr.com/12/17676116_d11ee7749a.jpg?v=0
or this code http://www.jmooneyham.com/trans-am-mustang-race-car.jpg
or this code http://1.bp.blogspot.com/_skQSpSg0aqA/SRXBnJORJOI/AAAAAAAAAS8/qjdKKPsCZdc/s400/lambourgini.jpg?
The author advocates duct tape and WD-40 software project management.
He analogizes agile using a go-cart held together and being patched
with duct tape while careening down hill and other go-cart builders
are still designing in their workshops. He writes, "You might have a
messy go-cart, but it’ll sure as hell fly." What an exhilarating
experience until ... the go-cart falls apart going 60 MPH. Its
occupant dies. Dozens of spectators are injured.
The author quotes Netscape's Zawinski as saying, “At the end of the
day, ship the f---ing thing! It’s great to rewrite your code and make
it cleaner and by the third time it’ll actually be pretty. But that’s
not the point—you’re not here to write code; you’re here to ship
products.” Cut the non-essential, anything not in the customer's
experience, like unit tests. Shipping a 50% solution is better than
having 99%. It's better to write what's going to be good enough than
to use "a host of other [proven] technologies that are all totally
reasonable ... but are, honestly, just a little bit too hard for the
human brain." The author's disparaging attitude software toward design
is succinct: "goddamn 'Design Patterns' meetup."
What has this got to do with performance? Everything. Performance is
engineered into products from the beginning. It cannot be an
afterthought. Engineered performance stretches and stresses the human
mind. It assigns a performance budget to software tasks during design
and specification that programmers are expected to meet. Software
performance engineering recognizes that a quality product is designed
for the long haul. There are times when corners are cut due to the
needs of the business. When corners are cut, are duct tape and WD-40
really the appropriate solution? Rarely.
Whose code is going to finish the race and whose code is going to be a
disaster that keeps the industry abuzz for years? Whose code is going
to function under extreme customer loads? Do you want your business
driven on this code http://farm1.static.flickr.com/12/17676116_d11ee7749a.jpg?v=0
or this code http://www.jmooneyham.com/trans-am-mustang-race-car.jpg
or this code http://1.bp.blogspot.com/_skQSpSg0aqA/SRXBnJORJOI/AAAAAAAAAS8/qjdKKPsCZdc/s400/lambourgini.jpg?
steve jenkin
Sep 29, 2009, 6:35:37 PM9/29/09
to guerrilla-cap...@googlegroups.com
Where do folk on the list stand on 'Open Source' Software (FOSS) -
specifically the code creation practices of the best/largest projects.
E.g. Apache, SAMBA, Postgres, KDE, and the Linux kernel.
The chief characteristic of FOSS projects is their unevenness and lack
of consistent quality - though the best work stands out as good code.
I've seen one or two studies of FOSS - but none of the coding practices
& team 'management' used to keep the best projects running...
One hypothesis is that FOSS programmers, because they set their own
rules & goals, will only use processes & practices that *work* for them.
They don't have time to waste on bureaucratic meaningless, nor do they
have to kow-tow to the dictates of "Best Practice Methodologies"...
The proof that FOSS techniques *can* work (for the best programmers) is
shown by the low defect rates and good Security/Performance of the 'star
projects'. Many would argue they beat the 'paid professionals' at
Microsoft by an order of magnitude (& more) on most metrics... Not sure
what that says of either side.
The tie-in to the thread: No FOSS project I've come across espouses any
Software Methodology, including Agile/XP.
If they really worked and were attractive to programmers in their day
jobs, wouldn't they be embraced for FOSS projects?
The articles posted demonstrate to me that Agile & XP
practices/techniques by themselves don't yield good outcomes.
From what I've read, I'm not even sure there's evidence they ever lead
to robust & high-performance code...
From the stance "If you didn't design it in, why would you expect it to
show up?" and the seeming lack of Agile/XP techniques to ever look
beyond mere functionality - I'm left wondering how Agile/XP address
Security, Performance & Usability...
Hope this contributes to the debate.
s
rml...@gmail.com wrote on 30/9/09 2:19 AM:
specifically the code creation practices of the best/largest projects.
E.g. Apache, SAMBA, Postgres, KDE, and the Linux kernel.
The chief characteristic of FOSS projects is their unevenness and lack
of consistent quality - though the best work stands out as good code.
I've seen one or two studies of FOSS - but none of the coding practices
& team 'management' used to keep the best projects running...
One hypothesis is that FOSS programmers, because they set their own
rules & goals, will only use processes & practices that *work* for them.
They don't have time to waste on bureaucratic meaningless, nor do they
have to kow-tow to the dictates of "Best Practice Methodologies"...
The proof that FOSS techniques *can* work (for the best programmers) is
shown by the low defect rates and good Security/Performance of the 'star
projects'. Many would argue they beat the 'paid professionals' at
Microsoft by an order of magnitude (& more) on most metrics... Not sure
what that says of either side.
The tie-in to the thread: No FOSS project I've come across espouses any
Software Methodology, including Agile/XP.
If they really worked and were attractive to programmers in their day
jobs, wouldn't they be embraced for FOSS projects?
The articles posted demonstrate to me that Agile & XP
practices/techniques by themselves don't yield good outcomes.
From what I've read, I'm not even sure there's evidence they ever lead
to robust & high-performance code...
From the stance "If you didn't design it in, why would you expect it to
show up?" and the seeming lack of Agile/XP techniques to ever look
beyond mere functionality - I'm left wondering how Agile/XP address
Security, Performance & Usability...
Hope this contributes to the debate.
s
rml...@gmail.com wrote on 30/9/09 2:19 AM:
Reply all
Reply to author
Forward
0 new messages