Fundamentally Broken

This week I had an interesting (and heated, of course) conversation on the Northwest C++ Group mailing list, following an Agile/Design Patterns webinar announce by Alan Shalloway.

I responded to the announcement in a sarcastic tone that some people found funny. Some consultants felt offended by the "unfriendly remarks". Boo hoo!

Several people gave examples of how Agile had been misused in real-life projects.

Read the above line again, because that's where the crux of the problem with Agile is: it is more often misunderstood and misused than not (hm, where did I hear that before? "Communism is not bad, it was just incorrectly applied by the Soviet Block").

Defending Agile on such grounds is equivalent to saying that there's nothing wrong with using raw pointers in C and C++, people just have to learn to do it right; hire expensive consultants and trainers to tell them how to avoid dangling pointers and such. What about using smart pointers or a garbage-collected language, then?

Has it not been said of yore that programming languages and APIs should be designed so that they encourage the correct use rather than the other way around?

If Agile encourages incorrect usage, then it is not a well-designed methodology. It needs some serious patching.

I showed the above paragraphs to a friend and he quickly rebutted me: "You criticize Agile yet you do not even know what Agile is. Please define Agile for me".

Awesome point! It greatly explains the misuse of the methodology: people hear the word and go ahead and apply whatever they think Agile is. Like some manager dude who does not allow his developers to fix memory leaks, because such activity is not covered by a "user story" on his cork board.

XP, Agile, Test Driven Development have become anti-brands. These buzzwords have been so badly abused that they are now diluted.

Even worse, Agile is now associated (in many people's minds anyway) with weaselly consultants and incompetent managers.

I Will Break Your Unit Testes (tm)

How much does it cost to develop a debugger? I ran SLOC Count on the source tree of my ZeroBUGS debugger for Linux, which I have been developing single-handedly since 2003 (late Fall).

I have removed some of the third party components, such as libdwarf and Google's sparsehash, but I kept all experimental and support code (you can subtract the ansi C lines though, they represent some old tests).

SLOC    Directory       SLOC-by-Language (Sorted)
38470   plugin          cpp=35578,asm=1485,python=1258,sh=149
26576   engine          cpp=21091,sh=5409,ansic=76
12115   interp          cpp=11475,yacc=450,lex=190
9300    zdk             cpp=9300
9101    unmangle        cpp=5402,ansic=3692,sh=7
8147    dwarfz          cpp=8147
5592    typez           cpp=5592
4648    stabz           cpp=4648
4353    dharma          cpp=4353
4289    zero_python     cpp=4289
2967    elfz            cpp=2967
2813    misc            cpp=2093,python=629,ansic=91
2357    symbolz         cpp=2357
2151    minielf         cpp=2151
949     readline        cpp=949
798     top_dir         python=477,sh=237,ansic=84
376     tools           python=296,sh=80
362     bench           cpp=362
176     make            sh=176
61      zrt             cpp=61
0       docs            (none)
0       help            (none)


Totals grouped by language (dominant language first):
cpp:         120815 (89.10%)
sh:            6058 (4.47%)
ansic:         3943 (2.91%)
python:        2660 (1.96%)
asm:           1485 (1.10%)
yacc:           450 (0.33%)
lex:            190 (0.14%)


Total Physical Source Lines of Code (SLOC)                = 135,601
Development Effort Estimate, Person-Years (Person-Months) = 34.67 (415.99)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 2.06 (24.73)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 16.82
Total Estimated Cost to Develop                           = $ 4,682,930
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.

I don't know what else to read into this, other than I am a badass.

You think that cowboy programming is bad?

I believe that agile is well suited for developers with small unit testes.

The Steve Yegge Factor

Who is Steve Yegge? Oh, just some guy I did not meet while I was working for Amazon, either because my short (two and a half years, from April 2001 to November 03) tenure has not overlapped with his, or maybe just because I do not seek the benevolent companionship of self-appointed software rock stars. Who knows?

While I agree with some of his views on the Agile Process, I am not sure that I fancy his style, for several reasons:

I know from experience that blogging and participating in forums while enjoying a glass of wine inevitably leads to my offending someone needlessly (I have done it more times than I would like to admit, and trust me: I love my reds).

Arguing over development processes (and programming languages, and OS-es) gets people so worked up to the point it becomes a huge time sink, a distraction from what I like doing best, which is writing code. Sometimes I would rather not say what I truly think.

Agile is a necessary evil because it keeps management happy and deluded, thinking they have a grip over the development process (and thus less dangerous).

And finally, why tell people the truth on Agile? Society needs dumb people. If everybody smartens up overnight, then who's gonna pick the garbage? Not Pinocchio, I hear he wants to be a real boy now.