The term Technical Debt was created by Ward Cunningham to describe the engineering trade-off’s that software developers and business stakeholders must often make in order to meet schedules and customer expectations. In short, you may need to use suboptimal designs in the short term, because the schedule does not allow longer term designs to be used. As a simple example, your initial website design may need to be frames based because you don’t have time to build an Ajax framework.

Clearly this causes a debt. If the customer is looking for a web 2.0 system, then frames just aren’t going to cut it for long. So time is going to have to be carved out of a future schedule to refit the system with an Ajax solution.

In short, the business has decided that it can afford to delay release 2 in order to accelerate release 1. Is this wise?

Programming Scala is finally available online at Amazon, O’Reilly, Safari, and hopefully at other online and physical bookstores, too. If you have trouble finding it, just memorize the ISBN, 9780596155957, to aid your search. ;)

You can download the complete code examples here. If you want to “try before you buy”, see our labs site.

I pitched the book idea just over one year ago. Alex Payne, my co-author, was also talking to O’Reilly about a book, so we joined forces. It’s been a fast ride.

This book is for you if you are an experienced developer who wants a comprehensive, but fast introduction to Scala. We try to convince you why we like Scala so much, but we also tell you about those dark corners and gotchas that you’ll find in any language. We even preview the forthcoming 2.8 version of Scala. I hope you’ll give Programming Scala a look.

Scott Ambler wrote a blog, and an editorial about the dirty dealings and desperate deception of the Scrum Alliance and their slimy certification scam. He rightly points out that the certification means little more than the applicant’s check didn’t bounce.

He goes on to imply that the entire agile community is guilty of keeping silent while this huge chicanery was foisted upon an innocent industry. He calls this conspiratorial silence: “integrity debt”.

Oh bollux! What an incredible load of Dingoes Kidneys!

InfoQ has posted the video of my talk at last year’s QCon San Francisco on Radical Simplification through Polyglot and Poly-paradigm Programming. I make the case that relying on just one programming language or one modularity paradigm (i.e., object-oriented programming, functional programming, etc.) is insufficient for most applications that we’re building today. That includes embedded systems, games, up to complex Internet and enterprise applications.

I’m giving an updated version of this talk at the Strange Loop Conference, October 22-23, in St. Louis. I hope to see you there.

For years authors and consultants (like me) have been telling us that functions should do one thing. They should do it well. They should do it only.

The question is: What the hell does “one thing” mean?

Just finished first draft. More to come, questions/comments appreciated.

http://schuchert.wikispaces.com/tdd.Refactoring.UiExample

Dean, Uncle Bob, Michale Feathers and I will be spending time in our Agile 2009 booth working on problems and pairing with volunteers.

If you’d like to join us for some pairing, please stop by.

We’ll give you an autographed “code monkey” for your efforts.

“Welcome!” said the Master to the Journeyman. “It has been long since last you were here, and there is much we can discuss. I trust your journeys have been interesing?

“Indeed they have, and I have much to show you.” The Journeyman replied. “And I see you have a new Apprentice!”

“Yes indeed, a fine lad who has been helping me with my projects. He learns quickly, and his practice is true.” The Apprentice said nothing, but nodded to the Journeyman and sat quietly as his two elders conversed.

“What then have you to show me?” Said the Master.

Over the past few days, I’ve been tinkering with a little project I’ve called vih – it’s a vi clone written in Haskell. Here’s the git repo.

The way I’ve started it is rather naive, and frankly I’m surprised I that I had gotten as far as I did without curses and with the simple data structure I choose. Rather than using a clever representation for a buffer, I decided to just use a String. What this means is that every time a character is inserted into a buffer, the whole thing is split and reconstituted. I’m not using Data.ByteString or Data.ByteString.Lazy either. I suppose that I’ll move toward a more sensible data structure in a while but right now typing is comfortable even with all of that work going on.

My intention in doing this was to start to get a sense of how data structures evolve in Haskell by growing something large from a small seed. The primary data structure that I’m using right now is called EditBuffer and I notice that quite a few of my functions translate an EditBuffer to another EditBuffer. This seems to work fine, however I find that I almost always have to label the buffer in the argument list and deconstruct it. I haven’t seen pervasive use of labels like that in Haskell code I’ve looked at, so I’m wondering if my mapping of functions to data structures is odd.

Right now, vih supports insert and command mode (toggled with ‘i’ and ‘ESC’), the h, j, k, l cursor movements, line deletion with ‘dd’, home with ‘gg’, end of file with ‘G’, `in line’ positioning with ‘0’ and ’$’, insert new line after with ‘o’, and delete current char with ‘x’. No file I/O yet.

Have a look, fork or contribute.

I found a bug that couldn’t be tested yesterday.

There is nothing quite so satisfying as isolating a bug, writing a test that fails because of that bug, and then making the test pass by fixing the bug. The fact that the test is passing is proof that the bug is fixed. The existence of that test in the test suite ensures that the bug will never come back again.

For ten years I have worked this way. For ten years I have taught, and coached, and otherwise cajoled software developers to work this way too. Sometimes those developers would ask me about bugs that couldn’t be tested; and I would reject the whole concept. “If you can write a line of code, you can test that line of code.” I would reply.

But yesterday I found a bug that I couldn’t write a test for.