|« November 2003||January 2004 »|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
firstname.lastname@example.org no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
I went to DynDNS.org and set up an account. It's a free service, for up to five addresses, that lets you have a domain name to pointing to a regularly changing IP address. The address http://audioman.dyndns.org should point to my development box's web site. Right now there is nothing on it, just a test page. My Linksys router forwards port 80 to the development box on the internal network so it appears as though there is a web server from the outside.
I use DSL to connect to the Internet and the IP address changes often enough that it's a pain to update the DNS record manually. DynDNS has a list of clients you can use to automate the IP address updating. I chose the DynDNS Updater tool for Windows. It was easy to set up, stays out of the way and best of all it was free.
# Setting Up Ant on Linux
To set up Ant on the AudioMan development box I had to install Java first. I used the RPM method which installed Java in /usr/java/j2sdk1.4.2_03.
1. Download the binary distribution of Ant and unzip it into /usr/local.
3. Set the JAVA_HOME environment variable to the location of Java:
4. Add the Ant directory to the PATH environment variable:
5. Run ant with no parameters. You should get the error message:
Buildfile: build.xml does not exist! Build failed.
The next thing I want to do is check out the AudioMan project from CVS and build it with Ant. I could put those commands in a shell script and run it daily as a cron job.
# Read-Only CVS Access with pserver
Note: This was a failed attempt to set up pserver. I subsequently succeeded and blogged about it here.
I want to give anyone read-only access to the AudioMan CVS repository and it seems like the pserver protocol is the way to do it. Now, pserver is an insecure protocol so it needs to be used in a secure environment. Two secure options are a chroot jail or ssh.
ssh is the secure shell that I used for secure CVS access for developers. The difference is that pserver allows anonymous access while the developer access through ssh I set up requires a Linux user for each CVS committer. I'm not sure if Eclipse - the IDE of choice for this project - supports pserver through ssh.
A chroot jail limits the damage that a pserver client can do by limiting the file access of the internet services daemon xinetd. Apparently the old daemon inetd wasn't secure and was usually running as root. Exploiting this daemon would give you full access to the machine. Yeah, not too good. So what a chroot jail does is make the directory it uses look like root: /. The rest of the filesystem is hidden and inaccessible to the daemon.
1. Downloaded Jail to my home directory.
NOTE: I'm stalled here. I tried the next steps on CVS in Jail and ended up in the rhubarb. I think Jail is too specialized and doesn't do what I want to do ... it's adding a whole bunch of directories to my cvsroot. I don't think I'm on the right track. I'm posting this for people's comments and I'll update it.
If I can't get pserver access working by the end of this week, I'm just going to release the code as part of the 0.1.1 release. It's holding things up too much.
# Version Numbers
How about copying the Linux kernel numbering system for AudioMan? There are three numbers: the major version, the minor version and the release number.
The major version number is incremented whenever there is a major architectural change. For example the Eclipse project incremented the major version number to 3 when they introduced the rich client platform and changed the plugin system. This number starts at 0 and is changed to 1 when there is a stable and usable product.
The minor version number is used for large milestones within major version numbers. Usually a lot of time passes between these milestones, with big features being added but not the major architectural changes in a major version swap. Like the major release numbers these releases are very stable.
The Linux kernel uses even minor version numbers to indicate a stable stream of development. Usually only security and bug fixes are applied to this stream and it is very stable. The odd minor version numbers are used for so-called unstable development streams, where new features are being added. The unstable development in version 2.5 of the kernel was recently changed to 2.6 when it became stable enough.
Release numbers are used for smaller milestones within a minor version.
So AudioMan's first release will be 0.1.1. For that release we should just get all of the tools set up, the licenses set and everything ready to go. The code will not change. Then 0.1.2 will be the first release with new stuff. Sound good?
# Blogger Tour 2004
Just a thought ...
Wouldn't it be cool if a blogger drove around the United States and Canada and blogged about it? He could post pictures, go off the beaten path (interstates) or meet other bloggers.
Here's the kicker though: he'll pick three or four cities each week and the readers of his blog vote on which one he goes to next. Then rinse and repeat the next week. He'd just travel until he ran out of dough or got bored. Wouldn't that be cool? Just a thought. :)
# Done School
OK, that's it: I'm completely done school. No more exams or assignments. Yay. Now what? :)
# Job Hunting
Any others ...?
# Open Source Licenses
The licensing issue for AudioMan one area I'm a little weary of because I'm not a lawyer and I don't want to pretend to be one. It would be nice if we could just write software and not have to worry about people stealing it but this is the real world we are talking about here. Nasty people are out there: we need to protect the code.
I won't talk about specific licenses now because I don't know that much about them. The Open Source Initiative web site is a good place to start researching.
There's been some concern about licensing related to libraries that we use. This project is going to use SWT and JFace libraries included in Eclipse, which is covered by the Common Public License (CPL).
I don't know much about software licenses but I do know that it doesn't make much sense to make a windowing toolkit that can only be used if the software also follows the same license. That would rule out any completely proprietary software or GPL software using SWT. So I think we are free to pick any license we want as long as we include the CPL text with the Eclipse-related JAR files that we distribute. By the same logic as well, what good is a graphics library that you cannot distribute? It just makes sense ... but we should still check into it.
Until we know more about software licensing, it's probably best that we don't release the source code. The reason being is that as far as we know switching sofware licenses isn't that easy. Once we pick one we could be stuck with it so we should put some research into the choice.
We could definitely use help in this area guys, if anyone knows a lawyer looking for pro-bono work or just someone with enough interest to really look into it. Otherwise I'll have to twist Jim's arm. At least he took Engineering Law last semester. :)
# Distributing AudioMan
I was talking in the halls of SITE after my last exam about AudioMan with Aleks and Karen and among other things we talked about distribution and Java. Just thought I'd write a post to get those ideas down and bounce 'em off readers.
AudioMan will primarily be a Windows application but SWT is cross-platform so it could, in theory, be easily "ported" to Linux and Mac OS X with a little work. This will probably be one of my little pet projects that no one else will care about but it would be nice to release the same code on three platforms at once. The only difference is that the Mac OS X and Linux integration will be crufty unless people start caring about it.
Second up is an installer. While Java programs don't need an "official" installer I think it's just nice from a usability standpoint. Previously with AudioMan we used a ZIP file and README. Most users will download a ZIP file and not have a clue what to do with it or even know that they are supposed to read the README file. Besides making the installation less painful, installers are also a nice place to do all of the platform specific stuff to set up usability things like shortcuts and menu items, overall just make the app seem more integrated. People shouldn't have to know that it's a Java/SWT application. We'd like to fool them. ;)
The build process is tied to this because it produces the installer files that people can download. There are two build processes actually: one for developers as they work on the code and the other to produce releases. These should be kept as similar as possible without hamstringing the developers too much. We don't want an error in a release build because of a build process difference but we don't want to slow down developers when they are just hacking code.
Ant is an easy tool to use once you get the hang of it -- we used it to produce the AudioMan builds before. But I would like to further automate that build process to do the following:
- compile the code
Then you can fire off a new build with a click of a button and everything is done for you. Zero maintenance. As well, you can configure Ant to let you make a new build only if the source code has changed in the last day. Then we don't get daily builds for a month that are all the same if the code hasn't changed. Ant will be the place where platform specific builds for Linux and Mac OS X are configured as well.
The Ant integration with Eclipse is getting nicer in 3.0 but developers will still probably prefer to use Eclipse's built-in compile and JUnit plugin rather than use the Ant window. That's definitely OK but a sanity check with the Ant script should be done at the end before committing to make sure that you don't break the next build. In other words, the Ant script will be the word of law on this project. Compiling/running and JUnit test runs in Eclipse are just for convenience. Speaking of convenience: when is someone going to make a jcoverage Eclipse plugin?
So that's my brain dump on distribution ... thoughts?
BTW, this is post #400. That seems like a lot eh? Thanks for reading.
# Introducing the Bazaar
Roy and I were discussing how he could contribute to AudioMan and, being the good team player that he is, he offered to fit anywhere he was needed. This is a great attitude to have -- team players are definitely valued on any project. But it's not really the way a lot of open source development has been working.
To refresh my memory I went back and re-read Eric Raymond's The Cathedral and the Bazaar (CatB). It talks about the differences between traditional commercial software development (cathedral) versus succesful open source development (bazaar). If you're going to be working on AudioMan or following its development, this is probably the minimum amount of reading about open source development that you should do. It's not that long. :)
While I was glad that Roy was willing to work on anything I remembered a simple quote from CatB: "Every good work of software starts by scratching a developer's personal itch." The idea is that developers with a vested interest in the code will produce better work. You use the code you are developing so you intentionally give it better quality. This is also known as "eating your own dog food."
Developers that are put into roles in which they don't necessarily fit or want aren't ideal because they don't have any incentive to do a good job. With paid programmers, in theory anyway, that's not the case because they are being paid a salary, are evalutated and can be fired if they screw up enough. The problem there is that you start getting "good enough code" and unmotivated people. To quote Office Space, "that will only make someone work just hard enough not to get fired." It's funny and sad because it's true. I don't want to regurgitate CatB too much -- you should read it yourself.
The more interesting ESR essay actually is Homesteading the Noosphere. In it he expands on CatB and explains the so-called "hacker gift culture" that makes open source sofware possible. He goes into the psyche of the open source developer to find out what drives him to do free work.
I'm not saying there won't be gruntwork on AudioMan - there is on any software development project. But as ESR says, open source developers also have to be self-fulfilled to do good stuff. I have to do my best to allow for those opportunities just like Eric and Linus have done. If that means I'll probably end up doing a lot of grunt work then I'm prepared for it.
By the way, I know I've been doing a lot of talking and not a lot of doing about AudioMan lately. AudioMan development has pretty much stopped for the time being. I think that rather than jump into it again a proper foundation should be laid down. Everyone has to grok what open source is about in order for it to work properly for this project, including myself. Talking it out for a week or two won't hurt much. Besides the dev box is still being used for something else so we have to wait anyway. :)
# Feedback Will Steer AudioMan
Some of you might be wondering where this AudioMan project is going. That's a good question -- I don't know either. That's because I don't know what the users want yet. Well I have a general idea but no specifics. When I set up the new Bugzilla database and open it to the public, people can submit requests for new features and defect fixes (collectively called "bugs"). Then others can vote on the importance of submitted bugs, so popular bug requests will be handled first. The users are happy because of the quick feedback loop and developers are happy because there are (hopefully) more users.
I'm not expecting every AudioMan user to be able to use Bugzilla though -- it's not an easy piece of software to grasp because it's made for programmers, not end users. Maybe we'll get feedback another way -- verbally, email, a web form -- and we'll submit the new bugs ourselves. But the bottom line is that all of the change requests are in one system, where they can be prioritized and attacked one at a time. If a new feature request is rejected, the reason is spelled out for other people to see. Then in six months when someone else requests the same feature we can just point them to explanation, saving a lot of time communicating.
So I'm keen on seeing what people request from AudioMan, which is why I'm a little anxious to get Bugzilla set up. That's not to say I won't selfishly implement functionality that I personally want but if people don't like that stuff I'll probably be pressured to take it out again or they'll just take matters into their own hands.
That's the thing about open source software: you're not selling anything, people just want software that works well. As soon as you start to stray from that people won't have a problem telling you about how much you are screwing things up. After all, they can just take your code and fork it off into their own project, which is perfectly legal and acceptable. Maintainers of open source projects have to be cognisant of that all the time.
# Welcome, Humans!
I've been getting a lot of visits lately from people I know in meatspace. I just wanted to say "Hey". Just so y'all know though, I dork out pretty crazy on this blog. I write almost exclusively about software, high tech or music. Not too exciting for folks outside of the high tech biz, I know, and not that exciting for people inside the biz either. ;)
But hey, if you want to read about people's personal lives may I suggest Diaryland? People seem to write as if they have no idea that anyone in the world can read their stuff. A lot of it is boring babbling but sometimes you find a doozy. I found Jim Hodgson's Blog a few years ago and it's pretty funny.
# AudioMan Dev Box
It's almost time to set up a box for AudioMan development, likely next week. I have a very old but sturdy Pentium 166Mhz box (the first computer I owned myself) begging to be used. We'll see how it holds up to these tools:
Should be OK but maybe a little slow. A wiki should make communicating a lot easier. Since I'm the only one with access to this site usually I just write stuff and people call me an idiot until I change it. With a Wiki we can all be idiots at the same time. ;)
Where to put the box? Yeah, that's a tricky one. Here we have Bell Sympatico High Speed DSL and the IP address changes quite a bit, though I could use DynDNS.org. Anyone have experience with this? I'm going to delay putting MoveableType on that box until we can figure this out (doesn't make sense to have an unreliable news site). Until then I can just host an AudioMan news blog, when the need arises, on ryanlowe.ca.
When I get a job and move I'll consider getting Roger's Hi-Speed Internet access instead and get a static IP address. I probably won't use a land-line phone and I watch cable TV anyway, even though it melts my brain.
Backing up the project data will be a big deal, so I have to keep that in mind when I set stuff up. That machine doesn't have a CD burner but I suppose I could get one (and learn to use it at the Linux command line? yikes). I should also make daily ZIP'd backups of everything and send them over the network to another, more reliable, machine. You only need to keep seven of these backups: one for each day of the week and write over last week's copy of that day. Then every week (yeah, right) back up the seven days to CD. Wow, playing IT is fun! :|
I should also remember to write down how I installed everything so I can rebuild the box quickly in case of a hardware failure or some other disaster. Backed up data is good, but without the same software configuration it's a lot harder to get things back to the way they used to be. Keeping the procedure up to date over time is a probably good idea too.
Update 4:32PM: Not that you guys care that much :) but I'm going to wait until I get my PII-266Mhz back from my step-mom to set this stuff up, her laptop is in the shop. It's a much better machine (USB, serial keyboard/mouse, 20GB hard drive, 64MB RAM). I've already had Red Hat 9 on it and it runs well, even with a gooey. Roy has a good point about the new box and less problems -- if development really starts swinging I'll invest money in one (another good reason to keep track of how the software is set up). Right now I'm trying to stay as cheap as possible. :)
# Code Check-in for AudioMan
Now that AudioMan is an open source project, I've been thinking about the best way to do check-ins. Fortunately I don't have to think too much because several open source projects, like Eclipse and Bugzilla, use a process I mostly agree with.
In that system there are committers, people who have CVS logins and can modify the CVS tree (submit, modify, delete code). Committers are usually with the project for a long time.
The rest of the coders on the project submit patches which are attached to bugs in the Bugzilla defect tracking system. Committers apply the patches to the current CVS contents, make sure everything works as intended and then checkin the code and close the bug.
This system has the following advantages:
I see this project having people coming and going, submitting code as they have time. Very few people will be able to consistently apply effort to the project, which means that specific taks and timelines for milestones will be difficult to lay out. Open source projects typically do not have firm deadlines (larger projects with paid developers working consistent hours like Mozilla and Eclipse are notable exceptions).
Oh yes, and casual patch contributors -- by submitting many successful patches and demonstrating their talent to the current batch of committers -- may be promoted to "committer" status.
Update 9:32AM: Eclipse can make patches that you can attach to a bug. Then a committer can apply that patch in Eclipse again to the latest CVS source. If the changes introduced by the patch are good, the committer checks those changes into CVS. Sorry, I wasn't too clear on that. Yeah, as far as I know patches are just diff files.
Update Wednesday 3:56AM: Right out of the Eclipse help, here's Working with patches.
# Outsourcing Internationally
Outsourcing is a sticky issue lately and programmers are concerned their high-paying jobs will be going out the window. To be honest, they should be. However, us North Americans have a few advantages over our international brothers and sisters that may or may not bring you comfort. Here are a few:
1. The language of high tech is English. Bleeding edge work in technology is often in English and that gives us a (admittedly unfair) head start. Use this to your advantage.
2. No matter how cheap the labour, sending work offshore costs money. Communication overhead multiplies. Managers love it because now there needs to be more of them to facilitate that communication, in North America and in the other country.
3. Speaking of English and communication: there's nothing like speaking to a native (North American) English speaker, especially about technology. English spoken around the world has local differences, not only in the way it's spoken but also with local jargon, expressions, etc. When you have to process broken/different English before you can digest its contents, communication slows down. In the high-speed technology industry this costs businesses money. Some people are easier to understand than others depending on thickness of accent, and that goes for England, Scotland, Ireland and Australia not just India.
3b. ... and that communication is not just inside the company. Ask Dell how much their corporate customers liked tech support from India. Customers will demand they can speak to someone they understand, not just in management but also at the lower programming levels, so they can get their problems fixed as quickly as possible. If there are communication issues in engineering your customers will dump you because you're not responsive enough. Time is money to them and it should be to you too. Dell learned the hard way.
4. Time zones are a huge communication issue as well. Something that might take an hour to fix in Virginia could take a whole day to fix in India because your engineers aren't even awake yet and by the time they fix it you'll be at home watching Who's the Boss reruns on TV.
So besides those points, software engineers have a distinct advantage over traditional computer scientists in that we often deal with software process rather than straight technology or implementation. CompSci's usually end up learning process on the job rather than in school. North American businesses might be able to outsource quality assurance or programming internationally but the head brass (C_Os) will probably feel less warm and fuzzy about exporting their process -- essentially their control over the software.
The best we can do as software engineers and programmers is to be aware of the advantages and disadvantages of outsourcing. Don't ignore this issue because it ain't goin' away.
Anyway, that's my personal take on it. If you have points to add or corrections please use my comments. I don't know much about this stuff either -- I'm learning just like you guys. Let's discuss it.
Update 3:04PM Nice timing: the rumour mill says IBM is considering "offshoring" almost 5000 jobs to Asia.
# Popping What?
Watch out people: my brother has a blog now. Read with caution ... I'm not responsible for the content there. :)
# Design Switcheroo?
I can feel a redesign of this blog coming on. What do you guys think of the MiniBlog? It is good to have the links separated or should everything be mixed together?
I was also thinking that if I did mix short and long posts together I could take advantage of MoveableType's "more..." link like Andrew does quite often. That would keep large posts off the index page to reduce clutter but it would also make the blog harder to read because you wouldn't be able to read all of the text from top to bottom .... hmmmmm, what do you guys think?
# University is About Meta-Learning
Andrew made a great blog entry about his experience with using grades as a measure of a person's success. I couldn't agree more. I also agree with Andrew's assessment that school is "not about learning" and that learning is a "wonderful side effect" of school. I would say that university is more about meta-learning: learning to learn.
Personally I took the other route. I chose not to play the grade game and everything that's involved in it. I get A's in the stuff I like and less in the stuff I don't like. I also self-supplemented my "curriculum" by doing a lot of outside reading about technology, programming languages and software engineering. I got most of my co-op/intern job placements with skills I learned on my own time -- stuff I knew I would never learn in school.
My logic throughout school was this: I'll get good grades in the stuff I care about because I actually want to learn it and just get through the other stuff. With the time I saved not "excelling" in those other classes I learned about skills that could get me a job in the real world, something that schools conveniently and ironically forget about. (Maybe this is because they are pumping out masters candidates instead of employable graduates?) Also important, it gave me time to do extra-curricular activities instead of worrying about school 12 hours a day.
Something they don't tell you in first year is that after your first job no one is going to ask about your university grades -- your interviewer will look at your past experience and call up your references. They want to see what you have accomplished, they want to see results (as Andrew mentioned, projects are a great avenue for discussion). After your first job your grades are moot unless you plan on going back to school.
Anyway that's my rant about grades. :) Andrew played the grade game to his success and I commend him for it. It's not an easy game to play by any means, just know what are are getting into and get your priorities straight.
# Sweet Singles
Here are some singles I like that haven't been "released as singles" by their bands yet ...
Radiohead - 2+2=5
# Kent Beck on XP Testing
I recalled correctly Kent Beck's opinion of testing in Extreme Programming Explained (1999). In fact he was quite concerned about developers adopting XP:
"... you should write the tests that help get programs working and keep programs working. Nothing more. Remember the principle 'Work with human nature, not against it' ... If we want programmers and customers to write tests, we had better make the process as painless as possible."
Then he goes on to say this about testing:
"You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practise, then you shouldn't write a test for it. If I told you to test absolutely everything, pretty soon you would realize that most of the tests you were writing were valueless, and, if you were at all like me, you would stop writing them."
So from this would I estimate that Beck is as thorough with his testing as I am? Probably not, but he's been coding a lot longer than I have -- he doesn't have to be.
# Developers vs IT Staff
Slashdot linked to a developer's rant about IT staff holding up development. It's interesting to read the IT people's comments (likely about half of Slashdot's readers are IT staff) and get the other side of the argument. It's sometimes difficult to get into an IT administrator's shoes -- especially when they are preventing you from making progress on the product you're working on. Is it ironic that developers created the software that they are hamstringing themselves with?
The best advice I read in the Slashdot posts was to communicate better. If IT is stopping you from doing something there is probably a good reason. Start a dialogue and work as a team to solve the problem. Developers and IT need to work together to create the final product, not go to war.
As a backup plan several Slashdot posters have also recommended going around IT altogether ... not exactly great teamwork but it might get the problem solved in the short term. Of course that's just the developer in me talking. :)
# CD Wishlist
Death Cab for Cutie - Transatlanticism
... I'll probably add to this.
# Bloggers Make Mistakes
Maybe I should have a disclaimer on this blog: "The content of this blog is my own opinion and should not be confused with fact". As more people get online and start writing whatever they want we have to carefully consider the source of what we are reading.
Bloggers aren't stringently bound by the law like reporters are, we state our opinions. If our blogs were in the newspaper we'd have our pictures in the byline. Bloggers make mistakes. We don't have fact-checkers or editors -- we just do our best. So be careful what you believe and take nothing you read on a blog for granted.
If I make a mistake lay into me. I can take it and I probably deserve it. I'm willing to take that risk to engage people in conversation.
# Agility vs Quality
The XP guys seem to want it both ways. They tell you that with XP you're agile but can have quality too. I disagree, great quality takes time and resources. The coupling that testing creates between code and tests degrades the product's agility to a degree. However it also improves agility by giving developers the confidence to refactor without fear that they may be introducing new bugs.
Agility is sometimes said to be the YAGNI philosophy. YAGNI leads to not writing a lot of unit tests -- just ones for important or tricky situations. Unless you're a lucky or amazing programmer your product's quality will not be great.
The subtle tricky boundary cases that are covered by comprehensive boundary value analysis are often the ones that break when you refactor. During refactoring you want to know immediately if any of these subtle boundary cases have regressed. Anyone who's done a lot of refactoring knows that these tests can often provide a valuable safety net and give the developer confidence to refactor the code without introducing as many defects. Jim and I have talked about this a few times.
Good quality takes time and effort. Even if the majority of your tests are automated you still have to put a lot of resources into making them. When the code changes -- as part of your plan to be agile -- you lose some of the investment you've made in testing. This is a reasonable sacrifice to make in the name of forward progress.
Striving for agility may discourage developers from writing tests on areas they think have to be more agile. Lazy programmers may realise the downside of uncomprehensive testing after refactoring poorly-tested areas of code. The time they saved not making tests previously comes back to haunt them as they try to track down defects introduced by the refactoring. These areas of code become regression defect magnets until someone goes back to complete the unit testing.
Update 10:26 PM: James Robertson responds to this post. I actually have used a lot of the XP practises this year during AudioMan development.
As I mentioned above, we found that testing does improve developer confidence during refactoring but that does not discount the fact that with more tests you have increased test-coupling. When you refactor the code you have to bring the tests with it, which can be a lot of work depending on how drastic the change is. IDEs are not smart enough to take care of all of this work yet. This could discourage programmers from refactoring because they see it as a nuisance. That affects the agility of a project.
YAGNI does refer to features but I believe that the XP 'purists' would also say it extends to testing as well. I got this impression after reading Beck's Extreme Programming Explained. I will find the exact passage when I get the book back.
Do XP purists like Beck check for simple things like NullPointerExceptions (Java) in their APIs? I don't think so. They would see these checks as unnecessary. Of course they've been programming for years and they don't make these stupid mistakes. Expert programmers can leave these testing holes to reduce test-code coupling but most of us cannot afford to.
Update 12:22 AM James responds again. I made the mistake of not mentioning that the AudioMan project did not follow the YAGNI approach to testing, I apologize. I do not advocate it, I only meant to say that from what I read I thought that Beck did (obviously I have not read enough).
In fact there were a few refactorings that took more work because of the high degree of test-code coupling we had. With our unit tests we tried to test every possible input to our API methods, doing a sort of informal boundary value analysis. We have 450+ unit tests on a relatively small project (80KB of code plus 130KB of UI code and 208KB of unit tests).
Of course this kind of testing gives you a great safety net for refactoring but does it affect agility? Maybe in the short term because refactoring is more painful (more things to manually change) but in the long term heavily unit testing an agile product can keep quality in check. In my limited experience this has been the case.
# The AudioMan Project Begins
I hereby kick off the AudioMan Project. I wrote some tentative ideas down and I'm looking for feedback. Here's an excerpt from the page:
AudioMan is a digital music organizer for personal computers. The purpose of the AudioMan Project is not only to create a useful product but also to explore software engineering practices and tools and to collaborate on a group project without severe pressure from market forces. The processes and code of the AudioMan Project will be completely transparent and free for the general public to read and discuss. This transparency will also allow members to second-source others.
In that sense, this project will be artifact-heavy. If you don't like writing about what you are doing this project is probably not for you. One of the primary goals is to stimulate discussion of software engineering topics.
Update 8:18 AM: I guess I should give more details. :) Yes, it's open source -- at the end of the school project (this month) we decided to release the AudioMan source code. We have not decided on a license yet.
I wouldn't call it an experiment since we are writing a (hopefully) useful product. I would say it's a typical open source project but done by software engineers. So in terms of organization it is more like the Eclipse project than the Linux kernel project. Rather than use the BIFI (build-it, fix-it) approach that is common in open source projects we will use a more organized process. Sure, this may slow us down a little in the short term but I am confident that long term gains will be realised.
Collaboration will probably be mostly online but given that most of the prospective members are from the Ottawa area I'm sure we can have face-to-face meetings over beers every once in a while. You don't have to be in Ottawa to join the project though.