I am of course talking about this blog.
It looks like that just might happen.
For more inside scoops on how aerospace is transforming slowly towards lean and agile methods, you might want to hook onto Glen Alleman's blog.
Quoting David Anderson, Visual Studio Team System Program Manager, on the scrumdevelopment mailing list:
By default Team System is designed for managing agile projects. If you want to do traditional project management you need to round trip the work item data to/from MS Project.
Yesterday, I listened to the IT Conversations interview with Jason Fried from 37signals. I loved the energy with which Jason described how they developed Basecamp.
One specific bit that sticked out from the interview was Jason telling how they prioritized their work before the launch. A few weeks before go-live, they hadn't implemented billing. In other words, they didn't have the capability to actually charge their subscribers for the service. Well, it turns out that they didn't dive head-on to implementing PayPal integration or something like that. Instead, they put all their effort into the user experience.
The catch is that they had a 30-day trial period. That translates to 30 days of time after go-live to get the billing implemented. In other words, spending resources on the billing stuff before launch would've been waste. At that time, the most important thing was to make the application as pretty and usable as possible.
Try to picture yourself in the situation Jason and David were in. Would you have spent your remaining time before the launch on the user experience or the billing? I'm pretty sure I would've spent mine on the billing stuff. After listening to the interview, I realize that I would've likely picked the wrong horse.
I just created my first patch for Ruby on Rails. And a rather meaningless patch at that. Its priority is "low" and severity "trivial". We'll see if it'll ever get into SVN...
...it's all fine and dandy that the Jakarta folks are improving Tomcat but I still can't understand why on earth they won't fix the damn hardcoded session cookie name.
I once asked about it on the devel list and the answer(s) was along the lines of "the spec says the cookie is named 'JSESSIONID' and we won't diverge from the spec in this case". Ok. Except that not letting users configure the damn session cookie name effectively prevents those same users from deploying their applications on Tomcat in certain shared environments.
I can live without having used Tomcat in that one project. I just don't understand why the Tomcat developers have been so reluctant of implementing relatively simple functionality that would clearly provide benefits for "enterprise" users who are simply not allowed to deploy anything behind a certain SiteMinder protected cluster with the standard session cookie name. It's not like 5 years is too short a time for such a drastic architectural change, is it?
I was recently reintroduced to the Python scripting language through a testing tool that uses a Java-based Python interpreter capable of importing regular Java libraries. Jython is currently almost feature complete with Python 2.2 while Python itself is already at 2.4. The difference is not that significant but still.
Anyway, since I've been looking into Ruby and Rails lately, I naturally gravitated towards the JRuby website to check out where the development is going these days. I've been using the RDT Eclipse plugin for a while and knew that at least the last time I looked JRuby was far from up-to-date with the "native" Ruby.
So, what did my sleepy eyes see on the website in the JRuby roadmap?
JRuby 0.8.4 (late March 2006)
- Rubygems working
- Webrick working
- Ruby on Rails working
Exciting. Very exciting. I really hope the JRuby crew can keep up the good work and hit the milestones. Who cares if Apple is about to release their first Intel-Macs when these guys release a Ruby on Rails with Java :)
Good news for everyone: JavaForge.com has been launched, the main differentiating features being their use of Subversion and some kind of an integration with CruiseControl.
Jim Shore's blog entry, XP Designs All the Time, reminded me of something I've faced in literally every TDD training I remember myself hosting--after a live demo of me pair programming with someone on the projector, every single time two things come up:
- "I knew the bit about refactoring mercilessly but I always thought it was just exaggeration"
- "It was fascinating to watch how the two of you were constantly carrying out little design sessions"
Just like with any other technique, you get so much more out of observing closely when someone more experienced with that particular technique is at it. In fact, the same holds for just about any combination of skill levels on the part of the observer and the observee. If only more people could see others do TDD...
You knew right away from the title that there's a catch, didn't you? No, "commercially" is not the regular "commercially" one would expect.
Me and another consultant (from another company) used a Rails app as part of a "live" demo for story test-driven development using a proprietary (sort of) FIT clone built on top of Jython and the JWebUnit WebTester utility for testing against the web interface. Basically, when the client called me up and said "we need some kind of a sandbox application to demo with the day after tomorrow", I knew that we'd have to a) use one of the Petstore implementations or b) use the Rails sample app I've got on my laptop. After some seconds of deep thinking, I also realized that since we're going to have only 30 minutes to actually implement whatever feature we need to implement, the scale is tipping fast towards the Rails app.
And so we ended up demoing the FIT clone against a Rails app.
There's more to this post than that, though. You see, we stumbled into a nasty little glitch while implementing the test--we couldn't make JWebUnit's WebTester to check a checkbox. We really couldn't. Both of us had done that before--with Java and with Jython wrapping Java--so we knew the same methods we were using had worked before.
The problem was eventually hunted down into how Rails' form helper functions deal with checkboxes. When you do
<%= check_box("to_be_shipped", order_line.id, {}, "yes", "no") %>
in the Rails ERb template (.rhtml), Rails actually renders not one but two <input/> elements. The first one is for the checkbox and the other is a hidden field with the same name and having the hardcoded value of "no" (for "not selected"). The purpose of this is of course to have the browser submit something every time regardless of whether the checkbox is selected or not.
Our problem apparently was that JWebUnit tried hard to set the value of the hidden field and not of the checkbox, resulting in a strange "value of to_be_shipped[123] must be 'no'" error message. Hardcoding the checkbox element in the .rhtml ourselves solved our immediate problem right away.
I hope this will help someone else avoid high blood pressure in a live demo situation ;)
Oh, and if you know of a better solution (than rendering the HTML ourselves), please leave a comment or something.
I just spotted this entry from Glen B Alleman's blog. He's writing about stuff he picked up from a book titled "Augustine's Laws". Take a look at the bullets he's got there.
Phew. I just arrived home after a looong day at work. It started off with a TDD training at Tampere with Bas and ended up in Helsinki at the Reaktor office writing up some stuff. Oh, and I hadn't packed yet for Spain. Ah, can't wait to see a little sunshine after a rather chilly September in Finland and Switzerland. Well, at least Poland was warm and sunny. Hot, actually. 30 plus. Anyway, now I'm babbling. But it's the "personal" category anyway. And it's almost 2am...
In the words of K. Fujino, Vice President of NEC Corporation's C&C Software Development Group:
When quality is pursued, productivity follows
(from the first edition of Fundamentals of Software Engineering)
I was so pleased with what I found after following a link to PDF::Writer, a pure-Ruby PDF library, that I just had to mention it on the blog. Just check out the manual they've put out. Oh, and it's naturally a PDF document...
Mike Kelly has posted links to a bunch of IEEE articles on software project failures.
Dave Thomas tries to answer a question he gets asked a lot; is Rails ready for prime time?
His answer is, as usual, a pragmatic one that I fully support. His list of when you shouldn't use Rails hits the jackpot:
When shouldn't you use Rails?- If you need to handle transactions across multiple databases. Rails/Ruby doesn't have two phase commit (yet).
- If you have really strange database schemas. ActiveRecord beats Hibernate when the schemas are fairly well structured. Hibernate wins when you have to map the schema-from-hell before using it inside your application.
-
If you're adding small chunks of functionality to an existing, large application. OK, this is contentious. If I was reading this, I'd probably fire up my mail client and complain that this is exactly when you should use Rails. Integrate to the monster using web services, and add new functionality in something more malleable, such as Rails.
Except... most monstrously large applications I've come across got there over time. They're messy, hard to work with, and tightly coupled. If you wanted to expose parts of them via web services, you'd first have to restructure them to make those parts callable from the outside, and that probably isn't worth the effort (if it's possible at all). - The developers don't want to. If the rest of the developers don't want to use Rails, then forcing them to help you create a pilot project is a simple recipe for embarrassment. Pull, don't push, when it comes to change.
Sigh. It's over again. We had a great time yesterday at the second ever Agile Seminar in Finland.
Craig, Timo, and Oskari took care of keeping everyone entertained and the fun continued at the bar.
One thing that especially delighted not just myself but a lot of the audience as well was the number of people present and showing interest towards agile methods. I haven't dealt with the pile of registration papers, yet, but it looks like the room was pretty much packed -- definitely close to the limit of 150 people in the auditorium!
Some have already asked whether the presentations will be available online. Yes, they will. As soon as I get them. And I'll inform about it via email to everyone present yesterday and on agilefinland.com front page.
Thanks, everyone. It sure was a good seminar.
What? "Information Technology", you say? Yes, that's the usual answer. Let me propose another version that I picked up from Jeremy Miller's recent blog entry.
IT should stand for Intellectual Toolbox
Over the past decade, we've seen a constant stream of CIOs repeating the mantra about standardizing and commoditizing IT for cost savings, effective service delivery, economies of scale, and whatever the latest buzzword combination happened to be.
The sad thing about this is that standardization and commoditization are not some kind of absolute evils. Standardization is a good thing for the industry. Commoditization is a necessity for economies to elevate to new levels of productivity. The problem was--and still is--that many of the same CIOs have used standardization and commoditization to optimize locally on their own turf while global productivity plummets.
CIOs should see IT as an enabler, not a mere service provider. Yes, IT has absolutely zero value outside of the context of supporting a business need. That doesn't mean that we shouldn't make the most out of our IT capabilities, does it?
By looking at IT as our corporate intellectual toolbox, we can support business on their terms and cut off the fat that is very present in many of today's large enterprise IT departments. The policy you have about only running IBM WebSphere 8.0.2 and Oracle 14f, screw that policy. It has absolutely nothing to do with your corporation's bottom line. It might have a lot to do with the IT department's internal bottom line but that's a whole lot different from the whole organization's best interest.
How long has it been since your company's IT department has asked business how they'd like to operate with IT? How long has it been since business stopped asking IT after learning they don't have a say on how to best implement corporate strategy that happens to need a new IT solution?
Someone posted a link to this haiku at Jerry Weinberg's website to our intranet.
Hilarious. And oh so true.
Digitoday picked it up a couple of hours ago. And this time with almost no typos :)
Hmm. We've all heard of peer-to-peer networks being the sh*t these days [1] but when did this kind of services come around? Anyone can upload any file up to 30 megabytes and the file will stay online as long as someone downloads it at least every 30 days. Interesting. That could come in handy some day.
[1] I recently realized it's been well over 3 years since I've last used a P2P file sharing network. Can't say I've missed it.
I just stumbled onto this mind map by Kent Beck about energized work at ThreeRiversInstitute.org:
It's a good reminder of the importance of the need for recharging--something that gets often overlooked when we focus our attention and energy on improving the process, shaping the architecture, or just making that deadline.
Speaking of work, I'm not so sure if I'd want to switch places with this guy.
Jim Shore writes about productivity metrics for software development, concluding that dollars per time is the only objective measure of productivity he's found.
He's quite right in that the CEO nor the shareholders really care about whether your software project was delivered on time. They care about the project's influence on the bottom line and share price. The problem is, of course, that some CEO's, some CTO's, some middle managers, and some whatevermanagersyouhave, are in fact more interested about timely delivery, exact fulfillment of a requirement specification, and so forth--even if it would be better for the company to actually ship the product a month later, ship it with a slightly different set of features than was laid down in the spec, or perhaps even cancel the project entirely. CYA is the reality in the majority of corporate world, even if it need not be.
The problem of misaligned priorities between top management, the grass roots, and everything in between is a real one. I'm afraid that aligning those priorities would require more trust, less selfishness, and more common sense than most established corporations can afford.
I just wanted to draw your attention to a quote from Christian Sepulveda explaning why agile is so relevant for successful software development:
...one of the core reasons why agile development makes more sense than waterfall: from a risk management point of view it is foolish to take a "big bang" approach where you have few opportunities to satisfy your market.
Few opportunities to satisfy your market. Surely we don't want that, do we?
I'm happy to see folks trying to improve on the existing Java web frameworks (I'm especially anxious to see whether Wicket will relieve us from the horrors of Tapestry) but...
...is it just me or does it seem like someone's astroturfing the RIFE thread at TheServerSide? I mean, the first three posts are like they were written by someone with a bachelor's in marketing, and looking at the post history of the said three users, we can see that they've only posted in threads where Geert (the author of RIFE) has posted (or in the one started by Dion about different Java web frameworks). Plus, a couple of those names are the same guys that show up on the testimonials page at rifers.org.
Please tell me I'm imagining things.