Category: Software Development

Code samples not enough anymore

It’s becoming quite common for employers to ask to see code samples from prospective developers. This doesn’t really go far enough.

The next step up is to see the VCS history as well. A small sample – say, a couple of hours of work – can reveal a lot about how a person works – more than the code itself. Do they write tests first, or do they backfill later? Do they refactor their code to promote readability? Do they commit regularly, with meaningful comments, or do they just push bits in randomly?

With good free VCS hosting – like GitHub and BitBucket – anyone can easily create sample code and put it online for your potential employer to see.

So the next time an employer asks for a code sample, take it up a notch and give them the entire history as well. (And yes, I practice what I preach)

AiL – JBehave and Spring

Having succeeded in getting a simple JBehave story running. my next challenge is to scale it up a bit. In particular, I want to get a JBehave story that integrates with Spring to do something more fully-featured: save an entry in a database.

Continue reading “AiL – JBehave and Spring”

Source Code vs Documentation…

In any battle between the source code and the documentation, the documentation always loses. Note that this is not the same thing as the source code winning.

Continue reading “Source Code vs Documentation…”

AiL – Simplest JBehave Scenario

In the last segment, I managed to get JBehave reporting under Maven using a pre-canned example. This time, I want to tackle the other extreme – I want to develop a single story in JBehave and see what’s the bare minimum it takes to get it running, inside an IDE (in my case, Eclipse)/

Continue reading “AiL – Simplest JBehave Scenario”

AIL – JBehave Trader Example, standalone.

JBehave comes with some very comprehensive examples, so I thought I’d start there to see if I could get one of them building – and reporting – under Maven. The example I chose was the ‘trader‘ example, which you can see at github.

Continue reading “AIL – JBehave Trader Example, standalone.”

Adventures in Learning… JBehave

A couple of years ago, I got the ‘specification-by-example’ bug. I was playing with this new project called Cucumber, and was really enjoying the idea of specifying examples in an English-like syntax that testers and BAs could supposedly read. (I say supposedly, because it never really took on at my previous place-of-employment. Which was a shame). Nonetheless, I enjoyed it, and advocated it when and where I could. Heck, if nothing else, it was an excuse to write support code in Ruby as a break from the Java stuff.

Continue reading “Adventures in Learning… JBehave”

Junior Developers considered harmful.

In my last post, I mentioned that the biggest reason for producing shit code (in my opinion, anyway) is that we let junior developers run around unsupervised. That’s worth expanding on.

Continue reading “Junior Developers considered harmful.”

How to write shit code that works

There are three basic approaches to writing software that I know of. The first is always strive for technical excellence. This is great if you can do it – I’ve never worked in a place where technical excellence was always priority #1 with no compromise. If that’s you, then you probably don’t need to read this.

The second way is throw code around and hope it works – this is far too common. You look at the problem in front of you, and you grab a solution that’s good enough for now, doesn’t blow the budget (time and money) too badly, and leave the mess to be cleaned up (or worked around) later. Industry wide, this is the norm – a consequence of always focusing on the short term.

The third is a pragmatic compromise – try to make it as good as possible, while recognising that parts of the system will be, well, shit. That’s what I want to talk about here.

Continue reading “How to write shit code that works”

Is rewriting the code “startup suicide”?

Came across this article by Steve Blank – “Startup Suicide – Rewriting the Code“. This can be summed up as:

  • Under the pressures of growth, some startups allow their code base to get messy.
  • This mess – and the pressure to keep it working – results, over time, in a slower delivery of features.
  • This leads to a failure to adapt, which is seen as an existential threat to the future of the business,
  • The business decides that a rewrite of the product is the way to go.
  • This leads to death.

I don’t dispute the main premise of the article, but I do dispute the title. The answer is to rewrite the product. The question is: how do you do that?

Continue reading “Is rewriting the code “startup suicide”?”

Moving right along…

Wow. It’s been over seven years since I last wrote a post like this one. I have resigned from Wotif (almost three weeks ago now) and am taking up the carefree life of the independent contractor. Should be a blast. In between, I’m enjoying some downtime and recharging.

Continue reading “Moving right along…”