Apologetic Agile Development

-
Having lived through numerous attempts to build software embracing the concepts behind the agile manifesto, I feel there are three large categories folks fall into when talking about agile principles.
  1. The curmudgen - these folks have been writing code since punchcards where the state of the art, OR they have been brainwashed by large consulting organizations into thinking that a large heavyweight process is the only way to succeed. Note, a subset of these folks believe that "no process" is actually OK and are quite happy to cowboy-code their way through life.
  2. The fanboy - these folks think "everything agile all the time" and will rename status meetings to "scrums". These are folks who are used to working solo on projects that they can do in their heads... or they are simply not clued into the implications of actually having a repeatable process or delivering working software.
  3. The apologetic - these folks understand the principles and the value they provide, but also understand that these principles are the important thing and know that the current state of the art of software development is still very problematic. These folks often complain or quip that they are not doing "real agile", but accept that using some of the tool and principles coupled with more traditional principles, tools, and processes has much more value in most cases
I'm squarely in the apologetic camp (my ego transposes apologetic for pragmatic BTW), and while I feel I have a good understanding of where and how agile can deliver value, I also understand that many times agile gets sold as a magic bullet that never delivers completely on it's promises. I think this is a mistake: No process, methodology, or tool is perfect, folks who complain that "agile" causes problems in their projects or doesn't solve problems that they have are completely missing the point. No process, principle, or methodology should completely dominate your software development philosophy and enlightened developers should stop apologizing.

Comments

Anonymous said…
Having read two of your articles, it's clear you have to learn it's important to know the difference between its and it's.

its - possessive
it's (contraction, substituting two words, it is)

Your articles are spot on otherwise ;)
May 17, 2013 at 8:33 AM
Mike Mainguy said…
LOL... its common for me to improperly use the apostrophe and often need a reminder of it's importance :)

May 18, 2013 at 8:59 AM
Jeff said…
If it makes you feel any better, there is a mom-and-pop hardware store, Read Bros., in Henry IL, which has had the same slogan on its storefront since the 1950's: "The Only Store Of It's Kind."

For decades I have fantasized climbing up there under the cover of darkness one night and removing the apostrophe.
May 20, 2013 at 3:36 PM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u
Read more