The Carnival of the Agilists has posted a new issue. Every two weeks, they post a pointer to the interesting articles in the Agile arena. If you can’t keep up with all the blogs and mailing lists and online publications, this is a good way to hit some of the high points.
I’ve never really liked stored procedures. I always put it down to the fact that I’m a programmer, not a database person. I like keeping the functionality in the code. The database is just a place where objects go when they sleep.
My current client uses stored procedures for all database reads and writes. It probably made sense when the code was ASP, but Java JDBC code has all the expressibility you could want.
Today, I learned a new reason to not like stored procedures. Read More
Esther Schindler, a senior editor and columnist at CIO.com, recently asked on the agile-testing yahoogroup,
If you could get the (client) boss(es) to understand JUST ONE THING about computer consulting and contracting, what would it be?
It would be that software development is not a commodity. The cost-value equation is not just enhanced by cutting costs, but more effectively, by enhancing value. It’s not just a matter that software is produced, but what software is produced. Does that software clearly express the nature of the business? Is it an asset that can be extended and adapted as the business grows and changes? All too often, the only measure applied seems to be the hourly cost of the software production (neglecting even the number of hours required). Too often I get the feeling that I, the consultant, pay more attention to the long-term value to the company than do the employees and executives of the company. Read More
So much of life, even so much of software development, comes down to interaction with other people. And a big key (perhaps the big key) to this is building relationships. David Maister says some very interesting things on this topic–things that hit home with me. I’ve been meaning, for some time, to comment on an interview he gave on another site. While I’m waiting to get around to that, let me point you to this wonderful podcast (available in audio and video formats). Go watch it; I’ll wait. Read More
There’s been some discussion on the XP Yahoogroup about the practice of “blocking” in order to protect an Agile team in a non-agile corporation. I’d gotten rather behind in my reading, and came into the middle of the discussion. I’ve just now tracked this discussion back to a post by Scott Ambler, where he says,
This is a great example of something that I call blocking, where you produce the paperwork, attend the meetings, pretend to care, … to make it look as if you’re following the “official process”.
Scott is responding to a mention of the use of PERT on the Polaris submarine project. Scuttlebutt says that PERT was deemed a great success in managing the Polaris project, but in reality the PERT charts were reverse-engineered from more seat-of-the-pants management techniques. As the stories go, this “scientific” management technique wowed the Congressional oversight committees, and such techniques have been the backbone of government contracting oversight ever since. Read More
There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.
So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.
The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.
I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. Read More
Jerry Weinberg said this a couple days ago (and probably many times before that, but that’s when I heard it). Today, I have a story to illustrate this. I also have a puzzle to solve about how I may best avoid this same trap. Read More
Ron Jeffries, when someone asks for data to “prove” that XP or some development practice works, is wont to say that the person they’re trying to convince may be asking for evidence, but it’s not likely that the evidence will convince them. Read More
Software’s nature is to be invisible, unless we work to make it visible…. During a construction project, we can see the building rising; but during a software project, all we may be able to see is a programmer staring at a screen.
This got me to thinking, as Jerry’s writing generally does. Read More
… and fruit flies like a banana. It’s amazing to me that it’s been three weeks since my last post. Sometimes real life has a way of consuming the time, leaving little left for philosophizing.
During this time, Brian Marick has been stirring things up at the Agile Alliance. I’ve joined in the discussion of his observations and proposals only a little. Brian’s turned over a lot of stones at once, and it takes me awhile to examine all the things that have been living under them. Being a Myers-Briggs introvert, I tend to discuss these things in my own head before displaying them to the world. Here, though, I’m just thinking out loud and I haven’t come to any conclusion. Read More