Things for the DIY programmer to consider

Another thought-provoking post on Thinking Faster - he sounds like my business doppelganger ...

When considering the option to build vs. buy, or at least involve corporate IT and/or experienced developers, most folks with a business background miss some key considerations about their approach:

1. Is robust multi-user required? Excel spreadsheets deal with this challenge rather effectively - like a book, one user at a time. Access opens the door, but most business developers don't appreciate common multiple user issues like record locking.
2. Does it scale? Related to #1 above - how many records until the spreadsheet or database starts to show some strain? Also, with databases, the tradeoffs for multiple indexes (report / query speed vs. transactional overhead) are typically not considered.
3. Version Control, Configuration Management, and Deployment - Getting the software to work on your own machine is quite different than managing the ongoing maintenance and deployment to multiple machines.

I suppose I could go on, but those are usually my favorite three gotchas when working with internal groups.

Now, hopefully I don't sound too elitist or dismissive of folks that want to do internal development like this. On the contrary, I applaud their aggressive nature, encourage their application of technology to business, and appreciate the cost / time-to-value argument they can often make. However, it is our task in IT to make sure the Total Cost of any technology decision is thought through.

One passing comment - I just love it when folks say "but this is such a great idea ... maybe, when it's done, we could commercialize it!" It never fails - it has happened in every company I've ever worked for ... ah, the lure of miniscule COGS (hey, blank CDs are cheap, right?). I then get to regale them with tales of woe from my developer days ...

Technorati Tags: development, TCO, cost, scale, internal