Abject Oriented Programming

Posted by Kerry Mon, 16 Jul 2007 06:49:00 GMT

Greg Jorgensen: Abject Oriented Programming

The number of lines of code in the application is a common measure of the importance of the application, and the number of lines a programmer can produce in a day, week, or month is a useful metric for project planning and resource allocation.

Lovely analysis of how projects actually work, of course the funniest part is the commenters who just don’t get the irony:

Overloading is actually the practice of using the same function name twice, with each handling different inputs.

Tiny Types

Posted by Kerry Sun, 15 Apr 2007 13:14:00 GMT

Darren Hobbs: Tiny Types

I consider it playing to the strengths of a statically typed language.

I like this pattern, and have used it once on a large Java project. Generally I prefer dynamic languages, Smalltalk and Ruby etc, but if you have types why not use them effectively.

Blaine Buxton puts it in terms I like:

Tiny objects make unit testing easier, aid in reuse, stop duplication dead, provide for better messages when things do break, puts functionality closer to where it is used, and I could go on all night.

I don’t necessarily use this all the time, I find a lot of developers reject the idea because of the number of Types you end up with. If I’m working on something of mine, or from scratch then I’ll use this approach, otherwise I tend to stick to the style of the original author.

One thing I’m not sure about is an example Darren wrote:

It’s much harder to accidentally pass dollars into a method that was expecting pounds sterling (but actually took a double so it could have been anything).

Money is money is money, would some methods really only take Sterling and not Dollars? Ever? Maybe this was a passing comment or maybe I don’t get this particular example.

This is a good technique to learn and I’d encourage anybody who hasn’t used it to give it a go. Maybe you’ll like it or maybe not, at least you’ll know. One really good outcome that I find is behaviour finds itself in a Class where it belongs, not in some Manager/Helper class just because it’s the first place the behaviour is needed. Not only does this technique work for primitives, but it works equally well for collections, especially where you have some find/collect type methods.

The Software Inferno

Posted by Kerry Thu, 05 Oct 2006 07:56:00 GMT

Bob Runstein on “The Software Inferno(How to convince management of the value of tests)

It can be difficult to convince people the value of unit tests.

In my experience, it’s easy to convince people, developers and managers alike, on the value of Unit Tests. It’s even easy to get everybody to agree to do them. What’s hard is getting developers to actually write them, maintain them, and even just run them.

You heard me right: Most people don’t give a flying fuck about actually doing Unit Testing.

They pay lip service to the idea because they are told it’s the right thing to do. Mostly I think developers find it hard to test code that has to work with external processes, databases, web servers and the like. It’s not until a developer goes through a Test-Develop-Test-Release-Fail-Test-Develop-Test-Release cycle that they even begin to see the real benefit. And even then they still might just not do it.

I always say my piece about Unit Testing, but whatever the outcome is I will always write tests. For me, it’s the same as repeatable builds, continuous integration, and even source control.

Smalltalk Design Principles

Posted by Kerry Wed, 04 Oct 2006 20:33:00 GMT

August 81 Byte article entitled “Design Principles behind Smalltalk”:

The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone.

Sounds like a good premise for a language. Link to full text.

FindBugs

Posted by Kerry Wed, 04 Oct 2006 11:48:00 GMT

After reading the generally positve post about Find Bugs from the Hibernate group blog. I thought I’d give it a go. I used the command line version, it seemed to be the easiest way to get going, and it was, very easy. The results on a small body of code were interesting and valuable.

I think I’ll reserve real judgement unitil after I try the Eclipse plugin. I think running tools like this apart from the IDE or during the build are Ok, but more often than not they are ignored by the majority of developers. Having them flag warnings/errors in the IDE though makes people pay attention, and that’s the real value.