Eyefodder - Page 2 of 5 -

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

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

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”?

Posted in Quality Software, Software Estimation | 4 Responses

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?

Posted in Quality Software, Software Estimation | 3 Responses

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 | 5 Responses

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.

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

Code Coverage with Flex – ANT build for running the viewer

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

In my last post, I gave you my ~~elegant extension~~ hack for generating EMMA style code coverage reports from FlexCover. This post covers the first route I took to incorporating this in my build process. It does work, but it’s not very consistent in its reporting and I’ll explain why at the end…

Posted in Agile Software Development, Continuous Integration, Flash & Actionscript | 5 Responses

Code Coverage with Flex – creating EMMA formatted reports

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

Over the last few months I have adopted Hudson as my build machine of choice as it is just so easy to setup and administer. Another thing I really like is being able to watch the trend of the number of tests in my test harness over time. It’s not the best metric, but it does act as a reasonable motivator.
A slightly less crude metric is code coverage, which measures the amount of an application that gets exercised when it’s run. FlexCover is a very cool tool for this and props to my colleague – Alex Uhlmann and Joe Berkowitz of Allurent for the great work they’ve done. There is a great UI for exploring code coverage in detail and it can also export xml formatted reports on coverage.
The thing is, I want to be able to track code coverage over time in Hudson, just like I can with the number of tests. I achieved this by extending FlexCover to output EMMA formatted reports…

Posted in Agile Software Development, Continuous Integration, Flash & Actionscript | 5 Responses

FlexUnit eclipse plugin alpha

By Paul Barnes-Hoggett | Published: August 30, 2007

I’ve been kind of quiet recently for three reasons:

Its summer
Work has been insanely busy
I’ve been beavering away on a new plugin for eclipse

The plugin is designed with one key goal in mind: shortening the develop-test feedback loop. It integrates eclipse and the flexunit framework to make our lives as developers easier.
The plan is to release the plugin on labs as soon as possible (I’m about to go on holiday for a couple of weeks so it’ll be October at the earliest…) but I thought I’d give you an early heads-up on what I’ve been doing when its been too hot to walk the New York streets…

Posted in Agile Software Development, Flash & Actionscript, Test Driven Development | 1 Response