It’s not about you, it’s about the project

One of the benefits of working with consulting companies is that you get to see lots of other development teams in action. This leads to some really positive experiences, but also some very negative experiences. Some of the positive experiences come from increasing the maturity of the development teams so they consider new possibilities when working.
One of the most common behaviours that I see from customer developers is the “I can’t do that because it takes longer to do my work”. From seeing this in action, I know immediately that they’ve had bullying and inappropriate team management in the past that has not understood the slightest thing about team success. This is generally a reaction to have tasks assigned as though each developer is a silo (the front end guy, the database guy, the framework gal) and then each person is tracked individually “have you finished your work yet.
As a consequence, they have been hammered because they didn’t get their work done, and there’s an immediate reaction to not doing their work and helping somebody else. It’s a counter-productive situation and one that needs to be addressed.
This behaviour is quite often evidenced by individuals :
    – not writing or running acceptance tests, because it takes too long
    – not writing or running unit tests, because it takes too long
    – not integrating changes frequently, because it takes too long
    – not wanting to spend time performing refactoring or restructuring tasks that will help others.
    – not wanting to wander over and spend 10 minutes helping somebody else
Now, just for a moment, imagine that it doesn’t matter how much of your work you get done, if the project isn’t completed. Isn’t it a lot more sensible to focus on getting the project completed, and all the work for the team done on time.
Of course, there needs to be balance, as failing to achieve any of your tasks may also put the project under jeopardy. As with most things in life, there is no silver bullet, and thinking is an important part of daily life (evidence to the contrary not withstanding).
The team lives or dies by the success of the team, not by the individual success. So, it’s incumbent on developers to understand their goals are the success of the project, and it’s vital that the team leaders, the project managers also understand that and reward team players.

Advertisements

Stick to law. Let me write code

In this article some lawyer has the audacity to tell me about software development, my motivations and whether or not Open Source has a future. In the process, shows that he should stick to conveyancing or some other equally intellectually non-taxing form of employment. Frankly, if the state of the US Law system is that somebody with that limited level of research, insight can become (and I quote) James Parker Hall Distinguished Service professor of law at the University of Chicago and Peter and Kirsten Bedford Senior Fellow at the Hoover Institution, then frankly, you septics deserve all the legal and judicial pain you get.
It’s hard to know where to start when somebody that clearly doesn’t know what they are talking about on a topic proceeds to lecture people on that topic.. However, rather than just smother them with bile (as much as that was my first draft) I’ll try and address a few of the most glaring points.
First of all the author confuses the GPL with all open source licenses.
    The linchpin of much, but not all, of the open source movement is the General Public License (GPL)
Many projects are licenced with the GPL no doubt. Many also depends on where you look. If I look on SourceForge, it’s 85%, if I look on apache.org it rapidly approaches 0%. Not even the “big 4” (LAMP) can agree on a license, and then with Perl and Java projects it’s all up in the air. While it is true that Linux and many of the Linux tools all the the GPL, this is a tightly coupled grouping of projects. I would hesitate to suggest that the “widest distribution” of Open Source licenses is the BSD license (and it’s kin, like Apache, Perl, PHP), however I’d really like to hear from somebody who’s done the research.
Secondly the author draws this rather unusual conclusion about open source developers and supporters.
    first note that open source software relies on the very private property regime that its supporters, most noticeably Richard Stallman, disdain on moral grounds
I don’t know about the rest of the world, and I wouldn’t like to speak for them, but I can say that he is possibly right about Richards feelings, however he is hopelessly, completely, utterly wrong about myself. I like private property, I like it so much that I work during the day, write open source at night, and then spend my own money on my own private property. I choose to give away my open source projects because I want to. I can understand that it might be a shocking thought for somebody who lives to bill people in 6 minute increments, that somebody might actually choose to do something for the love of it, which I (and some of my colleagues) do and then give it away, for free, gratis, with no strings attached (not even a GPL).
And, swinging wildly we go for strike 3:
    The open source movement shares many features with a workers’ commune, and is likely to fail for the same reason: it cannot scale up to meet its own successes.
To which I retort. Absolute 100%, bollocks. Where else do you see such incredibly successful software projects as the Linux OS (packaged into it’s many forms), the Apache HTTP server, the entire Jakarta suite of Java software where teams of geographically distributed developers work together in (relative) harmony? These projects have been successful for years, and will continue to do so for years, as it’s done for the love of it. As people get tired, new people join and provide fresh views, more shouting and wild gesticulating, but continued progress. If you want to see stagnation, look at corporate development. They’re still trying to get RAD tools working and don’t understand why it’s been failing for 10+ years. Here’s some free advice, Smart people build good solutions and there ain’t no other way around it.
Finally, the author and I agree on one point:
    But suppose this analysis is wrong.
It is. Tragically, and horribly wrong. And you know why I can state this so confidently ? Because I’ve been doing it for years, I’ve been working with Open Source projects (as a user, bug-reporter, contributor of patches and developer) for years and it shows no signs of slowing down, stagnating or dropping off.
If anything, it’s accellerating dramatically. So, all you journalists, lawyers, accountants, industry pundits and anybody else with no first hand experience in writing and using Open Source code, please go away and talk about your own industries. Or at the very least have the courtesy to ask people who know what they are talking about. You’re embarrassing yourselves, and while in some circumstances that can be entertaining, this is a little more like a train wreck.

Development Environment Smells

There’s a lot of talk in the XP community about code smells, where code is hinting that something might have gone wrong.
I’d like to propose that there are also development environment smells that are as bad, if not worse than code smells. What ? Yup, even tho’ many of the code smells can lead to unmaintainable code (sometimes very quickly) and merciless refactoring is nearly always a good idea, a screwed up development environment causes current, immediate, certain decline in productivity.
When I talk about a development environment, I’m really focussed on the tools, hardware, network used to create the software. While Incompetent Management is a serious impact on projects, I’m trying to look at things that I can control.
So, in no particular order, here are my main development environment smells:

  • No command line build. This is pure evil. No excuses, ever.
  • Build environment tied to a particular IDE. I can’t believe that people do this. But they do, sigh.
  • No specific development test environment. You need to practice deployment
  • Development environment depends on externally managed resources. Database goes down, team stops work. Dumb.
  • A development environment that mandates a “reusable framework”. Reuse is dead. Build a bridge, get over it.

Maybe it’s just my psychotic enthusiasm but being forced to work with tools that hinder rather than help just seems broken, evil and wrong.
Tell me your stories of development environment smells.

Ready for the 3rd Test – Richie is more configurable (and with source)

I’ve added some minor configuration updates to Richie. A complaint from a cow-orker was that there were two games running and it was impossible to listen to only one.
I knew about this but had ignored it to my peril. Oh well.
Now with the addition of the ircbot.commentator property, if this is set to a value, then only messages sent from that nick will be displayed. If it is blank, then everybody on the channel will be sent through.
With these changes, it is now possible to change the value of this while Richie is running, so during the change of innings, or if you want to listen to a different game that is being broadcast, change the file, and Richie will notice it in the next 120 seconds, and update on the fly. The file watching hasn’t been extensively tested, so it might explode badly. Let me know if it does. It works for my local testing, but I didn’t watch that carefully. The only property that is currently monitored for changes is the ircbot.commentator if you want to change the nick or server, then you need to restart Richie.
Also, I’ve now created a zip of the source for people to look at and laugh. At the very least it’s a start for anybody who would like to create something similar for themselves.
I’ve also started versioning the releases so people can update with less confusion.
Download richie-0.2.zip
Download richie-src-0.2.zip

Cricket commentary on the cheap

As I mentioned previously I’ve been coding away with Java creating a cricket commentator. So, I’m proud to announce the release of “richie” the Java IRC bot that will speak the #cricket commentary.
Rather than just a simple dump of the IRC commentary to the FreeTTS output (which is really very easy), I’ve added in some smarter coding so that using the java.util.regex package the bot parses some of the very cricket specific output (like 24-2-33-2) and turns it into something that FreeTTS can speak sensibly (24 overs, 2 maidens, 2 for 33).
Apart from it sounding a bit like Steven Hawking, it’s very understandable, and works really well over a dial-up line.
So, enjoy, and if you’d like some additional features added, then let me know.
Download the ZIP file from http://www.eaves.org/jon/richie/richie.zip.
Then create a directory, and unpack the contents into that directory. Modify the richie.cfg to create a new name for your bot and for the owner name.
Then, just run the bot by using java -jar richie.jar. This is best done in a window so that the commentary can actually be seen, but isn’t required.

The family that blogs together..

My wife has now started blogging. She’s a top notch expert in HR management consulting. It’s definitely more interesting than my drivel. That’s me, my brother and now my wife wasting electrons. If only Mum and Dad would take it up, that would just leave the cats. Actually, after reading some of my blog entries, I’m not so sure the cats couldn’t do a better job.
You can read Sue’s blog here.

Listening to the cricket on IRC

Australia is touring India at the moment playing what will be one of the best series of test cricket in ages. The first day was a real bewdy, and I was sufficiently distracted during the day trying to keep up with the play on IRC. It would be so much better if it was on radio.
So, armed with FreeTTS and PircBot and this article, I now have a Java program that will connect to my IRC server, login and then talk the scores in the cricket to me.
Paul Mutton (the author of PircBot and the ONJava article) has done a great job developing the PircBot framework, and it is really easy to work with. Check it out if you want to do something cool with IRC.
At the moment it’s not very robust, and I want to make it behave a little better and parse the #cricket IRC commentary better, but for a 2 hour hackfest and test, it’s looking (or should I say sounding) pretty damn good.
When I’ve got it in a better shape, and have it configurable, I’ll release a copy for people to use if they want it.