Programming
It’s not done yet
It’s good for software developers to experience joining projects that are at different stages of their development lifecycle. At the start, faced with an empty repository where you get to make important decisions every day, write a lot of code and functionality, and understand how everything fits together. In the middle, worrying about all those little details, dealing with testers raising defects, running into gotchas that obliterate fundamental assumptions, taking an application into production. And at the ‘end’ when a project is already running in live, fixing bugs and adding new functionality to a codebase you don’t really understand, where writing one line of code that doesn’t cause breakage is an achievement. (Ok, so I’m talking about writing server-oriented “business” applications. If you’re working on different types of software or in different environments then your mileage may vary.)
At my current job I’ve been fortunate enough to work on three projects covering each of these cases and I’ve learnt a few things along the way.
› Continue reading
Components vs Services
(This post is a bit unpolished, being a slightly edited copy of something I wrote on the train to work last Wednesday . No matter. I declare a Blogothon Principle – it is better to publish a post that isn’t ready than to miss out a week due to noble intentions …)
There’s a receipt on the table in my lounge. On the front: 1 Original Bianco Salmon pizza from Papa Johns West End Lane. Expected on 30/03/2009, at 21:05:31. On the back are some scribbles I made at 5am the next day. “Django little rest apps”, “Ruby _why mount little app”, “OMG it’s J2EE”, “seam -> EJB 3.1″, “coarsed grained well-defined interface”, “reusable component”, “can move to diff. servers, cluster etc.”, “EJB vs SCA”, “runtime vs design time”.
› Continue reading
YO DAWG I HERD YOU LIKE XSL
I spent most of this week writing XSL templates for transforming XML messages into other, similar, XML messages. Ah, bless.
Thanks to the practice of companies (including us!) making minor changes to standard XSDs, several of the input/output format combinations are identical apart from namespaces and a couple of tag names. Copy-pasting a template six times seemed like a bad idea – it contains some non-obvious bits, and the formats are bound to change since the requirements aren’t yet nailed down.
› Continue reading
Benefits of automated functional testing (was: Why unit testing is a waste of time)
Update 2009-06-30: Despite the attention seeking title and first few paragraphs, the point I was trying to make with this post was about the benefits of automated functional testing. Since it’s been posted to proggit and hacker news, a number of people have objected to the misleading intro. Apologies for that, and please start reading from “Benefits of automated functional tests” if you’re not interested in the misdirection! — Tim.
In the last few years of writing “enterprise” software in Java I’ve created and maintained thousands of unit tests, often working on projects that require 80% or better code coverage. Lots of little automated tests, each mocking out dependencies in order to isolate just one unit of code, ensuring minimal defects and allowing us to confidently refactor code without breaking everything. Ha! I’ve concluded that we’d be better off deleting 90% of these tests and saving a lot of time and money in the process.
› Continue reading