Just because you can, doesn’t mean you must.

I was working on a problem recently and happened across a conversation in the ddd-cqrs-es slack channel that reminded me of a blog post I read a while back. It reminded me that part of being a good software architect is recognizing that sometimes a software solution isn’t the best solution to a problem.

The blog post was from Rinat Abdullin (of Lokad fame) from several years back. You can find the post here.

My thoughts

Over the years, I’ve had a few experiences (probably an understatement) where as a developer I spent a large amount of time solving a business problem with code, only to have a really bad taste in my mouth once I finished.  I often thought to myself “man, I’m pretty sure I could have just put a button here and had someone click it when they wanted, and things would have cost way less and the business would have been just as happy”.  I’m sure we’ve all had this feeling.  This is a good feeling, it isn’t a reflection (typically) of your lack of skills as a developer or your inability to gather good requirements.  Often it’s just a result of the continuum that is software development / automation and the fact that sometimes the cost of automating something outweighs the advantages of doing so.

Now…. don’t all you devops / agilist people get all upset about this – and don’t you folks who don’t like devops or feel like you do too much automation use this as an excuse to rail against the devops movement.  There are certain things that you can always say may be cheaper to do manually than to automate, but that’s not really what devops is about.  Devops and automation in your build, deployment, and release processes is all about repeatability, consistency, and the 4am problem (Imagine being woken up at 4am, half-drunk after a friend’s birthday party and you have to do an emergency patch and for some reason the on-call person can’t do it.  Do you really want to “hope for the best” when releasing and deploying that fix?).

I’m just saying, that sometimes the business complexity (rules, etc.) around a process are too undefined, too complex, or changing too fast and sometimes it’s best to automate 99% of the process and leave the rest to the user.  A good test of this is asking the question of “where is the value” in the automation, is it making it so the user doesn’t need to click the button, or is it making it so some process that took days or weeks now takes the 5 secs to find and click the button?

After writing this post, one of our friends mentioned that Greg Young discussed a similar topic on his keynote at BuildStuff Odessa.  I wasn’t aware of this keynote at the time, but I recommend checking it out if you happen by here.  The keynote video is here.

Kelly Leahy (@kellyleahy) is Adaptech’s Director of US Operations. 

Comments are closed, but trackbacks and pingbacks are open.