Category: Business

Dual Monitors – Worth Every Penny

As I write this in 2006, it is a very late post. Back in January 2003, I got a major PC upgrade: two 19″ LCD monitors and a dual-DVI video card to drive them. This was somewhat less common (and much more expensive) in 2003 than today. The monitors are “Samsung SyncMaster 191T”. I took this photo at the time, meaning to post it:

Dual monitors are a remarkable productivity tool – I am confident that this upgrade paid for itself within the first few months of use. Another developer here at Oasis Digital uses three screens; I’m planning to go that direction, or two larger screens, next time I upgrade. I’ve since moved to a faster computer, but I’m still using these monitors.

For best results, don’t even think about plugging LCDs in to analog VGA – the difference between analog and DVI is immediately visible and stark. I’ve seen many sources online claim that DVI is only a minor improvement; I find this unfathomable.

I use and recommend Ultramon for making best use of multiple screen – it seems to work better than the similar software which ships with some video cards.

Reimplementing Good Ideas

A while back, Weiqi posted about Eric Burke‘s comments about Wikis; one point being that “WikiWordLooksStupidAndAreNotNormal”. I mostly agree with that, and the Wiki tool we’ve been using recently, MediaWiki, supports non-WikiWords trivially. Eric is working on new Wiki software that sounds quite compelling.

The notion of needing some new software with which to set up a Wiki-repository for misc. project-related information seems a little behind the times. I set such a thing seven years ago, in 1999 – and it was old news then.

I have a personal aversion to re-solving such a well solved problem; it feels like duplication, which I have deep aversion to in code, to the extent I’ve held on to this snippet from a post by Ryan King on the TDD mailing list in 2002:

“So, duplication sucks. The more rabidly a person hates duplication, the more I trust their opinions on managing information. A programmer, upon noticing some redundancy, should be thrown into a panic, begin hyperventilating, and stammer something about “¡El diablo! !El diablo está en mi software!”.”

And yet… I have done such things myself many times – for a while in my early days of programming, I implemented a text editor a couple of times each year. There’s something deeply valuable in the experience of building something yourself, I think it is a mistake to dismiss such efforts as “Not Invented Here”.

Emergencies, and How to Kill Creativity

A post over at Slow Leadership: Slow Leadership: How to Kill Creativity is closely related to a “rule” we have at Oasis Digital: we have a limited “budget” of emergencies; we will spend no more than a small percentage of time in “emergency mode”.  If there appear to be so many fires that that the team spends most of its time fighting fires, we first review who is doing what work – and usually find that most of our developers are mostly doing the right things in the right way.  There is a bit to be gained by “trying harder” – in the short term.  The real solution is not to try harder – in fact that approach almost never works over time.  Rather, the solution is to slow down and get to the heart of the matter, which is usually some variation or combination of:

  • The software doesn’t have the right features to handle unusual situations or inputs gracefully.  Add them.  Make it so our customers/users have the data and features they need, to deal with new situations directly, rather than those situations becoming our emergencies.
  • The software doesn’t have the right documentation and training, to enable its users do deal with new situations directly.  Add that documentation and training.  Users are often far smarter and more capable than the typical software developer gives them credit for.  We have repeatly been amazed and thrilled at what our customers have been able to accomplish when handed even the roughest of tools and explanations.
  • Our software has a deep mismatch to the problem it is intended to solve.  Change it… even if it means something scary like rearranging the core of a large DB schema.
  • We don’t have the right team for the problem/project at hand.  Swap someone around.
  • The team isn’t big enough for the problem.  Grow.
  • The problem is too big for the team/budget.  Trim scope, do a great job on the new scope, then consider expanding it again.

By doing these things, we apply more brainpower / creativity to automation, innovation, and genuine progress on the problems at hand.  This is the antithesis of the “pressure based culture” described in the article linked above.