Friday, February 26, 2016

Software Development Best Practices Aren't

Every once in a while I hear someone mention, in relation to developing software, that we should follow "best practices".  I often wonder if the speaker is just couching their suggestion in vague language because they have no idea what it means or if they really think there is some grand list of "best" practices that everyone should follow to guarantee success.  Really, there's two types of programming practices: "hipster" (or bleeding-edge, unproven, ooh-squirrel, or whatever you want to call the new shiny) and "legacy" (the stuff the old guys do because it works, but it's boring, and really a lot of times it's kind of crappy, but it's a known evil).  I think there's some imaginary middle ground there where "best" lives, but it's such a moving target that nobody can hit it.  Just in my time as a developer, web development has gone through at least these "best" practices:


  1. LAMP stack (Linux, Apache, Mysql, Perl)
  2. LAMP stack (P is now PHP)
  3. MVC Frameworks (Ruby on Rails, Django, etc)
  4. Async all the things (memcached, node.js, nginx, etc)
  5. MEAN stack (Mongo, Express.js, Angular, Nginx? - I forget)
  6. Single-page apps
  7. MSA (Micro-Service Architecture)
  8. I could go on, but I won't
Which of those is the "best" practice now?  I honestly don't know.  I'm totally ignoring the insane number of client-side frameworks that have come and gone (prototype/scriptaculous, yui, dojo, jquery, angular, gwt, meteor, I'm forgetting about a thousand).  RSS was cool, then it was all SOAP, but SOAP was too complex, so XML-RPC, but wait, we hate XML, so RSS again, wait Javascript is easy and XML is basically a piece of garbage, so JSON, and why don't we just use HTTP for its designed purpose, so REST all the things!  Chroot works for sharing hardware, but no we should use VMs because security, oh wait VMs actually have a lot more exploits than containers, and containers are more performant, and ooh neat, Docker makes them not painful, and ooh Google uses containers. Configuration management for a fleet of servers is hard, so cfengine, but Perl is icky, so Puppet/Chef, but Ruby is ugly so Ansible/Salt, but centralized servers don't scale that great, so Consul/etcd. And service monitoring, and metrics, and distributed filesystems, and and.

Don't get me wrong, a lot of the things in there are neat and could definitely prove themselves long-term, but just given how quickly the community has rallied around some of them and then dropped them like Neil Degrasse Tyson dropped the mic on that clueless rapper just as quickly, I'd guess that you shouldn't be adopting half of them just yet.  And often the better technology loses to the one with better marketing, or the one that's easier to get started with. 

So, the next time you say "best practice" about software development, you might want to clarify what you think is "best".  But be prepared for a lot of people to think you're the dumbest person that ever lived because you don't use whatever pet technology they think has redefined the game.  Because that will happen if you work with other developers or engineers.

Remember, when people say "use best practices", what they really mean is "do things my way".  Software engineering is a relatively young discipline, and technology moves so rapidly that there is no "best" way.  Build it the best way you know how and try to learn a few new things in the process.  Get feedback via code reviews to learn from others with different backgrounds.  Try new things, see where they improve upon the old and where they fall down because they haven't had the time to harden.  Keep moving forward, but don't abandon everything you already know to work well.  That's really the "best" practice you can do.

Good luck!

No comments:

Post a Comment