Tag: programming

Iterative Delivery: Finish Something, Ship, Repeat.

I’m in the habit, and we (Oasis Digital) are in the habit, of having a lot of irons in the fire: many features in progress (in development) at a time, working a bit on each. There are good reasons to do this – for example, it helps keeps a team engaged, it avoids being “stuck” on a feature in need of customer feedback, etc.

But it is also a form of multitasking (which makes us stupid). It turns out that within certain constraints, we can deliver value to our customers much better by not multitasking, but rather by a focused approach:

  • Pick a small number of features, those most important to customer(s).
  • Bite off a reasonable small scope of each – if a feature is large (or even not-really-small), split it in to a part of finish right now and another part to put in the backlog
  • Work on them to 100% completion (delivered to the customer, done) of some useful scope
  • Repeat.

Of course, this is called “iteration” and we all know that’s like mom and apple pie. And yet… knowing something is good, is not the same as doing it.

Regarding the splitting of scope in to “now” and “later”: Some developers and teams are prone to use this as a way to not give the customer what they want. That is an abuse of the idea of iteration. Rather:

  • “Let” customers want what they want; you can’t stop them anyway.
  • Don’t try to talk them out of it.
  • Don’t try to avoid giving it to them.
  • Don’t look for ways to stall “forever”
  • Don’t look for ways to drag out the delivery of the first piece
  • Do work with them to split what they want in to a series of pieces which you can deliver iteratively.
  • Starting delivering pieces soon.
  • Keep delivering.

Published in 1987

Rummaging through old books (giving many away, selling others, discarding others) in an attempt to lighten the load I carry through life, I came across a rather weak book from 1987:

… in which I appeared in print for the first time. One short (1.5 page) chapter therein is from a submission I wrote for a contest for Compute! magazine at the age of 13. I didn’t make it in to the magazine, but was included it in this compendium, for which I earned total royalties of around $1. Some editing error (on their end) caused a few lines of text to be dropped from the middle. Click on the book above, to enjoy my 1.5 pages of fame.

Java Scripting Talk – Code, Notes, and Audio

Last night (9 Nov 2006) at the St. Louis Java User Group, I gave a talk on “Scripting Your Java Application”. As I mentioned, there were no slides, but rather a handout, the text of which is pasted below. You can download the handout (a tight, one page PDF), the code, audio of the talk (WMA), and audio of the talk (MP3, larger). The audio was recorded with my Olympus WS100 Digital Voice Recorder, so the quality is bearable but not great.

Update: As an experiment, I also had CastingWords prepare a transcript of the talk. It’s somewhat tedious to read (I didn’t edit it at all), but it is available as Google fodder rather than trapped only in audio.
Continue reading “Java Scripting Talk – Code, Notes, and Audio”

Software Development Team = Marketplace?

Some months ago, when deciding how to structure a software development project team, I lamented (offline) that what I’d really like the project to resemble is a marketplace – a community of developers all eager to find their niche. As the market clears, each developer would end up doing what they do best, maximizing their comparative advantage while also maximizing overall productivity. We know this works well on a national scale (capitalism), but in a sense, many companies are (internally) little islands of non-capitalism. By saying a team would work this way, I mean internally, in terms of how the various parts of each project are divided up.

Today I read that TopCoder, in addition to their well known programming contests, does something very close to this:

“TopCoder assesses a client’s needs, breaks the project into 30 or so components, and opens the design and development work to a series of online competitions. The coder with the best finished product wins “prize money,” as does the runner-up, which usually amounts to a few thousand dollars. The small pieces are “sewn” together, usually by TopCoder, and delivered to the client.”

Two issues come to mind though, one negative and one positive:

  • In the kind of complex “enterprise” projects we sometimes take on at Oasis Digital, binding together the pieces in to a coherent solution, tends to be a major aspect of the work. Sewing together disparate pieces could easily dominate the schedule.
  • A bunch of separate, talented developers, committing to building a system in this fashion, are likely to produce a highly modular system. It is hard to overstate the benefits of modularity in large projects.

Update… in my next 2 minutes of browsing feeds, I cames across a relevant post about another “industry” far outside my expertise.

Joel, you have got to be kidding

Joel seems to “play it safe” … then goes off the deep end of irony in his final paragraph:

“FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.”

Fortunately DHH saved me some minutes of typing about it, with a scathing commentary.

Over at Oasis Digital we use both common tools (.NET, Java, PHP, C, Delphi, etc.) and more unusual ones (Lua, Prolog, Ruby, sorry no Lisp yet), so I believe that puts us in the DHH and Paul Graham camp: If you want to win, you must be willing to do something different from the pack… such as, in an extreme case, creating your own language optimized for the task at hand, whether in the form of Lisp macros or a C# compiler for Wasabi.

Keep Your Development Focus Sharp

Brian Button recently suggested, for XPSTL, “a series of presentations where we discuss the biggest challenges we, as team members and developers for the most part, face in our day-to-day jobs with respect to being agile. The challenges can be in technical areas, organizational change issues, or whatever else people think is hard.”

I’ll bite.

First, some background: the context here is an agile but not XP project, with a widely distributed team. The software is sold in an “application service provider” model; we usually deploy updated software weekly, though our planning is not particularly crisp around iteration boundaries. We use source control, a build server, an issue tracking system (paper cards aren’t of much use in a distributed team), unit tests, a few acceptance tests, a mailing list, Campfire, Java, and Eclipse. We build and sell an “enterprise” software product, so our product management is driven both by meeting current customer-specific needs and general target market needs.

We have listed a great number of desired features (and tasks, and bug fixes), and grouped them in to a few large buckets, which are roughly “releases” in the XP sense of the word. A small subset of those work items are considered “To Do” items, i.e. items that should be worked on now, to be deployed it the next week or two.

The ongoing challenge we face is in disciplining our own desires – in limiting the list of what we will do next, to what we can reasonably expect to accomplish soon, and then to work vigorously on getting those things out the door. Thus our goal is to, at all times, keep the team focused on a relative handful (at most a couple dozen) of key things to work on now, to bring those items to end-to-end closure.

Our challenge is in the perpetual tendency to derail the process, in any number of ways:

  • As new issues come up, there is a tendency to throw these in the “do now” list, without regard to their importance in the backlog.
  • Items get stuck waiting for requirements feedback. Either get the feedback quickly, or kick the items off your “to do” list in to the backlog, and go work on something you can finish.
  • Items get stuck waiting for integration in to core code.Items get stuck waiting for a production / deployment task, because your team is hesitant to touch a production system. The solution is to test, test, and test again, then deploy (using whatever the local process is, for your team / project / organization).
  • Items grow in scope, as they are discussed and implemented. The fix for this is to split off the additional scope in to another item (XP card) and put it in the backlog to be prioritized; trim the work item in front of you to a reasonable size and get it shipped.

All of these cause an overall derailment not because they add “bad” items, but because they reduce the focus, and thus reduce the tendency to get items finished and out the door. My advice is to keep your (team’s) focus sharp.