Monthly Archives: July 2004

General

Blogging: does this signify the end of NNTP?

2 Comments

Earlier this year (2004), I wrote an article called Change Imperative.

In that article I discussed how I set about changing my e-mail client and my NNTP newreader tool. It’s not important, but I chose TheBat and XanaNews.

Anyway, since I wrote the article, I’ve pretty much given up reading NNTP newsgroups. Why? Well, I’m getting a similar, but higher quality, more focused “fix” of information from the blogs that I’m subscribed to.

I think that’s the key: “subscribed to” and “focused”. I choose which blogs to subscribe to because their authors offers me a more focused view. Previously, using NNTP I had to filter through a lot of dross in order to locate good content. Indeed, a lot of NNTP groups have their resident “bozos”. Luckily, XanaNews has a “bozo bin” – which is just great for filtering out dross.

Of course, the blogs that I subscribe to are telling me when they’ve been updated (either via an RSS or ATOM feed).

Under the hood, we’re all merrily blogging away, carefully classifying each post using categories. This is very similar to the NNTP grouping hierarchy – folks can choose to subscribe to blogs that offer them, say, Test-Driven Development content. Except, blog content tends to be of higher quality, it’s more focused and bozos are just ignored. Ultimately, I have less to read because of the focused content – in reality I subscribe to just over 100 RSS feeds, so the time-saving balances out.

Does this mean the end of NNTP? Given that I pretty much stopped using NNTP over a period of three months (having been a user for longer than I care to remember), perhaps NNTP has a limited lifespan? I know that I can’t be alone.

Roll on the Semantic Web – the profusion of information sources makes the delivery of a real information aggregator even more essential. I’ve downloaded Haystack . I have soft spot for this kind of tool, perhaps because there’s an XML element (no pun intended) relating to how such a tool might work: XML Topic Maps. I’ll blog about Haystack later.

Now, I do have one concern: we’ve all got RSS aggregators, right? And they periodically go off and update themselves, pulling new RSS content from all our subscriptions. Isn’t all this extra traffic going to slow things down? Suddenly, sites that enjoyed average traffic are suddenly having to serve up MBs worth of RSS content to thousands of subscribers. Bandwidth is going to go through the roof. I’m off to check my stats: I’ll blog about my findings later.

Development

Hire Developers, Not Programmers

Eric Sink has written another fine article. His first article, Make More Mistakes was fantastic – if you’ve not read it, I can strongly recommend it.

In his article about the Hazards of Hiring, Eric must have been sat at the back of one of my presentations: he describes “programmers” and “developers” in exactly the same way I do! Indeed Eric has blogged about it here. Another fine piece of writing.

When necessary, however, I do state that some tasks bring the developer down to the same level as the programmer. For example, when discussing Test-Driven Development (TDD), I believe it is the person at the coal-face who should be writing the programmer tests. Whether a developer writes them, or a programmer writes them, in my opinion is neither here nor there.

However, as for Eric’s thoughts? I agree: I was a programmer in my youth, I just churned out code.

Back then, despite my title (Library Programmer), I became a developer…because the distinction Eric and I agree on wasn’t written down back then. The team I worked with also were developers: we took an open-minded approach to challenges, in many cases turning what might have sounded almost impossible into reality.

After that, I took a position that allowed us to customise our job title to suit what we were doing at the time: enterprise development. We kept a focus on the bleeding edge – everything we did involved XML, it was so cool back then. Nowadays of course, XML has its place, but we don’t have an “XML everywhere” scenario anymore.

Since then, I’ve still kept the word ‘development’ in my title: because I believe that one shouldn’t pick a single track and follow it. It’s important to be able to lend a hand to many tasks without selling yourself as a Jack of all trades, that’s totally different from being a Developer.

Nowadays, I’m a Certified ScrumMaster, with a strong bias towards all things Agile. I can see how Agile could have helped me/us on earlier projects. Equally, somewhat prophetically, can see that Agile will bring my current project in on time and within budget. So much, so I’ve signed up to SellingAgile, Clarke‘s Yahoo group aimed at individuals and developers who need to understand how traditional approaches can be improved by adopting Agile approaches.

Lending a hand to many tasks facilitates getting the job in hand completed through team-work, drive and focus. Developers can do this, they have the mind-set – hire developers, not programmers: good advice, I’ll follow it when I set up my own shop.

Development, TDD

How big are your steps?

I re-ran my An Introduction to Test-Driven Development session yesterday…to an exceptionally interactive and responsive audience.

The slides are free to download here (1134k). Feel free to download the Delphi 5-7 code, the Delphi 8 code or the Visual Basic.net code.

I was using DUnit with Delphi 7. I re-iterated the fact that eXtreme Programming and TDD extol the virtues of “doing the simplest thing that could possibly work”.

Read more about the session here.

Tied in with this debate was a lengthy discussion about the concept of “small steps”.

Early on in my session I took lots of really small steps, panicking the audience slightly as they wondered how long it would take me to get from 1 to 2000 in Roman numerals (I was applying TDD to a Roman numeral conversion class).

TDD promotes the notion of taking plenty of small steps, gradually taking slightly larger steps as your confidence increases. However, the instant you step over your mark and take a step that’s too large, you should revert to taking smaller steps until to regain your confidence.

The size of TDD steps is important and it’s one that you have to be happy with yourself: a “small step” that works for you might be a large step to somebody else. It’s about finding a happy medium – go out and try TDD for yourself, make the mistakes that I did, take large steps, try to do too much in a method and test. It’ll all come out in the wash and eventually as Erich Gamma said, you’ll be “test infected”

Want to learn more about TDD? These books are highly recommended:

Test-Driven Development in Microsoft .net
Test-Driven Development: a practical guide

Test-Driven Development: a practical guide: Reviewed here.

Test-Driven Development by example

Development, TDD

Doing “the simplest thing”

2 Comments

I re-ran my An Introduction to Test-Driven Development session yesterday…to an exceptionally interactive and responsive audience. The slides are free to download here (1134k).

I was using DUnit with Delphi 7. I re-iterated the fact that eXtreme Programming and TDD extol the virtues of “doing the simplest thing that could possibly work”.

About half way through my session (which could easily have run on to 2 hours had dinner not got in the way!) a well-respected friend, Adrian, raised his hand and said: “Building a class isn’t the simplest thing!”

I had built a class that converts integers into Roman numerals. The first step was to add a method, toRoman, that took an integer and returned nothing. The second step was to have it return ‘I’ when ‘1’ was passed in as a parameter. Feel free to download the Delphi 5-7 code, the Delphi 8 code or the Visual Basic.net code.

Of course, he was right, building a class that has one method returning the letter ‘I’ is overkill. It’s not the simplest thing. Everybody knows that the simplest thing would have been a simple function with no class wrapper and no hint of object-orientation.

I realised that what I had done was the simplest thing the could possibly work in this xUnit testing framework. It wasn’t the simplest thing that might get the job done.

Similarly, in an earlier re-run of the same session, Andy, pointed out that my idea of the simplest thing perhaps wasn’t his. And herein lies one of TDD’s ironic facets: whilst TDD provides us with a great understanding of “how” a piece of code should be invoked, thus increasing the chance that somebody other than the original developer/programmer will be able to understand it, TDD can be an emotive process.

TDD will help you as far as your “under the bus count” goes, it will give you the most accurate form of documentation that you’ll ever have for your code base, but it won’t help you ring fence or blinker your programmers in to writing code the in the same way. But, since that’s not something any of us should relish, Borg-like programmers churning out the identical code for the same problem, it shouldn’t put you off TDD.

I’ve just googled under the bus count only to realise that it’s not defined anywhere.

I’m using the phrase to mean:

    the number of people on a project who need to be run over by a bus, that will then make the project fail or incur a severe cost/time delay

If you are on a project with a team of one: yourself, then the under the bus count is one. If one person, you, is run over by a bus, the project fails, or meets almost insurmountable cost/delays. Of course, if it’s just you on the project team, you probably don’t need to worry about who’s going to be picking up the project after you’re gone!

Ideally, you should try to drive your under the bus count upwards, away from one. There should be no single point of failure, no empire-builders.

Go practice TDD, trust me, it works. It heralds a new confidence that will allow you to improve (refactor) huge chunks of your code base that you’d probably never want to touch citing “if it a’int broke don’t touch/fix it”…when you know perfectly well that the internal design is like a house of cards and won’t survive the next bout of customer change requests. It improves the quality of your life…there, what else goes this far?

Want to learn more about TDD? These books are highly recommended:

Test-Driven Development in Microsoft .net
Test-Driven Development: a practical guide

Test-Driven Development: a practical guide: Reviewed here.

Test-Driven Development by example