Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Lol, what I meant was, just like an any QA, most organizations unfortunately want to focus more on dev, and getting the product out of the door, rather than getting it properly tested first. This particular team was built to test the Faster Payments system that was being built at NW, because the spec was a bit cutting edge, and a payment needed to be completed in 15 seconds end to end. Of course, things went down a different route than intended, and I think I should not divulge any more contractor specific stuff
The reason I ask is that I've never seen anyone plan performance testing to take a team longer than three months. If that's what you do, then to be rejected because your contracts last three months seems a little harsh.
Best Forum Advisor 2014 Work in the public sector? You can read my FAQ here
Click here to get 15% off your first year's IPSE membership
The reason I ask is that I've never seen anyone plan performance testing to take a team longer than three months. If that's what you do, then to be rejected because your contracts last three months seems a little harsh.
3 months? I've seen it planned to take a week right before the live date. "What happens if it fails?" I asked. All I got in response was
And I'm pretty sure that week was actually part of the contingency.
The reason I ask is that I've never seen anyone plan performance testing to take a team longer than three months. If that's what you do, then to be rejected because your contracts last three months seems a little harsh.
In this particular instance it was more longer term, since the faster payments "transaction SLA's" were not being met, which prompted the client to hire a team of contractors, and see why the 15 second SLA was not being met. This led to a can of worms being opened, and the team got a lot of leeway, to work with the devs in day to day development, and ensure that the SLA was achieved. This meant adding a "funnel" to queue payments, in case the system went down, or there was delay in processing etc, which required rigorous testing (functional and performance wise). But yes, I have yet to see another client use such a team yet.
I am Brad. I do more than the needful and drive the market rates up by not bobbing my head.
I think this is definitely sensible from their perspective. Even in the case when they are looking for "only 3 months" from a contractor, they still want to know that they can depend on him/her should things change.
I don't. I think it is a pretty poor approach and shows a complete lack of understanding of contracting. If they want to making totally incorrect sweeping assumptions and miss the good guy by not doing a tiny bit of investigation then yes take this approach.
There is a perfectly valid reason why someone may do 3 months here 3 months there, hell, the client may only be looking for 3 months so it's a bit double standards. If he has a track record of three months it may be that this guy is actually seeing them through and is in fact excellent and picking work up and running with it. The guy with the long gigs will want a long induction and a warm up phase.
Ask the contractor why before making sweeping, and in most instances incorrect assumptions IMO.
'CUK forum personality of 2011 - Winner - Yes really!!!!
Completely agree with NLUK. We are contractors at the end of the day we are a flexible workforce, we are brought in to do some work for a certain time whether that be a year, 3 months or 2 days.
Only having short contracts on your CV does not show 'a problem' and agents and clients and even (strangely) some contractors that have this mind-set should really understand why we are here and what we are used for. This kind of mind-set is just how permanent minded people think in my opinion.
That answer really depends how bad the code and offshore mob are thats making the changes. in 2007 I took on a short "design some Solaris systems for me please" gig at a client that was using Cap to write their java app to sit on top of it. Long story short the design work took 3 months including implementation. then I spent a whole year trying miserably contain Cap Gemini while they did their level best to destroy the environment security so that their off shore team did not have to learn how to programme properly...
I think you have espoused the benefits of short contracts before and from a troubleshooting high day rate low utilisation model, I agree. But I think in that situation your CV needs to shine out as a different service offering rather than looking like you get a 3 month gig then move on. Because that is the CV that rings alarm bells like Tranceporter has said.
This kind of mind-set is just how permanent minded people think in my opinion.
You tend to judge on personal experiences, and I know software is different to infrastructure in some ways. My personal mode of operation is one man land and expand. That means I get in the door, do the job they have asked me to do. With that role underway and mostly complete I find a dozen or more other issues that they also need to solve. Then I offer to help them with their pain. As a result I tend to get blocks of one year or two years at the same client but that time is actually split into several different renewals for many different projects. So when I am building a team and I see someone with a related core skill that went to a client and for instance designed an ESX environment then left three months later. I think "Wow. This guy missed a whole stream of how can I help you optimise your environment or plan your migration or rationalise your licensing issues... " That generally means two things either the candidate does not think about joining up the dots of their skills to help the wider client or The client didn't like the contractor enough to offer the extra juicy stuff around the edges... And having seen plenty of guys not get a renewal at 3 months for exactly both of those reasons, I am not likely to bother interviewing someone that is in a trade that should be full of 12 month roles when they keep leaving in the first three months....
I am not likely to bother interviewing someone that is in a trade that should be full of 12 month roles when they keep leaving in the first three months....
I tend to agree, although it does depend upon the skill set. A couple of 3 monthers here and there isn't an issue, but if there were to be few / no longer termers I would be wary. Even on contracts I have hated I have managed to last at least 6 months before moving on.
And as for performance testing, a week at the end should be adequate for a standalone task because PT is something that should be on-going throughout the development process. You can't just do it for 3 months at the end. What happens if performance sucks? You would need to rebuild from scratch. PT should be something that happens by default on all products, from the design onwards.
Comment