Good stuff

| 4 Comments

I use BlogLines to read my RSS subscriptions. It's pretty good, and now that the performance issues I had initially seem to have gone away, I like it a lot. It's very handy to be able to read my feeds from anywhere and always have them up to date and synchronised. One of the features I like is the little "keep new" check box that each item has; check it and the item stays unread. I use this to keep the interesting stuff on top so that I can write about it later.

This week I've been busy with my deadlock tool; lots of coding, not a great deal of time to write long and considered blog entries. So, here's a list of some great blog postings that I tagged for later comment and never got around to commenting on.

The ordering is merely the order that they're stacked up in Bloglines...

1) Why project delivery bonuses suck - from Kevin Barnes over at "Code Craft". Kevin writes a lot of really good stuff and this one really hits the nail on the head. I've worked in a lot of investment banks over the years and they use these kinds of bonuses a lot; I've never seen a good outcome from their use, the project always gets twisted to achieve the date and the future usability and maintainability is always the thing that gets sacrificed. In the end they're giving bonuses to write shoddier software that will cost more to fix and extend in the future...

2) Three reasons to reinvent the wheel - another excellent piece from Kevin Barnes. Sometimes there are good reasons to build it yourself from scratch.

3) In Defense of Verbosity - Jeff Atwood at "Coding Horror" on why saving keystokes whilst writing code is a fool's economy. As always Jeff's spot on with his analysis and backs up everything he says with references to Code Complete. Personally, I'm quite happy with the conciseness of } given my style of coding (I don't nest too deeply and I use lots of really small functions for stuff so it's always easy to know what the current } applies to; but his point applies to all aspects of coding. Write for the reader, not the compiler!

4) Manage Dependencies not Aesthetics - David Chelimsky over at "But Uncle Bob .com". A nice piece on design and the Single Responsibility Principle.

5) Classic Technical Lead Blunder - Jeremy D. Miller over at "CodeBetter.com" (note that you can subscribe to Jeremy's feed directly rather than subscribing to the whole crowd at CodeBetter.com, a much better option IMHO). A good piece for all who are leading other coders; I've probably made all of these mistakes a couple of times. Some are easy to stop yourself from doing, others less so; the "Detailed work assignments" mistake is spot on and an easy mistake to make.

6) What's so great about Inversion of Control? - Jeremy D. Miller again. Excellent piece on designing for testing which could be used to counter the next posting...

7) Why unit tests are disappearing - Cedric over at "Otaku, Cedric's Weblog". Cedric disagrees with Michael Feather's "rules" on what constitutes a unit test. I disagree with Cedric ;) and feel that he's missing the key point of Michael's rules; "Tests that do these things aren't bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes." If you try and stick to the rules then you'll end up breaking the file access, or database access, etc, out into quite a small and simple class that does just that. The rest of the system can deal with these classes via interfaces and can therefore be tested without using the database or file system but instead from a mock object. If you disregard the rules you're less likely to do this breaking apart, your classes violate the SRP and you end up mixing business object to file format type code in with file access code which makes it harder for you to switch to alternative persistence methods in the future. So, stick to Michael's rules and read 6) for a much better explanation of why.

8) Ferrari versus Land Rover - Mark Pearce (who lives near me, apparently) over on "Fighting the Plumbing since 1979" (great name for a blog and not just because I spent the first 10 years of my working life doing just that... ;) ) - Although this piece is a response to my Assert is Evil posting from last week, and, whilst I've responded to that aspect of it there's more here that I feel I need to respond to. The whole Ferrari verses Land Rover idea and the suggestion that most C++ behaves like a Ferrari and most VB like a Land Rover... I think, it depends. Some kinds of program can safely act like a Land Rover and some must act like a Ferrari. Often the programs that can be like a Land Rover can be written in VB...

9) Multi-platform Images - Mark Russinovich over at "SysInternals". Mark shows us how he packages the SysInternals tools as a single executable file that can run natively on multiple platforms (32bit & 64bit Windows) by embedding the 64bit executable inside the 32bit exe as a resource. I've embedded dll's in exes in the past, we used it for the simple downloadable driver stuff for my WebRemote Lego Mindstorms over Netmeeting code (3 dlls embedded in a single exe which you downloaded and ran to unpack and register the dlls). The embedded driver technique that Mark mentions is mentioned in the RootKits book that I'm currently reading. Oh, and don't miss the link to James Finnegan's article; well worth reading if you're starting out with driver development...

10) There's no feeling like releasing software... - Robert over at "Software is too expensive to build cheaply..." A nice piece on releases and agility; I have to agree that you can tell how likely a project is to succeed by the "pulse" of its production releases. I've worked on systems where the release schedule is so slow that the team almost forgets that's what they're working towards and on projects where we released twice a week every week. I know which one was better and I know which one had the most polished release procedures and dealt best with release problems, rollbacks and hotfixes. The less often you release the harder a release is because you're less used to doing them and you are less likely to have automated all the things you need to have automated. When you're releasing twice a week to a trading desk you make damn sure that everything that can be automated is automated and that you have lots of regression tests in place.

4 Comments

I favor RSS Bandit myself. I recently found several interesting blogs through your "Blogs that I read". Thanks Len!

Here's a recent post on unit testing I thought you might be interested in: http://wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html.

Thanks for the link, Harold. There's good stuff in the comments. Subscribed to the blog, thanks.

I used to use SharpReader but I really needed a reader that I could use from anywhere and SharpReader started to annoy me due to the memory it used and the way it made my CPU fans and my disks chug when it decided to do stuff.

The bloglines published list of blogs is quite useful. I use the 'blog roll' option over on my skiing blog as I have a small amount of blogs in my "ski" folder. I have too many blogs in my "tech" folder and it slows the loading of the main pager here if I use the blogroll style here; the link to the blogs I read seems to work OK though.

Len,

I think we're in agreement. My point was that it's more important to separate fast tests from slow tests, and in that regard, deciding whether a test is a unit test or not is irrelevant (or even useless).

This is why TestNG's group tests are so important: when you write your test, you can immediately tag it as belonging to a certain group, and then you decide at runtime which tests to run.

--
Cedric

Cedric

The only downside in separating tests like that is that it might be seen as acceptable to write lots of slow tests ;)

I can see that grouping tests like that could be useful though. I still think it's quite important to try and go along with the spirit of what Michael was implying. I find that if you do then you end up with very small areas of code that need to access these slow resources. The rest of the code can be tested very quickly and you end up with flexibility due to the fact that you're not tied to a persistence mechanism...

Leave a comment

About this Entry

Opera lover was the previous entry in this blog.

Barry's take on Assert is the next entry in this blog.

I usually write about C++ development on Windows platforms, but I often ramble on about other less technical stuff...

Find recent content on the main index or look in the archives to find all content.

I have other blogs...

Subscribe to feed The Server Framework - high performance server development
Subscribe to feed Lock Explorer - deadlock detection and multi-threaded performance tools
Subscribe to feed l'Hexapod - embedded electronics and robotics
Subscribe to feed MegèveSki - skiing