This post was migrated from Justin’s personal blog, 'Codethinked.com.' Views, opinions, and colorful expressions should be taken in context, and do not necessarily represent those of Simple Thread (and were written under the influence of dangerous levels of caffeination).
Most of you reading this blog have probably seen the ALT.NET logo and its allusion to "running with scissors". Very clever, and as a software craftsman, I full agree with its sentiment. As smart, (and as Oren would say) consenting adults, we should be given the tools and flexibility we need in order to build awesome software. We shouldn’t have our hands bound, and we shouldn’t be artificially limited by the frameworks that we work with.
So as my discussions with Oren about my last post went on in the comment thread of his latest post, I started thinking about the different places that Oren and I were coming from. I also thought quite a bit about why I feel a strong compulsion to create strategies in my software design in order to funnel developers down the correct paths. As I thought about this more and more, I started to come to the realization that I was solving business problems in my code. And not the kind of business problems that we think of when we talk about creating rules and logic to solve a businesses needs, but instead, I was correcting for institutional deficiencies that I have seen in the past by coding around them.
Most of the places I have worked at have been fairly constrained environments. I have worked with a good number of awesome developers, but almost every company I have ever worked in has either had not enough time, money, or developers. Or all three. And in environments like that, things that many people see as being fundamental to creating good software sometime just don’t happen. Not enough unit tests get written, not enough code reviews get completed, not enough testing gets done before a rollout, etc… Corners get cut, and no one likes it, but unfortunately we don’t write our own paychecks. When, for instance, a new product needs to get rolled out, you don’t just tell the company that you can’t launch the accompanying website the same day as the product because you just aren’t ready yet. I can’t imagine a company on the planet where that would be acceptable.
I’d love to be working in an industry where those kinds of things don’t happen. There is a place that I like to call "Unicorn development shops", where management gives the software developers enough time and resources in order to always get the job done 100% every time, they might exist, but I’ve never seen one. And so the question begs an answer, unfortunately one that will likely never come, but is it okay for us to solve deficiencies in our development teams with code?
I certainly don’t have an answer for this. I know that I do it, as you can see from my previous post, I might even have a compulsion to do it. But is it the right thing to do? Are we better off throwing caution to the wind and picking up the pieces later, hoping that our team can grow along with us? Even as I am writing that last sentence I get this picture of a dev lead crawling up a mountain leading a heroic team of developers behind him. There really is something grand and heroic in that approach, relying on your fellow developer to rise to the occasion, take pride in their creation, and better themselves for it.
But is that realistic? In my experience, I’m not so sure. I’d love to hear your thoughts on it though, this is one question that I don’t really have a good response to. Or maybe I’m just exposing myself as a jaded cynic. 🙂Previous Post Next Post