Blue Sky On Mars

Always a happy occasion… here comes Eclipse 3.0 M3.

Not Up to Code? Embellishing the Flag, Then the Web Site (washingtonpost.com) talks about a number of laws that Bush has broken recently. This is partly a testament to how complex our legal system is, and partly a testament to how Bush is willing to bend the rules to get what he wants. There’s still that larger question hanging out there of how far the truth was extended in order to win support for the war against Iraq.

iTunes iSbogus is a nicely done satire of iTunes that blasts people for supporting the existing music industry. I’ve been generally against the music industry and many of its practices, but the fact of the matter is that artists voluntarily sign contracts with these records labels. And, no one has stepped forward with a viable business model that pays for the recording of the music and promotion that follows the release… there is a lot more that goes into it than just the artist’s original output. Places like EMusic offer a new model for artists.

Musicians have choices (and we better make sure that the legislature doesn’t remove those choices!)… if they want to be a “big name multiplatinum radio and MTV star”, the only way to do it today is via the major labels. Unless they’re really good at self-promotion.

Yahoo! is expanding out beyond My Yahoo! (which is already a great service) to provide RSS feeds for several news categories.

If you’re writing Java code and trying to support multiple databases, your best bet is probably to use Hibernate and not write queries directly. Assuming you just really like SQL, you can also useLDBC Liberty Database Connectivity which provides a common SQL syntax and common behavior regardless of which database engine you attach to.

Via Slashdot of all places, I came across a link to Dynamic Drive DHTML(dynamic html) & JavaScript code library!, which looks like a great resource!

I’m not sure why I’m taking the bait from this anti-XP rant at the BileBlog, but I am. Before I start: I am not saying that everyone should use XP everywhere all the time. Now that that’s out of the way…

The customer wants to get the most bang for the buck, and wants to cram in as much as possible for as little expenditure (both financial and time) as possible to them.

Yes, times are tough and people have to go for business where they can find it. But, if that’s truly what your customers want, I’m sure there’s an increased chance of the project not being successful. Companies want to spend as little as possible, but they also want their projects to succeed. The point of having a lot of customer interaction is not to air your dirty laundry but to make sure that what you implement is actually what the customer wants. It’s not uncommon for the view of what the customer wants to change between the start of the project and the end, and lack of customer interaction is one signficant reason for project failure… the customer simply didn’t get a product that did what they wanted at the end of the development.

More important is to define milestones and releases, rather than just churn out release after release.

XP is not about making frequent “releases”. XP is about having visible, demonstrable results on a predictable (2-3 week) schedule. The customer decides when an actual release (as in code shipped to end user) happens.

Unit tests are wonderful things, and can provide a great deal of robustness and regression testing for a system. However, I’ve found that in real life, QA engineers will still always find a whole bunch of issues.

Undoubtedly, though they will probably find fewer issues than if you weren’t doing test driven development. Also, it seems that you missed the fact that you are supposed to have automated functional tests, too. Ideally the customer would create these, so that they have something they can trust that says that development is done. I do think reality diverges from the ideal here, only the savviest of customers could create their own automated functional tests.

Almost as much time is spent (wasted?) on getting unit tests up to date, functional, and well behaved as fixing the actual code itself.

It doesn’t sound like you’ve ever actually done XP. If you’re doing test driven development, you should never be working on “getting unit tests up to date”. You would have written a failing unit test before changing any of your main code. Getting unit tests up to date can be a lot of work, because code that is written test-driven looks different than code that is not. It’s designed to be tested, and your test code is usually very simple.

Many projects require very specific in-depth domain knowledge, and shuffling people around such that chances are that most are moved away from their main areas of expertise is simply flushing talent down a toilet.

I don’t think an XP team would stick a pair of clueless newbies in a room by themselves to work on something they’ve never seen before. If something is very esoteric and one person on the team knows about that, odds are that person will be paired with someone working on that part. Most programming is not quite that far out. XP teams are usually located in an open environment which means that the pairs are not working in isolation. Someone from one pair can toss in some guidance as needed.

It simply expects too much from everyone, and assumes that the ‘average’ developer is versatile, talented, experienced, motivated, and highly enthusiastic

Any team will be made up of a combination of people, with varying skill sets. In fact, you want a team with varying skill sets. People at Menlo Innovations, a local XP shop, mention that they have had great success where less-experienced developers would come up with novel solutions that are better than what the more-experienced developers came up with. Not because of any failing of the experienced developers, but because the less-experienced ones are not set in any particular ways of doing things.
Anyone who is not motivated to do good work and help the project be a success should be fired.
In response to comments on the original posting: I do view the XP practices as a toolset that you can pick and choose from, but you can’t really say you’ve been doing XP without doing them all. There are synergies that come up when you do all of them. Doing unit testing and refactoring alone is a big win for code maintainability and the ability to add features quickly.

Finally, if your developers are equally talented, one of them is bound to spend a lot of time being bored to tears as the ‘typist’ fleshes out mundane but necessary aspects of the system.

Generally, people switch back and forth from the driver seat frequently. And if the person who is not driving is “bored”, they’re not doing what they’re supposed to be doing. While the driver (typist) is handling the mundane details, the other person is supposed to be keeping an eye out for the big picture: how well does this code fit the overall design? are there places that this can be refactored?

Write tests for the parts that are critical. A sound architecture will usually take care of the rest.

And what happens when a new requirement comes up that the “sound architecture” designed 2 years ago doesn’t address? People generally end up adding warts to an otherwise nice architecture, because they don’t want to break anything. When you do test first development and your tests cover the bulk of your code, you can change things a lot more comfortably.

IT: “Which are the most important features?”
USER: “They all are”
IT: “Can you please rank them”
USER: “OK, as long as you deliver them all”

Yes, we all know that user. The fact of the matter is that if the user is defining the features and the timeline, the project is likely to fail. Most projects have a fixed time horizon. The point with XP is to give the user the knowledge they need to make choices about their end-result product. If you want to say “Sure, we’ll give you all of the (undefined) features you want in 4 weeks”, go for it… and be ready to spend 80 hour weeks on a project that is buggy and comes out 4 weeks late.
There’s always got to be a process for managing the scope of a project. XP is an “agile” method, which means that the process supports changes in feature set anywhere along the cycle, as opposed to the “big design up front” methods. Either one can work, it just depends on the project and customer expectations.

Something that could come in handy in a future power outage:

American Environmental Products, Inc has developed Glow-Lux Emergency Afterglow Lighting, a bulb that glows in the dark even when the power has been turned off.

In the “oh, come on!” department: SCO CEO says IBM behind open source attacks includes this choice tidbit:

“We have absolute direct knowledge of this. If you go behind the scenes, the attacks that we get that don’t have IBM’s name on them, underneath the covers, are sponsored by IBM,” [SCO CEO Darl] McBride said.

I’ve been avoiding adding more coverage to the already massive coverage of this crazy lawsuit, but these guys are even more deluded than it had seemed previously! I can guarantee that I think SCO is full of malarky and that IBM has nothing to do with that opinion.

Time has a nice article about the changing consumerism in India. Huge change is afoot indeed.

The cutting edge of this consumer boom is on full display in Gurgaon, a satellite city south of New Delhi that is rapidly developing into mall-rat heaven. Since December, three mammoth, glitzy malls have opened their doors there, crammed with a collection of stores airlifted straight from America’s suburbs — Nike, Benetton, Pizza Hut, Subway sandwiches, even a showroom for Bose audio systems. Two multiplex theaters show such Hollywood hits as The Matrix Reloaded. Five more malls nearby are in the works.

The article also has some interesting bits about the steps McDonald’s has taken to cater to the crowd there:

The best seller is the McAloo Tikki burger, a vegetarian fried-potato patty with cheese. The newest entry is the McCurry Pan, a flat pastry filled with hot broccoli or chicken curry.