Category: Business

$200 -> Inno Setup

I’ve been using Inno Setup to build installers for a variety of projects for 5+ years, for both personal and commercial projects. Inno is very high quality software, extensively debugged and robust. I prefer it to the other install-builders I’ve tried, including NSIS and various commercial packages (some of which are truly awful).

When I saw this discussion on Joel’s discussion boards, I realized that I too had benefited greatly from Inno yet offered nothing in return. So today I sent $200 over, and I encourage anyone else using Inno to support the project also.

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.

The World is My Warehouse

My Old Way of Thinking

Until recently, my strategy for deciding what possessions to keep has been simple: to a first approximation, “keep everything forever”. There is family history in this direction, so I come by this honestly. I have kept many pieces of equipment, cables, books, magazines, tools, office supplies, and much more. There are 200 square feet of shelving in my basement (including my data center), that’s 19 square meters for those of you in the rest of the world. Applied to books, this strategy means that I keep every book forever, in case I ever want to read it. I’ve been building up a library.

I have seen the light, though.

My New Way of Thinking

If it is something unique in the world, or too expensive to replace, or I use at least every couple of years, keep it. Otherwise, give it away, sell it, or discard it. The world is my warehouse. If I need it back I can buy it again; statistically I will buy back only a tiny fraction of what I get rid of, and at low cost. Again, a book example: most older books (including dozens I have gotten rid of recently) are readily available at a fraction of the cover price, if by chance I need them again.

Life (and business) must be about the future. By tossing residues of the past out of the way, more capacity (physical and mental) is available to pursue what matters now.

Update: I thought back to this post when I read Paul Graham’s Stuff essay in July 2007.

A Few Days Away, a Fresh Look at Email

On my office PC, I have a complex, tuned mechanism for processing email: many filters, many folders, etc. I check email at least a couple times per hour (sometimes every few minutes) and tend to send many short replies to message threads.

When I travel, my email processing is much simpler: check email a few times per day (or much less, depend on whether it’s business or pleasure travel). All incoming messages land in the Inbox. I read, I delete anything I won’t need, then file each remaining messages in to one of two folders: “Stuff to file when I get home”, “Stuff to act on when I get home”. (The idea of filing everything in one folder has a lot of merit, which I’ll explore someday when I find a local email client which handles that model as well as Gmail.)

During my trip last week, following the process above, an important aspects of my “email life” became much more obvious: I receive an enormous number of messages that only peripherally relate to me – mailing lists, automatic notifications, etc.; and dealing with those messages takes too much time. This fact, so obvious when it all lands in the Inbox a few times per day, had been hidden by my filing system and rules, and by spending a few minutes time all through the day and evening on email.

So I trimmed, radically: I unsubscribed from lists, I turned off automatic email notification systems, etc. I now aim to let several messages build up about a topic, them write one well-considered reply instead of multiple fast replies, seeking quality over quantity.

On a related note, I also let the many RSS feeds in my reader (FeedDemon – a great product) build up while away, so that when I return, I have N days worth, rather than reading every day. In the past I’ve slowly caught up over several days. This time, I used the large buildup as an opportunity to more clearly see which feeds have the most value to me… and unsubscribed from many others.

I wrote the above in the first person, but I think it is good advice in general: guard your inputs, periodically take stock of overall incoming quality and quantity in to your inboxes. What enormous time sinks are hiding in your email rules/filters/folder system?

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.