Author Archives: Paul Barnes-Hoggett

Building A Pristine Rails Virtual Machine

A (thankfully) long time ago in a galaxy far far away I developed web apps in Flash. And when I had to target different versions I had to go through a whole rigamarole of uninstalling and reinstalling plugins. Fast forward to now and I’m often working on projects in Ruby. I’ve found RVM and gemsets […]

Posted in Agile Software Development, Engineering, Rails, Ruby, Software Craftsmanship | Leave a comment

Using Puppet and Vagrant to make a one-click development environment

Rees's Polygraph

Keeping a development environment clean and tidy can be a bitch. When you are working on multiple projects across different platforms it can get messy really fast. And if you’re managing a team of people and need them all to run your app locally things can get tricky too. Recently I’ve setup a process so […]

Posted in Agile Software Development, Engineering, Rails, Ruby, Software Craftsmanship | Leave a comment

An external keyboard for the iPad; making the right choice

As I mentioned in my previous post, I’m traveling for the next few weeks on a sabbatical to Europe and Asia. I’m keeping a journal of my travels on my tumblog, and from time to time figure I’ll be writing longer text posts here. Because of this, I figured that I should bring an external […]

Posted in Tablets, Travelling Light | Leave a comment

Tablet only living—A geek travelling light

In about a week’s time I’m taking off on a sabbatical. I’m fortunate enough to have employers who have agreed to let me off the leash for a few weeks, so I’m making the most of it. I’m using the opportunity to take myself off on a journey that will take me from Berlin to […]

Posted in Tablets, Travelling Light | 4 Responses

Performance – spend it wisely and never raise the debt ceiling

The US had it’s credit rating downgraded yesterday. For many people, it seems at first a little abstract and vaguely ominous—a chance for China to get it’s own back after being harangued by the US on its undervaluation of the Yuen. Maybe the outcome will be catastrophic, maybe not so much. Only time will tell. […]

Posted in Engineering, Quality Software, Software Estimation | Leave a comment

Have you been hurt by code reuse? Learn from De Niro

Ever used someone else’s code; a library or sample app online? Ever got to a point where it’s been so mind-bendingly painful that you rue the day you ever found the stupid ‘library’ in the first place? If not then chances are you’re not a developer, you’re this guy, or you’re delusional. Spurred by a […]

Posted in Quality Software, Software Craftsmanship, Test Driven Development | Leave a comment

Try this, my mini-application for software estimation

A couple of weeks ago I wrote about a simple yet powerful process for software estimation. When I was done I started to look at my excel worksheet for doing this process and figured that it could be something I could share with a broader audience. Rather than just post an excel file, I decided […]

Posted in Agile Software Development, Quality Software, Software Estimation | Leave a comment

Software Estimation — A good simple way courtesy of the Navy and the cold war

In my last post I told you that your next project will take longer than you think. Now I’ve destroyed hope I’m going to show you how you can use this knowledge to be better at software estimation. We’re going to use a simple but very effective technique first developed by the Navy back in […]

Posted in Quality Software, Software Estimation | 4 Responses

Your project will take longer than you think and less than a Nukem

I will tell you how long your next project will take to release. You won’t like it, but I’ll tell you. A game is launching this week and in the story of its development is the key to successful software estimation. The game is Duke Nukem Forever, and just like the title, it did pretty […]

Posted in Quality Software, Software Estimation | 3 Responses

Making Quality Software: how to test non-functional requirements

In my last post, I outlined what I think are the twelve key constraints you need to think about if you are going to build high quality software that people want to use. As I mentioned, thinking through this needn’t be a mind sapping endeavour, and for some things you may just decide it’s not […]

Posted in Quality Software | Leave a comment