This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: On code and comments
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Brian Marick has some thoughts on reading code - his main point is that even with well written code using intention revealing names, there's still an assumed expected reader. So his point seems to be to bear in mind that the end reader may not be the expected reader - and that you consider that when writing code. That's probably a good idea, but I have a follow on thought - if you have to look at code and you don't get what it's doing, that likely means that you don't know the language it's written in very well (or if you do, you don't understand the business domain very well). Too many outfits have the idea that coders are interchangable parts, and that one is just as good as another. This leads to problems, because the team leading the charge to replace the (poorly documented) legacy system with a shiny new one in some fashionable language/system probably lacks
knowledge of the legacy system's implementation language
knowledge of the business domain
Which explains a lot of failures, IMHO. What management needs to understand is that developers are no more interchangable (and no less, for that matter) than marketing teams. Just as a marketing team that knows the business has far more value than one that doesn't, a development team with domain knowledge has far more value. Consider that next time you see a project outsourced to a bunch of remote people with no domain knowledge, or the next time you see one of the hordes of consultants from one of the big consulting shops. It will likely work every bit as well as the equivalent change done in marketing or sales would.
Previous Topic
