A former coworker of mine, Jim Highsmith, has recently written an article on The Financial Implications of Technical Debt. Jim states that recent studies indicate the cost of technical debt is near $1 trillion in the U.S. I would like to see these studies. I do know that not too long ago, Gartner released a report indicating that the worldwide cost of IT Debt will be $1 trillion by 2015. Regardless, the point he makes is still valid - technical debt is egregious.
Jim states, "Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement."
Of these three (bad) options, I think the second is often a better choice than the third. The first represents failure to make a necessary decision.
Training Software Professionals
Here is the slide deck to my SCNA talk, "Training Software Professionals, Just What the Doctor Ordered". In the past, my slide decks stood on their own. That is, you could thumb through the deck and easily glean all the key points of the talk. But I am trying to move away from that presentation style to one where the slides offer visual support, but the speaker (me) tells the actual story.
Uncle Bob on Humility
The following just hit my inbox. It is a post on the Software Craftsmanship Google Group.
On Oct 24, 2010, at 12:36 , David Starr wrote:
My question is, "what can be done to fix the reputation [of elitism] and change the conversation before craftsmanship is deemed irrelevant"?
Uncle Bob's Reply
As a craftsman I am dedicated to improving myself; and therefore I realize I am deficient. As someone who is admittedly deficient, I am not interested in pointing out someone else's deficiencies.
In general, whenever someone asks "what can we, as a group, do to ...", the best answer is going to be of the form: "Each of us, as an individual, should ...".
So, to deal with perceived elitism, each of us as individuals should remember that we are not elite.
Packing Peanuts Game - Variation
Code as a Cause of Project Failure
During the speaker panel at SCNA this past weekend, Chad Fowler (@chadfowler) asked, "How many projects fail because of the code?". Given the context, I assumed he was making the point that projects fail due to business issues, not code. The room was silent. While one might have assumed this meant the entire group thought it rhetorical, I concluded everyone agreed with Chad. Projects fail not due to code, but due to business issues.
On The Scrum Compliance
A recent article by Tobias Mayer has been getting a lot of attention. "The Scrum Compliance" is an accounting of why Tobias is moving on from the Scrum Alliance. This article is not the first on the ugliness that has become the Scrum Alliance.
Esther Derby asks: Are we aiming too low?
Esther Derby put together a nice post on the importance of design for a web site in which she asks, "Are we aiming too low?"
Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?
Technical Debt versus Cruft
I repeatedly find myself in discussions with really smart and experienced people regarding Technical Debt. And I consistently find myself ranting about how cruft and technical debt are not the same thing. I am beginning to feel I am merely tilting at windmills.
Values Revisited
In 1992, I started a custom software development company out of my basement. I started it because I was angry. At a relatively young age, I was already keenly aware of the gross dysfunction that existed in most organizations. I didn't want to be a part of that. I wanted to be a part of something different; something better. I had no plan, but I had an abundance of temerity.
A blank wall and a fist full of index cards
Motivating the Unmotivated
I read a post recently from teknophyl entitled "Motivating the Unmotivated". He asked me to read it and give him some feedback. I started a reply in the comments and realized this one was going to take some time.
I encourage you to read his blog entry. I am willing to bet it will resonate with most of you, either as a participant in a similar series of events, or at least as a witness.
Excellent Developers Are the Best Hires
I recently read a post wherein the author was condoning the hire of excellent programmers with abrasive personalities over bad programmers with cordial personalities. Superficially, I agree with this advice as it is ultimately better to have an individual who does their job well and delivers over an individual who you get along with very well, but who cannot produce.
A false dichotomy
The notion that you must choose between great developers with bad personalities or bad developers with great personalities is just plain false. The dynamics involved are far more complex than that, but let's assume for a brief moment, that there are only two criteria any company hires on; raw skill and congeniality.