An external keyboard for the iPad; making the right choice

By Paul Barnes-Hoggett | Published: February 13, 2012

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 keyboard with me and I’ve already found it to be a tremendous help. Even writing short emails is so much easier on a real keyboard. When I was researching, I quickly narrowed it down to two choicee: The Apple wireless keyboard (with the Incase origami case) and the Zagg Zaggfolio case and keyboard.

Read More »

Posted in Tablets, Travelling Light | Leave a comment

Tablet only living—A geek travelling light

By Paul Barnes-Hoggett | Published: January 31, 2012

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.

On the road again, and learning to be more like a car than a truck


I’m using the opportunity to take myself off on a journey that will take me from Berlin to Bangkok, from Paris to Paro. But this isn’t just a grand tour where I’m off to ‘find myself’ (although I will be travelling to PBH)—I’m also using this as an experiment in tablet-only living.

Read More »

Posted in Tablets, Travelling Light | 4 Comments

Performance – spend it wisely and never raise the debt ceiling

By Paul Barnes-Hoggett | Published: August 6, 2011

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. What Standard and Poor’s have basically said is that there is more chance than before that America will fail to pay its bills on time. But what does this have to do with quality software and how it gets built? Well here’s the thing—the way the US government are managing the economy and the debt ceiling are very similar to the way many software projects go slowly south; everyone recognizes that something needs to be done, but none can agree on what the right course of action actually is.

Stock market crash "100 dollars will buy this car, lost all on stock market"

Don't overpromise and foreclose on your project

Read More »

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

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

By Paul Barnes-Hoggett | Published: July 6, 2011

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 conversation with Mateo, my friend and former development buddy about this, I started to think a little deeper about what the problem is with code reuse. We expect a well-made production quality piece of work, and before long we realize that we are stuck with something that is sucking time away rather than letting us develop the hard stuff faster. So when should you reuse code? Here are some thoughts on when you should proceed with abandon, and when you might want to be more cautious…

We think we are getting this...


...but often end up stuck with this

Read More »

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

Try this, my mini-application for software estimation

By Paul Barnes-Hoggett | Published: July 5, 2011

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 to create a simple software estimation app and post it here. You can go check it out now, or read on to get a bit more detail into the thinking behind it.

Screenshot of the software estimation app

The estimation app in action

Read More »

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

By Paul Barnes-Hoggett | Published: June 19, 2011

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 the ’50s when they were building the Polaris nuclear submarine. Faced with tremendous risk and uncertainty, they had to work out how to build a missile that had never been built before, to be carried on a submarine more complex than contemporary technology would allow. And by the way, they had to work out how get a missile to launch underwater and hit a target thousands of miles away when no one had built a decent guidance system before. Oh, and the Russians were breathing down their neck with the Sputnik project. The Navy managed to develop a system of estimation and risk management that was so effective, they delivered three years early. Think your project is harder to estimate than that? Think again. Get on board and read on to find out how you can use this technique for your own means…

How long would it take you to build "the free world's most formidable weapon"?

Read More »

Posted in Quality Software, Software Estimation | 2 Comments

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

By Paul Barnes-Hoggett | Published: June 16, 2011

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 much take forever to launch. Five thousand, one hundred and sixty days to be precise. That’s just over 14 years. Longer than it took to build the Empire State Building, the Golden Gate Bridge and the World Trade Center combined. It took so long, people have put up sites covering how long it took. The game is by most accounts at best mediocre and at worst atrocious—in my highly opinionated view, the duration of a release is inversely proportional to product quality. But that’s not the story here. What’s important is why it happened and what it can tell you about software estimation on your own project.

Duke Nukem Forever Launched after 14 years development; what can this big chested antihero teach you about your project?

Read More »

Posted in Quality Software, Software Estimation | 3 Comments

Making Quality Software: how to test non-functional requirements

By Paul Barnes-Hoggett | Published: June 10, 2011

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 important right now. Here’s the rub though; once you’ve decided something is important enough to define as a constraint on your system you’d better think about how you’re going to test it. If not, you may as well kiss the requirement goodbye as eventually people will stop paying attention to it. Here’s how I would go about testing each of those twelve constraints:
Read More »

Posted in Quality Software | Leave a comment

Making Quality Software: 12 non functional requirements every app should have.

By Paul Barnes-Hoggett | Published: June 7, 2011

When people talk about really great quality software, they usually think in terms of it’s utility, simplicity or aesthetics. But there’s more to it than that. A really great piece of software will bleed quality through and through like a piece of Brighton Rock (or Bognor Regis). What separates high quality software from mediocrity? It’s being aware of and planning for the right constraints to put on the way you develop software. Frank Lloyd Wright did his best work in tightly constrained spaces and awkward sites, and as software engineers we need to do the same to avoid flabby work. Here’s my list of twelve constraints I’d plan for on my next project:
Read More »

Posted in Quality Software | 2 Comments

Code Coverage with Flex – a headless agent for CI builds

By Paul Barnes-Hoggett | Published: July 28, 2009

In my last blog post I gave details of how I user the modified code coverage viewer for flex in an automated build to follow the trend of code coverage over time. The trouble with this approach was that there was a problem either with the localConnection in flex or the code that uses it and there was a wide variance of the values being reported. This post shows you how I fixed it by creating a headless code coverage reporter that you can drop into your test harness and remove the need for a second application altogether.

Read More »

Posted in Agile Software Development, Continuous Integration, Flash & Actionscript | 22 Comments

  • Stay in touch!

    If you want me to let you know when I add new posts, drop your email here

    * = required field