Sceneric Thinking » Delivery

Recognising Launch Anxiety

jimherbert — Thu, 08 Dec 2011 02:01:02 +0000

With every project there will come a time during testing where the bugs are being raised, and fixed and classified in the usual way:

Blocking bug – can’t launch with one of these
Major bug – don’t want to launch with more than X of these
Minor bug – don’t want to launch with more than Y of these

No matter how well the project has gone, there will come a point when the pressure is on to launch and suddenly those Major’s seem like Blockers or “actually, this Minor is more important than this Blocker can you work on that”. At Sceneric we call this “launch anxiety” and it can stop a project on the brink of success. How to recognise it?

Track the bugs in a decent bug / task tracking package (we use Jira & Greenhopper)
If, close to launch deadline, there is a sudden upward trend of Blocking bugs – sit down and discuss as a team. Are these *really* Blocking bugs, or is it a way of delaying launch (which might be useful from a dependency perspective), a genuine fear of launching or simply a way to get “best value for money” in the dev phase

If launch anxiety is taking hold, it’s important to clients and vendors alike to remember the cost of not launching. We often see 100% increases in online revenue with new sites – it begs the question “is this bug really stopping me from launching my site and missing out on that extra cash?”

Integrating SVN and Mantis on WAMP

jimherbert — Tue, 12 May 2009 22:30:07 +0000

A superb blog article here:

http://alt-tag.com/blog/archives/2006/11/integrating-mantis-and-subversion/

describes how to integrate SVN and Mantis, however the post-commit hook is for linux. To do this on windows:

post-commit.bat

SET REPOS=%1
SET REV=%2
SET TMP_LOG=%TEMP%.\svnfileTMP-%REV%
D:\\bin\svnlook log -r %REV% %REPOS%>%TMP_LOG% 

D:\\php.exe -q D:\\core\checkin.php < %TMP_LOG%

Quality not quantity

jimherbert — Sun, 15 Mar 2009 10:08:02 +0000

As an SME consulting company, we often come up against large offshore development set-ups and the classic accountancy argument “We’ll use them as their day rates are a fraction of yours”. There is an obvious problem with this – software development is complicated and expertise gained over years of coding, integrating and testing can lead to orders of magnitude of improvement in speed of development and subsequent quality.

We’ve recently come up against an excellent example of this. While on client site, we were integrating to a credit card provider in Mule via web services. Mule supports CXF, Axis 1 and Axis 2 as Java WS frameworks, and they all have positives and negatives so we advised the client to use the same framework as their offshore supplier had used in the back-office system to ensure support and maintenance was made easier. We subsequently discovered that, as they had no experience of Web Service integration, the offshore supplier had used HTTPConnection and DOM – i.e. they were hard-coding each web service call.

That afternoon, we integrated all 5 webservices and used Mule’s definition XML to model the control process. In 4 hours work we had acheived the equivalent of over 200 man days of offshore development.

Expertise was obviously the clear winner here!