Re: Agile Development, Anyone?

On 8/30/2011 9:06 AM, Bryce Martin wrote:

Joe,
I understand where you are coming from. As I said in another post... its
not for all situations. Lots of business applications have well defined
specifications (I know, laugh laugh, but its true), or you are coding to
some sort of standard process that is a matter of just pounding out the
necessary lines of code to make it work.

Yup, I know about application specifiations. I was the Manager of Architecture for SSA, with a primary focus on new development for their client/server products. I have some experience in large-scale software design, and in building and deploying development teams. I've also done a lot of individual programming, both for new development and application maintenance.

Its not about typos, the compiler will catch those. Its about the bigger
picture. Programs can become complicated very quickly, and very little
code written hits the deck without any bugs. Cases that weren't thought
of where two pieces of code integrate, cause and effect with other parts
of the system.

This is what upfront design is for. Well-defined interfaces between systems, designed into the application at the beginning, make these integrations run smoothly. You program to the interface, and the rest of the system works. Whether you call it "modular programming", "object orientation" or "encapsulation", you have to design it in at the very top, otherwise your integration efforts become nightmares.

Sometimes having that set of eyes and other set of
experience can save hours or days of trouble shooting and bug hunting.
Using a variable with similar but just slightly different context can
cause a headache. You become so close to the code that you begin to see
what you "think" you see, not what is really there. This happens no
matter what the quality of the programmer.

I don't disagree, I only say that it doesn't happen regularly, at least not to experienced programmers. It happens, but on the order of once a week or once a month, not every day. Novice programmers, on the other hand, could take advantage of the technique, but it's an awfully expensive way to train a programmer!

You don't always take the
right approach the first time, you always have code that you later wish
you could refactor. Iterative development is supposed to make refactoring
easier and not such a loaded and haunted idea.

Again, it's not that it never happens, but how often. In my mind, the more you have to refactor, the more time might have been better spent in initial design. Just like bugs are easier to fix during compiles rather than runtime, architectural flaws are easier to fix in design rather than programming. It's the nature of the beast.

Its ok to admit we are
human when we code, no one is perfect. And if we are honest about the
amount of mistakes in our code, either caught by ourselves during testing,
or by the users in production, I think you'll begin to see where an
integrated approach between two programmers can come in handy.

Except when I am doing POC on new technologies, most of my programs have few bugs. Most of those I find during unit testing. Very few make it to system testing. And I think I have had three significant bugs pop up in production in the last year (as in bugs that actually affected data, as opposed to cosmetic problems like a field not getting highlighted or something). And this was a brutal year; we implemented some significant changes to our processes. And still I'm embarrassed that I even had three. But then I was brought up old school - heck, we bench-checked our code in the old days before we submitted a compile.

I expect no less than that level of craftsmanship from senior programmers. If your primary value-add from pair programming is to reduce bugs, especially in production, then I think you have far more fundamental issues. That's just me.

Its not as
simple as one person coding and another person just sitting there
watching. Its way more involved than that. To hold it at arms length
like that is not fair to the practice of pair programming, or honest about
what its application is or should be.

As I said, if pair programming is about reducing bugs, I think you have procedural issues that might better address the problems. If, on the other hand, pair programming is about training then it's probably an effective albeit expensive exercise. I don't mean to hold it at arm's length; I consider it a tool that can occasionally be useful, not a philosophy that should be adhered to rigidly.

Joe