Langr Software Solutions » programming

Langr Software Solutions » programming — Main Menu — Home Consulting / Coaching Training - Information About Training - Student Quotes - Technical Training - Process Training Resources - Agile in a Flash blog - Articles - Jeff’s Wiselike Page (Q&A!) - Books Jeff’s Blog About Home Consulting / Coaching Training Information About Training Student Quotes Technical Training Process Training Resources Agile in a Flash blog Articles Jeff’s Wiselike Page (Q&A!) Books Jeff’s Blog About Open Source Pairing Scheduler April 03, 2008 by Jeff Langr 0 Comment Rather than whine about not having enough good pairing experiences, I’ve decided to do something about it. Recently I’ve had a few pairing sessions online, and I decided that the software to build would start around the simple notion of scheduling online pairing sessions. The idea is to slowly start building an online pairing community. I imagine there are many kinds of participants, people who want to: build quality software via pairing and TDD promote their services and ability to mentor via pairing get some work done on a real product get in touch with other members of the agile community learn about either pairing or TDD learn about the effectiveness of distributed pairing learn a specific technology (Java, Rails, JMock, RSpec, etc.) improve their Ward number for bragging purposes I hope that the scheduler software will be all that and many more. Initially, I created a wiki as a scratch pad area, to help set up sessions, to hold an initial backlog of stories around the scheduler itself, and to record experiences. I chose Java, but only because of interests in my pairing partner. I’m not sure that the pairing scheduler should be Java, but for now it is. If Java, what represents the best choice for front end (web) technologies? Please feel welcome to join up and post your recommendations and experiences at the wiki site. Interested developers should send me an email with their intents, and I’ll set up their SourceForge account to have appropriate access. Dogs and Bugs March 23, 2008 by Jeff Langr defe 0 Comment My dog kept wandering around the neighborhood, so I recently put up a fence around my back yard. Now I’m experiencing some regret: after all that expense and effort, the dog no longer gets out of the yard! Was it all a waste of time?!!? (I think Ward Cunningham puts it much more nicely, but hey, I’m not Ward and will never be. Ward says, “ How about FIND BUGS PROMPTLY? “) TDD Hype March 04, 2008 by Jeff Langr 0 Comment A trend I’ve noticed in the software development community is that there are a large number of developers who resist the new wave. Many of those who spent their formative development years doing procedural development went kicking and screaming into the OO age; some suggested that it was an inappropriate tool for many problems. Many C++ developers looked at Java as a toy, not useful for any real work. And I’ve met enough Java developers who thought that Java was the last word in programming languages. Certainly we should question newfangled tools and techniques, and insist on putting them through their paces. OO is not the best tool for every problem, Java did suck big time when it first came out, and yet there are now some significant advantages to continue doing business with it. Challenges ultimately help the tools & techniques improve. Experimentation and innovation is at the heart of the software industry, not active resistance. But it’s far easier to sit in a corner and make as many possible excuses for not doing something. I know, because I’ve done so myself. There are plenty of jobs out there using old technologies, and places where people are happy with the status quo. So, TDD. Some of us strongly believe in it, only because we’ve seen benefits firsthand–not just from toy Stack examples, but from working on systems that range from tens of thousands, to hundreds of thousands, and millions of lines of code. Ahh, but the stack example is all the people sitting in the corner see, because that’s all they want to believe is behind TDD. I agree with the vocal dissenters that TDD should not always be used, but not for the lame list of excuses they often come up with. Primarily, the reason is that the typical American software team just isn’t that good. TDD is a reasonably tough discipline to get a handle on, and most developers are still struggling with OO, language, and tool basics. What’s interesting is that TDD would ultimately help these people the most–some of its best potential is its use as a learning tool. The vocal dissenters, on the other hand, are usually reasonably sharp developers who already have a good notion of design. Thus they can’t quite understand why a technique that promotes more decoupled and cohesive designs is important–“duh, we already get it.” Particularly, for example, if they don’t happen to work with lots of typically underachieving coders. Is TDD overhyped? Not a chance. There are still mountains worth of learn