Don’t Rush to the Keyboard

A client asked for my opinion regarding a need their team had, which could save them several hours of their top people, every month.

This was a relatively simple and interesting problem to solve. It would’ve been easily accepted that this could be spun up as an internal tool by someone on the team very quickly (“There’s no way it’ll take more than a day to get that running!”). Some consultants might even try to take on the work to whip this little tool up (no business is bad business, eh?).

We’re keyboard-trigger happy.

But, assigning someone to solve this means they’re not working on something else. And, please, when is the last time that something was really just “a day” to get up and running? What happens when there’s an AWS outage and you need to spend half a day trying to remember how the thing should be started up again? Or, of course, when the person that did it moves on and you inevitably need changes made?

Instead, I pointed the client to a handful of SaaS options that would solve at least 80% of the need, and that the cost of “a developer’s day” would pay for a year (or more) of usage.

Yeah, writing code is fun, but make sure your people have fun writing the right code.