Speaking of Reg Braithwaite, in this post he touches on team size and productivity. There are so many gems there, I could comment on just about every sentence, but I think this is my favorite:
If we know that bug per line of code remains amazingly constant, why do we try to scale code out in verbosity rather than up in abstraction?
I’ve very often wondered the same thing.
When I’ve given talks about dynamic languages and productivity, I’ve sometimes brought up the “bugs per line of code” constant. With dynamic languages, I generally write far fewer lines to solve the problem than I would in Java or C++. While that alone doesn’t guarantee correctness, of course, in my experience it sure seems to lead to solutions that are completed faster and with fewer bugs. Yet in those presentations, I’ve always gotten pushback on that idea from someone in the audience, typically based on the “static typing will save you” argument, which I’ve never fully understood despite having written, read, and fixed tons and tons of statically-typed code over the course of my career. First, the notion that you’re generally likely to have more bugs if you have more lines of code just seems like common sense, since there are just more chances to be wrong. Second, static typing does nothing to help ensure that you’re applying suitable algorithms and are correctly solving the problem, yet that’s where the bugs tend to be.
But it goes beyond bug counts — sometimes it even comes down to getting a solution vs. not getting one at all. The fact that you can quickly visualize and produce a solution in Python or Ruby, for example, means you’re a lot more willing to actually sit down and crank out that solution in just a few days, rather than agree to take on a multi-month multi-person task to try to drive that nail with a Java or C++ hammer. Not to abuse another cliché, but I truly have been there and done that, believe me.
Postings like these often seem to attract comments of the form, “Well, dynamic languages are just too dangerous; we have several hundred programmers and we can’t watch everything that every one of them does.” I think that’s precisely Reg’s point! But this also gets to another related issue, which is that if you build teams that you can’t or won’t trust, you’re simply creating a self-fulfilling prophecy. You’re essentially expecting your teams to fail, so they will. In that type of environment, you’re just not going to be able to attract or keep anyone that you actually can trust. Furthermore, if you’re that type of manager or leader, not only is the likelihood that you’ll be able to scale your organization quite low, but you have nobody but yourself to blame for the eventual failures you’re sure to encounter. Issues related to dynamic languages and static typing are the least of your worries. Rather than tying your developers’ hands, it’s far better to devote continual effort to instilling common values and culture across the organization so that your teams can work toward common goals without requiring constant centralized oversight. Read Peter Senge’s The Fifth Discipline for great insight into this area.
For me, dynamic languages mean increased productivity. It’s as simple as that. It’s because the programming languages I use actually can do this, and because succinctness is power. And if you’ve never actually tried developing real software in such languages, that’s too bad, because that power — that productivity — really is quite amazing.