Realizing quality improvement through test driven development: results and experiences of four industrial teams analyzes the TDD experiences of 4 teams at IBM and Microsoft. Nothing surprising here to those who have already experimented with test-driven development (pre-release defect density decrease of 40%-90% combined with a 15–35% increase in initial development time), but it is good to have some hard numbers on TDD rather than relying solely on anecdotes and hearsay.
Why Big Software Projects Fail: The 12 Key Questions by Watts Humphrey clearly talks about how:
Agile has become popular because finding all requirements at the beginning of a project is nearly impossible for large software projects, especially green-field projects (projects that are the first of their kind). Agile, properly executed, lets you discover requirements by using a running system as a usable prototype for the eventual finished system.
Agile also requires everyone's involvement in the scheduling, rather than having an arbitrary schedule handed down from on high -- a tactic which I think has contributed the majority of project failures (real Project Management classes will tell you just how big of a no-no is schedule imposition).
(Mr. Humphrey is worth listening to -- while he led the OS/360 development team, they met their schedule for all 19 releases he oversaw.)
Pretend Project Management is when management of the project ignores reality -- from the making of the schedule, to the tracking of actual vs. planned time/money spent, all the way down to the project post-mortem (and mortem it usually is, as the project is often D.O.A.) Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong is a real-life example of Pretend Project Management, one worth examining in more detail.
The first red flag is not hiring a system administrator, while simultaneously not allocating the time for system administration in the schedule. The Iron Triangle of scheduling cannot be violated without doing violence to the schedule -- you cannot have system administration work to do without scheduling time for someone to do that work. So, without a system administrator, the schedule has to change so that other people will get that work done. Generally (IMHO), you cannot take an FTE's amount of work in a schedule and say, "Oh, we'll just do that work during slack times." This always comes back to bite you, usually towards the end of the project when you can least afford it. The Project Manager should have modified the schedule to allow time for system administration by whatever means cut back features (scope), add a system administrator (cost), or stretched out the schedule (time). If management does not let you modify the schedule, then Pretend Project Management is what is actually being practiced.
Another red flag was "Agile Development" but no time in the schedule for quick incremental deliveries (intervals measured in weeks). Perhaps the essence of Agile Development is quick iterations with immediate responses by the customer. If the iterations are not quick, or the responses are not immediate, then the development process is not Agile, despite protestations to the contrary. (And calling quick iterations "silly" as management did shows serious misunderstanding of the Agile Nature.) Quick iterations maximize the value delivered to the customer, as the feedback from quick iterations keeps development on the correct path. If the feedback loop is too long because of lengthy iterations, management introduces the risk that development will produce a product not needed or wanted by the customer. Agile Development without quick iterations is Pretend Agile Development, and Project Management of Pretend Agile Development is Pretend Project Management, as time has not been allocated in the schedule for real Agile Development. (Hint: 4 weeks rather than 4 months is closer to a useful iteration length.)
The lack of continuous integration is yet another red flag. Agile development should proceed at a fairly steady pace. Continuous integration helps steady the pace, by preventing small, relatively simple build problems from growing into huge, intractable build problems. In tbe pre-Ethernet days, I once had to integrate months of changes -- trust me, you really don't want to have to do that.
Those of you with exposure to Project Management training will notice another, massive red flag -- no flexibility in scope, time, or resources. When I have managed projects in the past, resources were fixed, time was fairly-well fixed, while scope was the most variable part of the project. I suspect (without proof) that this is a common pattern, as you sacrifice features to get the project "done" (by some measure).
From what I have read, Agile Development seems to plan for a fixed number of people (resources) while varying the time and scope of the project. Usually, changing the project scope is the topic for those writing about how Agile differs from other development styles. (This may be because Agile developers have the attitude, "It will be done when it is done, and not a moment before.")
What conclusions can we draw from this example?
Troubleshooting works through an example troubleshooting situation (possible cardiac problem), then extracts the pattern to follow when you are troubleshooting, whether you are responding to a medical emergency or a debugging a Perl program.
Worth a look.
If you have ever wondered why some presentations grab you while others leave you cold, this TechRepublic download of a chapter from Cliff Atkinson's Beyond Bullet Points may provide insight. (The chapter feels like a Head First book chapter to me.)
Code Contracts for
Code Contracts includes a static checker program for verifying both explicit and implicit (null references, array bounds, etc.) code contracts. Runtime (dynamic) contract checking can use marked series of If-Then-Throw guard clauses as in:
if ( x == null )
throw new ArgumentNullException("x");
if ( y < 0 )
throw new ArgumentOutOfRangeException(...);
Contract.EndContractBlock();
(so you don't waste perfectly good guard clauses) as well as the standard, explicit code contracts like:
Contract.Invariant(this
.y >= 0);
Contract.Assert(this.x == 3,
"Why isn't the value of x 3?");
Contract.Requires(x ! = null,
"DANGER -- missles fired!");
Code Contracts defaults at runtime to throwing an exception (System.Diagnostics.Contracts.ContractException) when a contract is violated (this behavior is configurable).
I have not tried Code Contracts (or any code contract mechanism) yet, but the idea is intriguing because it lets the computer do something it does well (exhaustive examination of your code in tedious detail) thereby freeing you to work on the higher-level aspects of your program, just as C freed us from assembly language bookkeeping and Perl/Java/VB.NET etc. free us from C language bookkeeping.
If anyone has experience with code contracts for any language (positive or negative), please comment.
(Ob. Perl ref. -- see Moose and Class::Contract among others...
Mark Russinovich's Inside Windows Vista User Account Control includes many interesting tidbits for those like me who develop for Microsoft Windows, but to me Windows Vista Integrity Levels are DoD-style Multi-Level Security by another name.
This is ironic, as the Department of Defense seems to be moving away from MLS systems, instead going towards PCs where each PC is at one level of security. (DoD developers, feel free to speak up at this point.)
Worth a look for Windows developers and OS enthusiasts.
As Perl moves into Garbage Collection territory with Perl 6, Dispose, Finalization, and Resource Management -- even though it was written about the
If you ignore these issues, you will spend your time debugging memory allocation/release problems instead of delivering functionality to your customers -- and your customers pay you for the functions you deliver (they only put up with your debugging to get those functions).
(One way to think about Garbage Collection is that GC is like Perl for memory allocation/release -- GC makes easy memory alloc/release easy, and makes hard memory alloc/release possible.)
For those who have not seen this -- Top 25 Most Dangerous Programming Errors.
As a personal example, RELMA is moving from VB6 (1998 technology) to VB.NET (2008 technology), so there are lots of good additional features in VB.NET to learn about. I have started using Zotero to track my