A few people were discussing a post talking about monkeypatching over at Coding Horror. The article touched on the aspect of how much things should be dictated by the so called experts and how much power the masses should have.
I see two different cultures at clash here: the open-source-minded one, where experimenting and randomly writing code that does cool things is good, and the corporate goal-oriented one, where experimenting and randomly writing code that does cool things will likely blow up the budget of the project.
I think both sides have perfectly valid arguments: on a higher level, you want innovation, and giving all developers free reign over your language helps them quickly express what they want the program to do, and just like in the infinite-monkeys-on-infinite-typewriters experiment, something good is bound to come out. But when you consider monetization, especially as projects require more people, you need to take into consideration that doing things unusually will almost always cause a lot of (not-necessarily-brilliant) people to waste their time trying to figure out what was done, when it comes to maintainance, testing, bug fixing, whatever other cycle.
So where is the middle point of all this? I suppose it's talking to your team.
Well said. The open-source minded, trial-and-error method of doing things is not really very efficient when there are deadlines to meet and customers to make happy. Things like static typing and other security-minded aspects are other great things for productivity when dealing with large scale projects. Having tried to do a medium-size project in Ruby, I eventually got fed up with typing problems and restarted the project with C++.
ReplyDeleteFreedom in a programming language is better when there is less of a cost involved in the software developed with that language. In the open-source world, the cost is simply the time of the programmers, who are doing something they enjoy anyway so the cost really is negligible. Also if nobody uses the software, the only loss is perhaps in the programmer's ego. This is not the case when developing software for a business.
I give you the following conjecture:
ReplyDeleteIn business you can have it both ways as follows: you can use tools that permit freedom for programmers but be very conservative in your own personal choices on the project-specific code. So for example, you might use Scala or Python or Squeak, but you will be conservative in your own coding.
However, you can take advantage of the power in the tools another way, by cherry-picking frameworks, plug-ins, gems, and other open-source components for your project. Let other people take the risks.
A very practical example might be choosing Ruby and Rails, but not doing any metaprogramming yourself, just using the metapropgramming that comes out of the box.
This gives you a middle way between trying to hit a home run with all the freedom afforded by your tools and trying to avoid disaster by picking tools that constrain programmers to a narrow band of productivity.
That's a good point, and I'd say it's effectively what happens in businesses that choose to use Rails or Lisp or whatever other expressive language.
ReplyDeleteThere's one aspect that I think gets overlooked sometimes though: that 3rd party libraries can sometimes have monkeypatching that break your stuff, or worse, that have undesirable effects that only get discovered in late cycles of your project. I suppose that's a matter of leaky abstractions, which is a whole other beast :)
Frankly, I have SEEN Java code. I have seen people use string methods to handle XML. I have seen people write 10 rules and still fail to handle what could be handled by a single rule.
ReplyDeleteSo, really, I find all this discussion irrelevant. The bad programmers I have to endure are perfectly capable of screwing up with very basic Java. They won't KNOW advanced stuff. And whatever advanced screw up one comes up with, it just won't measure to the basic screw up people do.
In that regard, I'd rather have a very difficult programming language. It would at least filter out the worst of the worst.
@Daniel:
ReplyDeleteIf one's dealing with inexperienced programmers, one needs to establish some basic cultural safeguards: establishing a mechanism for code reviews, a quality control workflow and a process to document code are all language-agnostic measures that absolutely must be in place in anything but the smallest projects.
I'm not sure why you say that languages should be more complicated. If your coworkers have issues with the core Java libraries, what good would it do to force them to use things like overflow checking, malloc() or jnz? Wouldn't it make more sense to have them try something simpler to use (like, say, PHP) for the next project?
If your goal is to "get rid of the noobs", I suppose that exposing all those bloody guts would scare them away, yes, but I personally prefer to think that this industry is a career for everyone involved in it, and taking initiative in teaching good practices (be it via formal training, casual "lunch-and-learns" or one-off "hey looks at this cool feature" tidbits) is a trait of good technical leaders.