Map & Produce » Discipline

I Was a Strange Loop

noel — Fri, 06 Aug 2010 16:31:59 +0000

Best part of fall 2009 in St. Louis? The two day geek rapture that occurred during Strange Loop 2009. I went to that very first one last year on my own dime, and it was a tremendously worthwhile experience. Good networking, lots of new approaches to software development, and lots of cutting-edge research and methodologies.

For two glorious days I rode my bike from my University City home, down 5 blocks to my favorite theatre, the classy Tivoli, and nerded out.

New languages that were self-proclaimed of questionable utility (humility is refreshing).

Simplicity (al3x, formerly of Twitter, gave one of the most thoughtful and grounded conceptual discussion I’ve ever attended, including my years attending academic philosophy conferences).

Awesome slides.

The open bar at Blueberry Hill and Strange Passions night were thoroughly enjoyable from both an academic and bacchanalian perspective.

Of course, you should have seen the shill approaching. Strange Loop 2010 promises to be bigger and better. Register today for $150, rock out in STL (I’ll even show you around if you’re out of town), and enjoy FREAKING GUY STEELE AND DOUGLAS CROCKFORD!!!1!!!!1

Seriously, this was by far the best conference I’ve ever been to, blocks from my house, and tickled multiple parts of my lobes.

Lessons in Scrum: Sneak Previews and Test Screenings

noel — Mon, 31 Mar 2008 04:19:32 +0000

We’ve been trying to use Scrum to manage our software development for the last six months. It’s work as far as we have let it (or as far as others let it), and I’m slowly clueing in to what should raise red flags in my Scrummified brain.

Recently the customer (chicken!) requested to schedule a couple of demos over the course of a sprint. I became very concerned.

Giving the customer demos at the sprint mid-point will encourages the customer to give feedback with the expectation of immediate implementation and delivery by the end of the sprint. We cannot sustainably support that. If the customer really wants a peek into what is coming in the next sprint delivery, then perhaps a demo at the end of the sprint development and before the testing and production deployment would work.

To borrow a movie analogy, we must maintain the difference between a test screening, and a sneak preview. The test screening, when a movie is shown for a small audience who gives feedback, is used when the movie is still being made. The sneak preview, when a film that is finished is shown before it is distributed, is used to generate excitement and approval for the finished movie.

In Scrum, a test screening should occur after a delivery & during planning for the next sprint. That is the time for customer feedback that results in products implemented in a sprint. A sneak preview should occur during a sprint in order to consolidate customer buy-in and get them excited about what is coming.

I want to make sure that the demo schedule during a sprint is a sneak preview and not a test screening.

Most Impressive

noel — Fri, 19 Oct 2007 04:52:53 +0000

When I took Formal Logic in undergrad, we had to frequently step up in front of the class and write a derivation or proof on the chalkboards which lined three of the four walls. Our professor called it ‘board work’. One day, after a particularly mid-morning tryst with S5, he stops class, surveys the amalgam of sweet symbols arrayed on the boards before him, and with glee proclaims, “Yes, I think we leave the boards unerased today. It looks impressive enough.”

Yesterday, my wife looked over my shoulder and saw this:

“Oh! It’s beautiful homework,” she exclaimed. It does seem impressive.

Like my yellow highlight color, we would do board work with yellow chalk. One glorious day, in the same yellow-chalked-equipped building but a different classroom, a history professor of mine walked into class a few minutes late, picked up a piece of chalk, snarled at it, threw it into the wall across the room whereupon it dissolved into sharp, white bows of dust. He swung around and proclaimed, “This is ridiculous. I can’t work with white chalk.” He then stalked out of the classroom. This 30-second whipsaw left us temporarily stunned. He never came back that day. We waited for ten minutes, and then left. I knew he was gone as soon as the chalk exploded into dust.

Sundry Wisdom Regarding Software Engineering, Design, and Incredulity

noel — Fri, 27 Jul 2007 13:38:23 +0000

Thanks to Coding Horror + commentators for reminding me to post my favorite quips and wit regarding software engineering. I’ll be occasionally adding quotes for my own inspiration, recollection, and possible self-justification.

Simplicity and elegance are unpopular because thy require hard work and discipline to achieve and education to be appreciated.

—Edsger Dijkstra

“Make it work.”

noel — Wed, 25 Oct 2006 04:46:56 +0000

I am so justified for the hour on Wednesday of every week this fall spent watching Project Runway.

IT: We Understand Business

noel — Tue, 25 Apr 2006 23:34:23 +0000

I have been surprised over the last couples of months to find out that there are IT departments and consultants that don�t really understand how their law firm does business. In some of these places the standing excuse uses the size of the firm (> 200 attorneys, etc). Whatever; that’s not how we roll here.

That’s a bit of a crow for me, but to be transparent my na�vet� is due to the unquestioned commitment of my coworkers and managers to accurately capturing, understand, and wisely implementing business processes and requirements for IT initiatives. In my experience, the software we write is only as successful as the business process it embodies. When we are off the mark or the process is broken, our software is a mangled zombie corpse. When the process is good and our software captures that, it sings a sweet aria.

Towards reflecting the importance of correct understanding of the business of law firms, Adam Smith, Esq revises the list of top CIO traits to put understanding at priority #1.

Writing Software As Digital Rhetoric

noel — Mon, 24 Jan 2005 23:18:50 +0000

The art of persuading computers to do what you want them to. That’s one of my internal definitions of what writing software means.

When people ask what I do, my past response has been that I am a programmer for a law firm. This is not comprehended well, so I’ve been toying with different ways to describe what I do. A tougher-than-it-looks task. I have settled on the claim that �I write software that is used by a law firm.� This answer reels in more comprehending faces and lighter eyes. What is different between a “programmer” and “writing software”? Well, the latter describes an action while the former is a noun.

Further, there’s the idea that what I do is somewhat orthogonal to what a writer of novels, or short stories, or essays does. I plot, I outline, I adopt the most persuasive line of argument. I practice rhetoric on the computer. Seems like a good heuristic to hang my hat on for most people.