Ask Slashdot: Moving From Contract Developers To Hiring One In-House? 524
An anonymous reader writes "I run a small software consulting company who outsources most of its work to contractors. I market myself as being able to handle any technical project, but only really take the fun ones, then shop it around to developers who are interested. I write excellent product specs, provide bug tracking & source control and in general am a programming project manager with empathy for developers. I don't ask them to work weekends and I provide detailed, reproducible bug reports and I pay on time. The only 'rule' (if you can call it that) is: I do not pay for bugs. Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code. Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs. Then all of a sudden I am asking my contractors to work for 'free' and they can make more money elsewhere. Ugh. Every project ends up being a battle, so, I think the solution is to finally hire someone full-time and pay for everything (bugs or not) and just keep them busy. But how can I make that transition? The guy I'd need to hire would have to know a lot of languages and be proficient in all of them. Plus, I can't afford to pay someone $100k/year right now. Ideas?"
Have u thought about.. (Score:5, Insightful)
Re:Have u thought about.. (Score:5, Insightful)
Hiring contractors you can trust and pay them to fix bugs?
you can never trust someone to work for under market pricing - that's the problem he was having, moving risk of customers changing things and being under budgeted for the task to the contracted developer. that's why he spent essentially a paragraph praising himself.
Re:Have u thought about.. (Score:5, Interesting)
you can never trust someone to work for under market pricing - that's the problem he was having, moving risk of customers changing things and being under budgeted for the task to the contracted developer. that's why he spent essentially a paragraph praising himself.
Do you know this man, and do you know this to be true? As far as I'm concerned, I'll take him at his word that he is indeed talking about "bugs" in the sense of programming errors. The whole point of contracting is to shift risk, and if you're paid to write software that fits a spec and you don't, you've not fulfilled your contract. It's the contractor's responsibility to quote what he requires to get the job done to spec, and if his coding style results in an x% bug rate, that should be factored into his estimate.
This man's view of bugs is the right one, and it's a shame the industry (and the courts) don't have the same view. I'm sick of buying buggy software and being told it's "good enough" when it doesn't do what it promises.
Re: Have u thought about.. (Score:5, Insightful)
Re: Have u thought about.. (Score:5, Insightful)
I was a programmer once, and I've recently returned to coding to attempt to produce educational software. My bugs are my responsibility, and when I eventually get to the point where I can sell the software to end users, they will remain my responsibility. My bug rate (currently very high, because I'm out of practice) will ultimately become a factor in my pricing strategy. A contractor is a supplier, not an employee, and should therefore be working to provide something to a contract. When I was at school, my parents hired a contractor to build an extension to the house. The project finished late, and the contract had penalty conditions for late completion, so my parents ended up paying less. This is standard practice in most contractor fields, so why should a coding contractor expect to be any different? Paying for bugs is effectively a bonus for late completion, which is a bit daft.
On the other hand, you do raise an important issue... does the OP actually hire dedicated testers or leave it to the devs? Leaving it to the devs is an invitation to a disaster.
Re: Have u thought about.. (Score:5, Interesting)
My code is not guaranteed indefinitely. Any bugs which appear after the contract is expired can be fixed under another contract if I agree to fix them. I am certainly under no obligation to do that later work at all and especially not for free.
Re: Have u thought about.. (Score:5, Insightful)
As a contractor when I submit code, I leave a certain amount of time for the customer to test that code and supply me a list of bugs. I fix that list. Once my contract time elapses, I expect sign-off and payment. I've fulfilled my end of the contract. I expect my customer to fulfill his end. If he doesn't pay, then I'll send my bill to a collection agency. My code is not guaranteed indefinitely. Any bugs which appear after the contract is expired can be fixed under another contract if I agree to fix them. I am certainly under no obligation to do that later work at all and especially not for free.
Excellant points. Good program management requires testing as you go to eliminate bugs; especially since bugs can result in later programming decisions to develop work arounds, which, then bug is fixed, now become problems themselves. If the If the specs are as good as he claims, testing should be straightforward and either the code meets the specs or it doesn't.
In addition, what is a bug? I've seen situations where code A meets its spec but do to some weird interaction with other code or data anomaly doesn't run properly. To me, that's not a bug but a poor specification; or simply one of those unforeseen events that happen in any project.
Given his statement "Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs." leads me to believe that there is more than just poor programming at play here; a combination of how specifications are written, testing practices, poor documentation of existing systems and data structures, and changing requirements seems to me to be a logical explanation for issues that arise. It sounds like he is paying by the hour and iif so the programmers concerns are valid. If he can't pay what it takes to get a full time hire with the needed skills he is better off biting the bullet, raising his prices,and paying developers to fix bugs instead of getting someone who cannot do the job to his expectations. He could go to a deliverables model - pay for a specific functional code, but that won't really solve his problem - expecting perfect code at a cut rate - and probably cost more. I know if I get requests for a fixed price I triple my estimate to cover any unexpected issues that may arise; and if they don't I pocket the bonus. I also get a very specific contract detailing exactly what they get to protect myself from schedule delays, changing requirements, etc.
Re: (Score:3)
There's bugs where a program doesn't follow the specs (logic bugs) and there's bugs where the program crashes because you didn't check the return value of malloc() (or whatever).
I could argue that both of those are negligence on the part of the programmer, but at the end of the day we're arguing over whether there's such a thing as perfect software or not. Empirical evidence suggests there isn't (at least not at prices that normal people are willing to pay).
The only way to avoid conflict is to pre-agree a p
Re: (Score:3)
Re: Have u thought about.. (Score:5, Insightful)
My code is not guaranteed indefinitely. Any bugs which appear after the contract is expired can be fixed under another contract if I agree to fix them. I am certainly under no obligation to do that later work at all and especially not for free.
Interesting that you're not prepared to guarantee your work. It would make me wary of contracting you as it places the onus on me to ensure that I've throughly tested your code rather than on you. Is this common practice?
All guarantees have limits. With cars, it's a set number of miles or months, whatever is reached first. With most products it's 30 days, or not at all. When you devalue labor by eliminating in house staff to penny ante it to outside contractors, there are going to be consequences. You're not keeping a contractor on retainer, you're going to have to have reasonable limitations on your expectations.
Re: Have u thought about.. (Score:3)
Though for sufficiently serious problems, one can have recalls many years later.
Re: (Score:3)
Though for sufficiently serious problems, one can have recalls many years later.
There are limits to that. You buy a five dollar shirt at C.H. Martins, you can't come back ten years later and demand a refund because it's become a pile of disconnected threads, nor can you expect a recall on your car because it's rusted out. Vehicle recalls occur only because of demonstrated safety issues and because Federal regulations demand such a response.
Re: Have u thought about.. (Score:5, Insightful)
It's common practice in every real field.
if you hire a construction firm to build an office block you go in, or hire someone else to go in and create a list of snags or problems which they can find and the firm you hired to build the block fix them. once you've signed off it doesn't matter if you didn't notice that one floor was missing all it's water pipes. (real example)
you've inspected the job and signed it off. If you want a change or find a problem after that you have to hire them or someone else to do it.
unless of course you specify it in the contract. but that'll likely cost you extra.
Re: Have u thought about.. (Score:5, Interesting)
However, as a precaution, I ALWAYS insist on putting a post-release support agreement in place at the start of the project. This lets the customer know that if problems arise, they will be addressed and fixed if at all possible, and it gets the developer in the mindset of providing continuing support after release. This has worked amazingly well for everyone involved. The customer feels secure and the developer does not have to work for free.
Re: Have u thought about.. (Score:5, Insightful)
I do not pay for bugs.
This guy is a prick.
And you are not far behind.
How many times has Microsoft broken everyone's code with one of their updates?
How many times has someone's code been broken by some other app dicking around with things it shouldn't?
How many times has some idiot administrator broken code by fucking with security?
How many times has someone's code been broken by a DBA changing shit in the database?
How many times has someone's code been broken by the user jacking around with it and deleting stuff they shouldn't be messing with?
How many times has someone's code been broken by viruses, malware, etc?
How many times has someone's code been broken because the user changes the OS?
How many times has code been called broken because the user didn't know exactly what they needed and genius here didn't bother to catch it?
You can write perfect code and there are legions of ways it can be "broke" by others in ways you can't and/or shouldn't anticipate.
Re: Have u thought about.. (Score:4, Informative)
This entire discussion has either misused the term "contracting", or deliberately glossed over it (by which I don't mean to accuse you specifically, the whole thread has that problem).
When I work under salary, I get paid for projects (along with a certain amount of "keeping the lights on" shit-work, of course). I work unpaid OT if necessary, and cut out early when ahead of schedule. I generally expect (and get) a very flexible schedule so long as I get my tasks done.
When I work as a contractor (and yes, I do both), I get paid for my time. I'll give a good estimate of how long it will take me, but if we run over, you keep paying. Simple as that. Yes, that could potentially lead to abuses by unscrupulous programmers - And they wouldn't get any repeat work for pulling crap like that. Just part of the game: Find a few that work well with/for you, and make them happy enough to stick around.
To address the FP post, though, you can't have it both ways. Sure, you sound like great boss in good times, then a bastard at the least pleasant part of the project. All code has bugs, period. Usually the major ones come from ambiguities in the specs; but even assuming a perfect spec, All code (still) has bugs, period.
If you don't budget some percentage of the total project resources to identifying and correcting those bugs, you have failed to properly manage the project. Instead, you have committed the PM version of the classic mathematician's proof-joke, "We start by assuming all cats as perfect black-body spheres in a frictionless environment...".
Re: (Score:3)
This is only true for suitably strict definitions of the term "bug". O/S changes, configuration changes, hardware changes, data changes, requirements changes can all lead to "bugs" that should not be covered under the initial terms of development (and are rarely covered under the initial development contract).
I have yet to see the customer that wants to pay to have the developer specify "exactly" how software
Re: Have u thought about.. (Score:5, Informative)
"A contractor is a supplier, not an employee, and should therefore be working to provide something to a contract."
Yes, a fixed amount of work for a defined period of time, this is why you pay them by the day or hour. If you want more than that then pay more than that. You don't get to pay a contractor for a days work then expect him to do a day and half's work.
If you feel the contractor's work wasn't of sufficient quality then either withhold payment and dispute it legally with them or just don't ever hire them again.
The whole point in using contractors is that you can get rid of them in an instant with no questions asked, no redundancy payment, no justification required. Maybe this is in part a cultural difference because I understand some US states even allow the firing of permanent employees at will, but certainly here in the UK the benefit of contractors is the flexibility they allow you in staffing up or down as required above all else - if you don't like the work they're doing then kick them out the door immediately.
Re: (Score:3)
I think it depends what the arrangement is. If you hire someone to create deliverable X with defined specs for $Y then if they take the contract they need to provide deliverable X to spec no matter how long it takes them; or you don't pay.
Its up to the contracted not to accept a job where the specs are inadequate. If the job is going to be big enough that its worth while maybe you provide some good customer service and help write clear specs; that everyone can understand and agree to.
On the other hand lot
Re: (Score:3)
But we're not talking about a house which is normally something you can quantify as taking x amount of time to a pretty reasonable degree if you've done it before, we're talking about software.
I think just about every software contractor has clued into the fact that software requirements change much more rapidly and if I was on the hiring side of the equation I'd be loathe to take on a contractor that didn't want to be paid by the hour, day, or week, and instead wanted to be paid for the full job, as it wou
Re: (Score:3)
"It's no different for the software industry."
Yes it is, there are two types of project in the world - those where the time for production is a fairly well known and those where it's not. When you've built a few houses you know roughly how many bricks your bricklayers can lay in a day, you know how long it takes to install the plumbing, these are tasks that you do many times and within a certain degree of tolerance are highly predictable in terms of time required.
You can't do that with software, because eve
Re: (Score:3)
Re: (Score:3)
When I was at school, my parents hired a contractor to build an extension to the house....
Stop. Just stop.
Programming is not the same thing as building house. It's a popular, but ludicrous analogy. Even a small program can have billions of different possible execution paths. In fact, if your code has 30 if statements you're already over a billion execution paths (2^30). Why do you think it's so damn hard to make bug proof code? You can have unit tests, integration tests, a dedicated test team and still miss bugs. Even years after the product is finished bugs can still be found by ingenious users
Re: Have u thought about.. (Score:4, Insightful)
As for the question at hand, If you can't pay $100K or more annually I seriously doubt you will find a programmer versed in multiple high profile languages that isn't already self-employed and doing quite well for themselves. You might want to consider a business partnership where you run the business and project side of things.
Re: Have u thought about.. (Score:5, Insightful)
You're not a programmer are you? There's no such thing as bug-free code. Just like no writer can proof read his own novel, no programmer can truely find every bug in his own code.
There is no bug-free anything. Ask someone to put up wallpaper in your living room, and it must be done absolutely perfect. Not one fault. It will take them three times as long. Since you don't pay for that, you will have faults. Ask a gardener to cut back a tree. Bug-free would mean that each single twig is cut to the exact right length. It's not going to happen. Everybody makes mistakes.
:-)
As an employed software developer, it's up to my boss to decide where on the time / quality scale he wants me to be (I prefer more time / higher quality myself). Reducing the amount of bugs increases the amount of time. There is an optimum, which also depends on the cost of bugs, but the decision is up to my boss.
The original poster apparently wants the number of bugs down to a level that would make development cost unreasonably costly, while not actually paying for it. My boss also makes an estimate: How expensive to leave the bug unfixed, how expensive to fix the bug? The original poster doesn't seem to want to make that judgement call, because he doesn't want to pay for the cost. On the other hand, his contractors don't want to pay either
Years ago when I worked for a company that contracted out their services, they just sold X hours of development time at Y per hour. At one point I worked as a contractor; I also charged an hourly rate. I did a good job because that's what I do; I pressed more towards quality because higher quality = more hours = more money which I believe benefited the company as well, but there is no way ever I would sign an f***ing contract where someone else can determine how much work I need to do for a fixed amount of money.
Re: Have u thought about.. (Score:5, Insightful)
I do actually expect all work I pay for to be "bug free" I recently had an aftermarket bed liner put in my truck, and it came back with a bug: it was crooked. I took it back and demanded they make it right for free. And you know what happened? They fixed it for free. Everyone makes mistakes, but when the product makes it to the customer it had better be right. Why are programmers exempt from workmanship standards?
There is a difference from what is a reasonable standard that is generally accepted for a product and perfection. A crooked bed liner is clearly not normal, but if you expected every seam to be within .0000001 of an inch then you would be beyond the bounds or reasonable and customary. Programers aren't exempt, but workmanship standards do not mean 100% bug free code; especially since every situation can not be anticipated and all bugs discovered and fixed.
Re: (Score:3)
I do actually expect all work I pay for to be "bug free" I recently had an aftermarket bed liner put in my truck, and it came back with a bug: it was crooked. I took it back and demanded they make it right for free. And you know what happened? They fixed it for free.
What tolerances did you specify?
"Doesn't look crooked to passers-by" isn't really a specification that can be applied to software.
Re: Have u thought about.. (Score:5, Insightful)
You got modded down, but you're absolutely right. If he could reasonably make money by actually doing the work himself, he would be doing that. Clearly he can make more money by getting someone naïve to do the work for him and then making the profit himself. What's happening here is that the naïve people have stopped being so naïve and he's having to move back to the other business model to correct for it.
Re: Have u thought about.. (Score:4, Funny)
When you understand the Halting Problem, and you understand what that has to do with bugs, THEN you will have a right to critique programming as a profession.
Unfortunately, to understand the Halting Problem, you have to first understand the Halting Problem. So it's rather difficult.
Re: (Score:2)
This man's view of bugs is the right one,
Only if the person he is hiring is PERFECT. I don't know any human being that is perfect.
But as I understand it, he is paying the devs to find their own bugs. But if someone else finds the bug, he won't pay for it.
Re: (Score:3)
If I don't have complete control over the entire codebase, though, you can fucking forget trying to get me to fix bugs without being paid. Sure, I'll fix the odd one of mine that gets in, but I'm not going near problems caused by interactions with other developers' code unless I get paid.
Quite. The OP isn't clear on this -- he seems to be assuming that the spec precludes interactions, but if he's got no way of proving that the failure to integrate isn't a failure of the spec, he might be leaving himself open to litigation if he doesn't pay.
I think the OP should perhaps be looking at insourcing the testing component, and testing to spec. Contractors can be expected to produce to spec, and the company should then be responsible for any problems that aren't caught by their tests against the
Re: (Score:3)
Right, so why does he have a problem? Why is he here asking for solutions?
Honestly he sounds like a cowboy gone contractor. Thinking "hey, I can do this real cheap!", then started cowboying out his "solutions" and found out to his surprise that project management is more than "shopping around" for developers.
The real problem is coming to Slashdot with this rather than seeking advice from someone provably knowledgeable in this field - or go back to school and brush up on software development models, organization and specifically project management.
Wake up (Score:5, Insightful)
Waking up would be a good solution to your problem. You don't pay for bugs? Oh shut the fuck up, if your specs were so masterfully created there would be no bugs. Own up to your part of the miscommunication and deal with it. Put a fault tolerance number into your contracts if your too much of a douche bag to realize that working with humans creates mistakes.
Re: (Score:3, Insightful)
Re:Wake up (Score:5, Insightful)
Well half of the article is boasting how great he is.
The next part is saying he doesn't trust his work force.
Then he gives a vague business idea without much numbers.
And phrased in in a form of advice.
Sorry, he is only going to get ridiculed for being a pompas ass.
Re:Wake up (Score:5, Insightful)
To Pay or Not To Pay, That is the Question (Score:4, Informative)
However, even though I am fixing bugs for "free" they really aren't free. The extra time it takes to fix bugs is simply factored into the initial contract costs. If the contract payment is too low, nothing is forcing you as a freelancer to accept it. You simply take those contracts which have a payment requisite to the amount of time you think it will take to make the software and fix its bugs relative to the complexity of the software you are creating.
I mean you can say "I don't pay for bugs," but really everyone is paying for bugs whether they think they are or not.
Re:Wake up (Score:4, Insightful)
if your specs were so masterfully created there would be no bugs.
does not compute.
Re: (Score:2, Offtopic)
Oh shut the fuck up, if your specs were so masterfully created there would be no bugs.
If your post wer so well ritten their wood bee know mis-takes in my response.
Re:Wake up (Score:5, Insightful)
If your customers are complaining about bugs, and those conditions are covered by your spec, then you are at fault for not catching it before giving it to the customer. You must verify that the delivered code matches your spec.
Either write automated tests based on your spec yourself, or get a developer to write them and review them yourself. Otherwise you will have to test everything manually, every time they deliver you new code.
But even then, your customer may encounter issues that you didn't test for.
Re:Wake up (Score:4, Informative)
Bugs happen even with the best developers.
Not factoring in the cost of fixing bugs into your project is your mistake not theirs.
Often these bugs are not true bugs but misinterpretation of the specs, and needs to be reworked.
Do you rehire good contractors or at least give them as recon adaptions? If so the idea that these contractors will write bugs intentionally just to make money, is rather silly, as they are risking their future jobs.
If you are so masterful yourself and you are also the boss, you should see what the bugs are, and if they make sense, to have happen or if they are just blatantly put in.
Re:Wake up (Score:4, Interesting)
>Waking up would be a good solution to your problem. You don't pay for bugs? Oh shut the fuck up, if your specs were so masterfully created there would be no bugs.
It's very likely that his developers are, in fact, not perfect, but don't have an incentive to bug fix after they got paid.
Solution: Don't give them the final payment until the customer signs off on it.
Re:Wake up (Score:4, Informative)
Yeah, and more importantly he needs to agree with his contractors on what a "deliverable" is, and when one is "done". He might be the victim of poor developers, but since his entire business model is "shopping around" for developers, that's all on him.
Re:Wake up (Score:5, Interesting)
Well, a little rude, but not totally wrong.
1. I've been told I write "excellent" specs before; notably on one project where the devs then went 3x over budget, (estimated AFTER they had read the specs). Even before this experience, I never believed such a thing as an "excellent" spec existed. A little humility, guy...I'm sure you're good, but is everything you do "excellent", everywhere and every day? Anyway, spec has very little to do with the ability of the team to translate into code. I've known plenty of people capable of turning a bad spec into good product, and vice versa.
2. As the OP said, add a realistic budget into your contracts for testing & bug-fixes. That will help you build loyalty into your core team of contract devs. You're better off sticking with a regular team who you can trust, especially as you're asking for a very wide competency base.
3. Don't hire fixed costs; they'll kill you, and it sounds like your hiring criteria are totally unrealistic anyway. Also, your logic is flawed; why would you be prepared to pay a salaried employee to fix (his/her) bugs, but not a contractor?
Re:Wake up (Score:5, Insightful)
Well, a little rude, but not totally wrong.
Yeah, although that was not by accident at all. Somehow people like the AC who asked the question pushes my buttons. The whole story reeks of a lack of understanding of how software development works, yet it is somehow the fault of somebody else. God forbid he looks at his own process with an eye towards making improvements.
Some /.-ers see through the smoke and recognize that "empathy for developers" is a marketing stunt because he knows /. - and knows that half the audience is going to eat that right up.
When asking questions at least be honest and, as with all homework, show the work you have so far. Setting himself up to be some kind of hero defeats the purpose. If he's such a God among mortals, why is he having these basic problems at all?
Fall back asleep. (Score:2)
There is no possible way that masterful specs can eliminate all bugs. In fact, I'm gu
Re:Wake up (Score:4, Insightful)
As a general rule there's two kinds of contracts, fixed bid and time&material. The former usually means a predefined scope at a fixed price, formal change orders and bug fixes are usually free within a given testing period. The other is basically "do whatever I say" and yes I will, but I don't own the specification and I'm not making any sign-offs on what I'll deliver - I just work hours for you. You get various forms of hybrids - I consider agile one of them - but that's the archetypes. I've coded off "specifications" that were a yellow post-it note, rushed it to production with hardly any testing or documentation and if it works for them it works for me. If you're overall not happy with my work stop the contract, but I charge you every hour even when I'm bug fixing my own work.
It sounds to me like you're asking for the best of both worlds, contractors that'll work regular hours during most of the project and do bug fixes for free at the end. That is going to be trouble, every time. Hell, when you say "programming project manager" I'm starting to think they're not even in full control of the code, far less the spec. Contractors tend to love repeat business, have you them coming back for more? No? Probably because they feel railroaded by the process. Do your contractors ever reject your specs? Can they reject your specs? Or are you just telling them these are the specs and I'm saying they're good enough, get to work? What about when things undoubtedly come up, is there a formal change process or you just improving or amending the spec?
Good enough to work by and good enough to sign off on are two entirely different things, try doing a proper fixed bid project and I think you'll find out.
Re:Wake up (Score:5, Insightful)
Expecting someone to pay for bugs is like buying a new car with a broken gearbox then having to pay for a new gearbox ontop of the initial purchase.
No. A car is a mass produced vehicle. That gives you one standard for what to expect.
Contracting a software project is a one off, bespoke item. Built to your stated requirements (which are unlikely to be perfect in themselves.) It's not rational to have the same expectations as a mass produced item.
A better analogy would be builders building a house based on your drawings. And I hope you ARE a qualified architect.
Now I'm not saying that you wouldn't expect builders to come back and fix flaws. Of course you would. But it wouldn't necessarily come in with the original price. There would be a discussion about who's fault it was that the flaw happened.
But my main point is it's foolish to expect the same flawlessness from a bespoke item built to your specification, and a mass produced item.
Come to that, you could have a car analogy, but it would have to be a custom car, again built to your drawings. And if you expect that not to have flaws...
Cars dont have bugs WTF ?? (Score:3)
right and rockets dont blow up because the spec has been followed and tested several times the tolerances tested etc\
never heard of a car being recalled ? - BTW they try not to do this but...
WTF - seriously everyone involved in this thread seems to have very little to say... study some history or repeat yourself...
cheers
John
Re:Wake up (Score:4, Insightful)
Correct. You agree up front what kind of repairs the retailer is responsible for. You don't come running when it turns out that the windmill you thought you ordered turns out to be a batch of tulips. You word the contract appropriately, and you have a process to verify that what has been delivered is the actual wanted product. Saying "I don't pay for bugs" is more telling than anything that this guy has NO process, and no clue.
Re:Wake up (Score:5, Insightful)
Most of the time the customer asks for xyz and doesn't tell the developer about w, and complains that it's not there. Or the customer forgets to tell the developer that their data integrity isn't checked, and that data outside the spec sometimes slips in. Sometimes the customer forgets to mention that other systems are used with the data and will sometimes make changes to the data that weren't documented in the spec. Putting all the blame on the developer is nice from a pure management perspective, but it breaks too often in the real world.
Re:Wake up (Score:5, Insightful)
Of course you fix your bugs - this guy however signs off on code and then expects to be able to un-sign off on it at a later date. That is not how sane software development works. You boil down tests in every phase to a yes/no response, and that is your basis of signing off. If he signed off on shit, then it later proves to be shit, then that is all on him for not doing proper unit/integration/acceptance/whatever testing. So yeah, again, fuck him - his type is what is wrong with software development - he acts the middleman and peddles absolute shit to paying customers and expects to pass the turd on to someone else.
Re: (Score:2)
No - he is dealing with his own lack of a process model. I wouldn't take work from him or you either, what I would do is go straight to your customer and offer a better product at a cheaper price, because I know process models and I just cut out the greedy middleman.
Re: (Score:3)
I certainly care about the product I deliver. I don't care much for middlemen though, and I certainly don't care for middlemen who thinks their job is done when they deliver the specification. Where was the acceptance testing? Why was this code signed off on? Why does he even have this problem to begin with? He sets himself up to sound like a fucking legend, yet it smells to high heaven of greed and incompetence.
Sounds like a partnership (Score:2, Interesting)
You can always offer stock options, a share of the company/profit etc. If you're as good a manager as you say, getting someone on board shouldn't be that difficult.
Hiring? (Score:2, Insightful)
How about hiring a decent tester and catching the "bug" a lot earlier?
Completion Bonus (Score:5, Interesting)
This gives the programmers an incentive to finish the bug testing and getting to a stable release status so they receive their bonus.
Many contractors have a bonus waiting at the end of a project and know that any mistakes will come out of that bonus. If a new contractor is needed to fix something the original contractor is unwilling to do, then the bonus should be just large enough to pay for the new contractors work.
Good luck with that! (Score:5, Insightful)
But how can I make that transition? The guy I'd need to hire would have to know a lot of languages and be proficient in all of them. Plus, I can't afford to pay someone $100k/year right now. Ideas?"
So let's see: you want (a) A person who knows a lot of languages, (b) Proficient in all of them - i.e. many years of experience, hopefully very skilled (i.e. not resume padding), and (c) Relatively inexpensive.
Good luck with that. You can't have all three. Hell, getting one really good developer who is inexpensive is hard. Fresh out of college, sure. Someone who has a lot of real world experience in a lot of languages? Nope.
Also, since you are talking about difficulties with transition, you want your outside developers to either do a knowledge transfer, or the new guy to spend time reading the old stuff independently - i.e. it will take him/her weeks (if not months) while learning, making it a loss of money early on. If you want to make a clean break (and not support your old work), then you can skip this step (assuming you found someone).
And finally, you do NOT pay for bugs? Then recover your costs (SLAs) or do your testing and refuse to pay till the code is clean. Saying developers are fine with it till bugs are brought to light means that the developers are not fine with it! And assuming your specifications are great ("there is no excuse for not testing their code") then either the devs are keeping testing to the end, or the timeline is too stringent, not giving enough time for testing. So your project management skills aren't great (you are being optimistic in what you tell your clients as a schedule), or you are picking lazy developers.
Ever project ends up being a battle...
So you don't learn from your mistakes either? Why do assume moving things in house will solve all your problems? The common factor for a lot of your projects seems to be you...
best practice employment practices (Score:2)
in general am a programming project manager with empathy for developers. I don't ask them to work weekends and I provide detailed, reproducible bug reports and I pay on time
hardly true. If you want 100% bug free code then expect the devs to take twice as long to provide the solution (and that's being optimistic). If you don't want the tested-to-death solution, and want to take a pragmatic approach where you assume some bugs will fall through the dev process, then you'll get the solution quicker overall. (obviously there are some devs to whom a bug is a way of life, I assume you will not hire them again)
BTW good for you, not wanting devs to work weekends. Do they get national h
If you are going to wishing for things (Score:2)
If you are going to be wishing for things like the perfect employee (knows lots of languages, is proficient in all of them, is cheap) then you might as well just wish for peace on earth, good will to mankind .. and a pony.
And while you are doing that, take a look a what people with experience in only a few areas are being paid, and then factor in some overheads. Or in other words, is that $100k as salary to them and you will have a bunch of overheads to carry, or is the $100k including overheads? Because
There's no such thing as non trivia bug free code (Score:3)
There's no such thing as non trivial bug free code. only code which has not been tested in enough circumstances.
No. really. Even limiting it to just security related bugs with an author who put an insane amount of work into making it bug free who knew exactly what he wanted with no communication with a client bugs still turn up when code is exposed to the real world.
http://en.wikipedia.org/wiki/Qmail [wikipedia.org]
Totally bug free code is insanely expensive to write in even small amounts so you're basically having the developers spin the wheel, if your clients do massive amounts of testing they end up working for months unpaid. if they do little testing and can live with lots of little bugs then the Dev gets a good deal.
Here's a sane solution to your problem: pay for bug fixing.
Project management includes handling QA. (Score:3)
"with the specifications I write there is no excuse for not testing their code" - so why don't you test their code, then? (If you can't do this yourself, hire QA.) Regard the contract as complete when all your tests pass (note: *your* tests!).
If bugs are found after the project is complete, it is because the test coverage was incomplete, or QA failed, and you should be happy to take responsibility for having them resolved (including payment if necessary.)
Re: (Score:2)
Sounds reasonable to me (Score:2)
Acceptance tests for the contractor (Score:2)
In your contract, you should have acceptance tests specified. The contractor that hires you should test and approve the product. If it's not what they want, contains bugs, or is not as specified by them, they should not accept. When they have accepted the product, they should pay for bugs. You should agree about this before starting.
For now, fix those bugs, and think of it as a good and valuable lesson.
Not in touch with reality (Score:5, Insightful)
Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code.
This hugely contradicts my experience. Although it may be possible to write specs that are so good, so coherent and incorporate so many edge case that any code realizing it *must* be bug-free, I have never seen it happen for any modestly complicated software project.
Software development is a continuous process (like gardening). If you are worried about bugs, then you must be pro-active about it. Tools like Sonar can give you valuable information about which parts of the code base are under-tested, overly complicated and require careful attention. Also, testing is a multi-level discipline - you can't get away with *only* unit testing, or *only* integration testing. If you want your code to be bug free, you need to invest a lot of time and effort in automating your different test strategies.
There is no guaranteed, affordable process for having bug-free code. You *will* end up with bugs, without requiring this to be attributable to someone's incompetence. You need to actively manage this.
Re: (Score:2)
No matter how thoroughly tested software is, there will be places where it breaks in production, through no fault of the developers and testers. If you don't believe this, you haven't worked on enough systems, or they haven't been complicated enough.
Hire the contractor you work best with (Score:2)
My suggestion is you look at your current list of contractors, order them by how well they cooperate with you, and make the "best" an offer. You won't find anybody perfect, better the developer you know than the genius you don't!
Forget it (Score:4, Insightful)
You're looking for someone who is incredibly good (able to offer a wide variety of programming languages, good enough to not create any bugs, anticipate them and/or find them very quickly), that is essentially someone who could pick and choose his job, but pay him like some intern.
Would you do it?
Sigh... repeat after me (Score:5, Insightful)
Code is never 100% bug free, no matter how smart the programmer, how well tested the code and how many million hours it's been running without any problem.
The only type of developer willing to agree to a "fix-bugs-for-free" contract is one who is either (A) stupid of (B) lying.
100k/year is on the low side for what you want (Score:2)
If you want an excellent engineer, you need to pay at least reasonable.
Can't afford a good developers' salary? (Score:3)
Then it sounds like you will need to give some equity in your business away.
Or, consider this - why are you allowing the same guys writing the software to be responsible for testing it? If you genuinely write good specs you should be able to find someone who will write automated testing (and/or engage in manual testing) to meet your spec and apply it against the software provided by the contractor. This should eliminate a very large number of potential bugs. If your specs are good enough you could even offshore this fairly easily - it's very simple work.
Check your ego at the door (Score:3)
Anyone who says they write perfect specs or perfect code, or perfect anything is full of shit. Even if YOU write perfect specs, they're based on customer requirements and those are always incomplete. Customers do not have requirements, they have problems, and it's our job to devise solutions to those problems. Even if code is written bug-free the customer will not know exactly how it should work until you give them something to critique. Then they ask for changes - this is called a requirement change or clarification, not a bug, and not the developers fault. I'm sure your developers create bugs too, but I'm certain they're not the only cause.
BTW, my subject line applies to developers too.
You want the best of both worlds? (Score:3)
Why do the bugs only surface toward the end? (Score:4, Informative)
My first thought as I was reading the summary is "why are the bugs only being highlighted at the end of the project?".
Granted, that is when the users have something approaching a "complete" product to work with so that is where they will do most of their testing... wait, have I just answered my own question?? It seems I have, yes.
Welcome to the wonderful world of the project manager and analyst - if the client is coming with bug reports, there are 3 potential areas where someone screwed up - either the client explained it badly (in which case, it is not a bug as such, it is a functional change - paid work), or you did not do as good a job as you should have of writing the spec (in which case, in my opinion, you should eat the cost and learn from the mistake), or the developer botched the implementation of your spec (in an ideal world, the developer *should* fix that, as they caused the problem).
If the client or you screw up, just about the only way to catch that is during a user acceptance test. Determining whether the screw-up is yours or the client's comes down to a review of your spec and needs some honest appraisal by you - if the spec is unambiguous and the product does what the spec says, and the client has signed off on the spec, then it is their fault. If the spec is ambiguous and open to interpretation (typically this is going to be when the spec matches what the user wants, and what the product does, but the product and the user's expectations do not match), then you have the fault. Yes, it is incredibly hard to write clear, unambiguous specs and then get a client to read through them and understand them... but in that case the spec is a bit like a EULA - the user does not have to read and understand them, they just have to sign on the dotted line to say "the spec matches what I want".
If the dev screws up, getting them to hold their hand up and admit to the fault and fix it is hard, as you have found - why work for free when you can work for money - but if you structure the contract correctly, with a completion bonus that they get when the client takes delivery, then you have some kind of hold over them. For example, a basic wage of $60k/year pro rata with $40k/year pro rata paid after sign-off. Some/most contractors will be put off by that, and they are typically the ones who will cut and run at the first mention of "bug" and "free". But the ones who are willing to take that on will probably be more conscientious in terms of self-testing, unit testing, analysis and possibly querying the spec, because if they can get it right first time, they get the bonus without doing any extra work...
As for the other side - getting the users to test and validate earlier in the process, for that you need to deliver functional prototypes early in the process and implement some manner of testing window - most of the companies I have worked for as a PM/analyst have contract clauses that give clients a 30-60 day window from delivery of a new version of an application to report bugs as bugs - after that, any errors are categorized as billable change requests, so the client has both incentive and responsibility to perform testing of their own.
It does mean that you get to have some tough conversations with a client because they are reporting a "bug" after 5 minutes of use, 6 months after you delivered the application, and if you want to be flexible and client-focussed, you can look at whether that bug should have been caught by in-house testing to confirm compliance with your spec.
Lastly, when you find a couple of good contractors who are able to write good code and who take enough pride in teh quality of their work that they are willing to work on fixing bugs in their code (they do exist, honestly, they are about twice as common as unicorns, and are sighted more often than flying pigs), either offer them a permanent position, marry them off to your sister so that you can keep track of them, or tell them that they do such good work you will want to call them back next time you get a juicy and interesting project.
ok, maybe I am a bit too naive for this job, but I have been working as an analyst/PM/IT implementation consultant in the banking and finance industry for the last 10 years.
Your employee should be a unit tester (Score:3)
Instead of an end product coder, hire a unit tester. Hand him the specs that you send out, and have him code unit tests for all input categories of the different modules, and check results and fail modes. Hell, have him send out these tests as he finishes, so that the contractors can use them, too.
If the unit tests are correct and the software is failing, don't send out paychecks until it passes. Getting the test suite running may take a week or two once the code is delivered, so you might be a little later than you usually are. But you contracted for working code, and the easiest way to verify it's correct is to pass a test suite. Once it passes that, you'll know that it passed YOUR specs. At this point, if there are bugs despite meeting the specs, it's your fault.
Re: (Score:3)
*How* do you pay? (Score:3)
What is your agreement with the contractors? From your statement that you "pay on time" I have the feeling that this is where your problem is.
If you have agreed: "I will pay you $x per hour of work", then you are paying for their time. If bugs need fixed, you need to pay for some more of their time.
On the other hand, if you say "I will pay you $x if you write a program that meets this specification", then you simply do not pay until you have such a program. If it's a big project, it may make sense to define some intermediate milestones, where the programmer receives partial payment. However, a large portion of the payment (at least 1/3) should be released only after the program has passed acceptance tests.
A contractor ought to charge you slightly more for the second option, because the contractor is carrying the risk.
Being a Publisher on the Cheap (Score:3)
The OP essentially wants to be able to act like a software development company on the cheap. A software development company has it's own full time staff to develop code and budgets time for things such as beta testing and fixing the INEVITABLE bugs that come up, especially for major pieces of software. This of course is not cheap, you're paying salaries and benefits to maintain such resources.
If you're going to try to do this on the cheap by outsourcing it, then you're going to have to admit that you're not a developing house, you're just a shell game trying to hide the fact that you're not the publishing house you're making yourself out to be to your customers.
UAT ? (Score:3, Insightful)
Thoughts from an Analyst (Score:5, Insightful)
I am an analyst and I often write requirements, test code and write user documentation. I've been in the industry for 20+ years. I have never met a single developer who doesn't have bugs in code. I've read some of the posts in this thread and many of you are comparing building contractors to software developer contractors and I honestly think you're comparing apples to oranges.
I don't know what the small business owner is making but I believe, to some degree his demands are unreasonable. When a contractor comes into your house to install an item, there are a limited number of ways in which that contractor can perform the tasks to complete the job. If that contractor must deviate from standard specs they run the possibility of having issues with the installed item. And under their contract, under normal conditions, they have limited liability to correct the issues after installation. If the house has a non-standard configuration, and the contractor must fit a square peg into a round hole, this is usually discussed before the work is performed and agreements are made. However, it happens all the time where a contractor faces a hidden issue in their goal to complete the task correctly without issue.
From that description comparing a building contractor to a software developer contractor is feasible. But code is different. With code there are several ways to skin a cat and depending on how rigid the specifications are can influence the amount of bugs that can be created. As good as I would like to think I am in writing requirements there are always hidden requirements that can't be considered until a software developer gets into the process of writing the code. The small business owner claims to have written the specifications, and I don't believe he has developer experience, and to write a chunk of code to capture data in one place may open several doors within the product on how to handle that captured data. Unless the specifications are that meticulous there will be bugs. My question would be, have you hired a tester? Just because requirement 1 says "capture data", and requirement 2 says "store data", where is the requirement on the length and type of data to store? Boom, bug. If specifications don't get down to that level of detail everywhere, there will be bugs. And if your specifications are that meticulous, then how much time is over used up front.
On top of that, you're requesting that a developer be able to write in multiple coding languages. How much would you pay an interpreter to speak five spoken languages? A lot of money, software developers who can write in multiple coding languages and are proficient in all of them don't come cheap. Specifications to interpret one to one from one language to the next.
I'd say the following:
1. raise your prices you're charging your customer
2. insist on a very small subset of development languages
3. hire a full time employee and find someone who cares about success in your company
4. perks, perks, perks
5. hire interns for testing
6. Most important, demand excellence, but be realistic.
Re: (Score:3)
I am an analyst and I often write requirements, test code and write user documentation. I've been in the industry for 20+ years. I have never met a single developer who doesn't have bugs in code. I've read some of the posts in this thread and many of you are comparing building contractors to software developer contractors and I honestly think you're comparing apples to oranges.
A friend of mine built a house. One contractor drove a nail through a water pipe. Well, mistakes happen. He then wrapped a plastic bag over the hole and plastered over it. Everything actually looked fine for a month (must have used an excellent plastic bag) until a dark spot developed and became bigger and bigger.
I must laugh when people say there are fewer bugs in different professions.
What's missing from the question (Score:5, Informative)
If you define a "bug" as an operation that clearly and objectively fails to meet the expectations set out explicitly in your requirements and specs, then you are in the clear. Basically the situation where your specs state: "When presented with A and B the software will do C", and the software does D. Not conforming to the explicit spec is a clear defect that the developer should have caught.
If the "bug" is actually "something the client didn't like in your implementation", then tough. The software performs to spec. It doesn't matter how obvious it seems to you or your client now that you see the software that this isn't desired behavior - the desired behavior was not described in the spec and not included in the quote you got. You made an error of omission in your spec - it's your error to fix, not the developer's.
If you think through on this path you will start to realize that writing a totally air-tight spec is outside of your ability. Stop trying. You aren't that good. No, you really aren't. There are going to be areas where you, the client, and the developer have very different opinions on the severity or "correctness" of certain behaviors not specified in your spec.
Finally, realize that you are actually taking a passively antagonistic stance to your developers. A priori you are assuming that they will deliberately add bugs to inflate their income. This is bullshit. Contract developers are smart people. They know "recurring business". These guys may be *smarter than you*. The good ones are not out to get you, they want you to be happy with their services so you come back the next time. So drop the antagonism and work with them on the actual issues. Meeting each other at a reasonable half way point works wonders in any relationship, including professional ones.
You can't afford to be in business (Score:3)
If you can't afford to pay someone what it costs to do the job right, then you can't afford to be in the business you're in. You can do it for a while, until you build up a reputation for overpromising and underdelivering. You should focus on work you can afford to do.
Let's pick apart your requirements (Score:3)
"I write excellent product specs" -- are these product specifications sufficiently detailed to have a consulting Software Quality Assurance person be able to test each feature of the product? Sufficiently detailed so the multiple people you hire can seamlessly do integration testing? What scaffolding do you provide for each of the developers? Do you have the same "source control" of your specifications as you do for the code generated from them? How do you handle "feature creep"?
"Bug tracking and source control" -- Do you have staff or contractors who confirm the bugs? And how do you handle regression testing during development and subsequent maintenance? How about code reviews? Who handles customer service queries?
"Empathy for developers" -- demanding bug-free code without the tools and processes to give the contract developers a fighting chance? How well do you anticipate corner cases in your products, so you can include them in your specification? What practices do you insist on to catch bugs early in the product development cycle?
"...hire someone full-time...know a lot of languages and be proficient in all of them...can't afford to pay someone $100k/year" -- Sounds like a version of the Universal Specification: "I want everything, now for, $1.98." As for pay, that one is easy: make him a partner, and he earns from the bottom line just like you do. You will probably have to take a bit of a pay cut to attract what is essentially a do-everything maintenance programmer, not exactly the career track that anyone with the type of experience you are looking for would choose. Have you looked at the pool of experienced programmers? There are quite a few who have been put out to pasture because they don't have the "zing" in their resume that most [In]Homan Resource people look for. Learning languages is a skill easily picked up. Learning how to un-muddle code written my others is an art, and people skilled in the art of decoding a mess are much harder to find, let alone identify.
Transition? One possibility is to find a contractor highly skilled in maintenance programms. If he works out, offer him a partnership.
As for the attitude that any piece of software can be completely bug-free: that's a holy grail. The ADA Programming Language was invented to try to provide an underpinning to achieving the holy grail -- when was the last time you heard about it seriously? Several research-based languages have been developed that purport to "prove" that they are correct...but watch what happens when an unanticipated corner case hits the code. Many of the advances in languages and compilers focus on finding easy and trivial problems quickly, so a programmer doesn't have to spend time finding and fixing them. (Scripting languages, particularly those that compile "on the fly" such as TCL and most shell scripts, point out the advantage of a proper compilable language; you lose some flexibility, but the overall programmer cost is far lower than tripping over mistakes one at a time, particularly if the programs run are measured in minutes and hours.)
Your business model will need to change. Count on it.
Subby isn't as good as he/she thinks. (Score:4, Insightful)
Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code. Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs.
There is no excuse for developers not testing their code, because you shouldn't expect that to be the final testing. That's your job. I think the analogy someone else posted above is apt, programmers need testers just as writers need editors.
What the developers send you should be reasonably complete, as in not a first draft. But it shouldn't be assumed to be a finished product ready to pass to the customer.
So why are customers complaining about bugs? If you write "excellent product specs," "provide bug tracking & source control," and "provide detailed, reproducible bug reports," why are you passing along buggy code to your customers? Why aren't you doing your job as a project manager?
It sounds like you're not sticking to your product specs, not using the bug tracking & source control, not reading those bug reports.
That you've been moved to ask /. leads me to think this is a recurring problem. Remember Subby, the common aspect of all your failed relationships is you.
I hear you (Score:4, Interesting)
I'm in the exact other boat, so I can see the same problem from the other side. I run a web development business, I don't write specs, I do everything in my languages of choice, I also market being able to handle any technical project for my clients. In my case, however, I specifically don't charge them for bugs. Everything's either project-based pricing or feature-based pricing. Bug fixing, cosmetic alterations, and cursory data field/presentation changing is free. I do all of that in order to justify not writing specs in the first place -- because I'm not you.
I tried paying contractors to work for me. I tried paying employees to work for me. And even paying them proper salaries I got the same results as you're getting from contractors. As employees, instead of running away, the work effort got sloppier and sloppier as bugs and client changes were hacks ontop of hacks. Their speed dropped to nill, and it basically sucked me dry to the point where I could easily lose all of my personal take-out when bug repairs ran longer and longer. And you can't tell a client, especially before they've signed off on a project, that a huge expense is to fix bugs that don't exist yet in something that should be written properly the first time, especially in their minds.
So my advice to you is going to be different. My advice to you is to find contractor developers like myself who do fix bugs for free. But I'm going to tell you that the only way to make that fair to them is to let those developers choose the tools -- i.e. the languages they use. I've spent two decades building up my own tools, to the point where now I can easily handle bugs and after-the-fact client changes so it doesn't cost me anything to fix bugs -- and if you're telling me that you'll produce the test case, then you've saved me 80% of the work. And if I know that you're the one doing it, then I can upgrade my platform to show me exactly what you tested, which will ultimately point me to the very code itself, and that's a total of 90% of the work 90% of the time.
Find the right contractor who knows how to appreciate your policy. I can guarantee he exists, because I'm one of them. There must be others.
Feel for you. (Score:3)
I have the same problem.
However half the time it isn't the contractors fault entirely, sometimes the local IT when setting up the contractors work screw up a script, or implement the DB incorrectly, or any number of things, causing the application to fail pretty fundamentally.
As someone that has been on the business area testing side of things, it can be vastly frustrating when finding flaws that are so big and so obvious that there is no way the developer even bothered to test (sometimes I wonder how they could even code it without even trying to run it at least once). Or when you point or said flaw, they report that it has been fixed, you go back and test it again, and nothing has changed. Turns out they forgot and just said they did something about it when nothing was actually done.
Much of this can be solved with contracts and good testing practices. DO NOT having testing as an after thought. Engage the users to exhaustively test. Have them sign off, but do not have the time truncated because the developer was slow or ran into problem. Have set scripted time for testing and build into contract. That way it is spelled out when the developer fails (and so does payment) or when the user client fails to spot bug and they have to take some responsibility also.
Any many have mentioned, bug free code pretty much doesn't exist for any systems of any size or complexity, or they don't stay that way for very long if they do exist. However you can try to keep it to a reasonable amount of non-core functionality. There can be those bugs that only happen when all the planets align on a prime number Tuesday. Even the most diligent development or user testing can miss it, and only find out much later. Thankfully usually these things are pretty low impact due to the rarity.
In any case hiring internally is fine, and will allow for more continuous updates to these applications. Find a rare bug a year afterwards, no problem, you have an in house guy that can fix it no problem. The only difficulty is that you better make sure who ever you hire does meticulous documenting, in code comments, and is very organized. An organization can become very dependent on these folks for obvious reasons. When they leave (for whatever reason), you could be quite screwed, and even going back to contractors may be difficult. Languages really don't matter, keep up their training if they have to deal with a lot. Hire someone that has a lot of experience in the primary languages you deal with (or the most immediate need), and let them develop the rest. In your situation, I wouldn't be looking for the "genius level hacker" type but rather the "OCD organized, meticulous, steady" type. Heh, neither are likely fun to be around... :) Someone who is a competent programmer to be sure, and shows some flexibility and range of ability/knowledge/experience but primary skill should be fastidiousness.
Re: (Score:2)
Agree, you need to have some acceptance criteria and process where you pay for functionality that you have deemed acceptable. The product specs and so one would form part of that criteria along with any testing cases to support it.
Once past that stage any further bugs that come to light after acceptance is a paid for change request as you've accepted the unit of work and have to have taken responsibility for it being deemed correct.
Software development is like creating a prototype for something new every ti
Re: (Score:2)
Well, you should be paying them to fix bugs really... it's analogous to not paying a sports team if they lose.
No it's not. A contractor is not an employee, but a supplier. If Amazon sends me the wrong book, it's their mistake. They cover the costs of my return postage and them sending out the correct one. I do not pay directly for their mistake. Instead Amazon track the cost of their mistakes and factor it into their pricing. A contractor should be able to do the same: "OK, I generally make X bugs per 10000 LOC, so I'll need to have a contingency of Y days for this project..."
Re: (Score:2)
Great, if the customer is prepared to pay for n sprints, without knowing n before the end of the project.
Re: (Score:2)
damn that all sounds awfully complicated... cowboy coding rulz...
you tell me what you want mr customer and i'll code while you're talking. if i run into something that is too hard to code while you're talking (or i can't be fucked right now) i'll just scrawl some notes in a todo. you'll have your first feature in about an hour. it will be very basic and won't do much and will likely be full of bugs, but together we'll get something running quicker than you can say "that drawing of a cannon looks like a huge
Pay for the tests (Score:5, Informative)
with the specifications I write there is no excuse for not testing their code.
In every engineering project I've ever worked on, the specifications included acceptance tests. Obviously, his specifications aren't good enough.
He should detail with his customers the functional specifications of the product and generate a set of acceptance tests. The end product of this would be a test procedure, which both the customer and the contractors have previously agreed upon.
There is no excuse for a contractor to blame the programmers who did not conduct testing, if the way the testing should be done has not been previously detailed. The formal test procedure is what separated bugs from features.
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:3)
The specs are never as good as the spec writers think they are.
I've been a developer (contractor and employee) for nearly 20 years and have never seen specs that clearly defined everything. In any project of notable size, there are always huge portions of "it's obvious what I want," often with the UI. Spec writers are generally terrible at thinking about "edge case" behavior, focussing on the "normal flow" and trivializing the "alternate flows."
Why do you think the OP always has battles at the end of the pr
Re:Stop being cheap. (Score:4, Interesting)
The specs are never as good as the spec writers think they are.
I've been a developer (contractor and employee) for nearly 20 years and have never seen specs that clearly defined everything. In any project of notable size, there are always huge portions of "it's obvious what I want," often with the UI. Spec writers are generally terrible at thinking about "edge case" behavior, focussing on the "normal flow" and trivializing the "alternate flows."
Why do you think the OP always has battles at the end of the project?.
Given the spec is incomplete, and your experience, wouldn't best practice be to analyse the requirements at the start and identify those edge cases and get decisions on them before starting.
Whilst building out large systems I have written functional specification and detailed designs for clients that, in the end, stated absolutely what would be done and how each interface would look and perform. This made implementation simpler, because all of the decisions where made up front, and gave something to test against when completed.
Way back in the early '80s when I got my degree the thing that was placed into our heads was to spend 90% of the time designing, 5% coding, and 5% testing. These days we seem to dive into coding way too early.
Re: (Score:2)
Depend on location.
In Boston or NYC, that pay is low. In Albany that is a really good salary for skilled workers.
Re: (Score:3)
Not to mention that for any project maintenance is the largest percentage of the project's lifetime. It kind of sounds like this guy doesn't really understand what constitutes a "bug," at least doesn't understand that not all bugs are caused by developers making mistakes. There are bugs caused by invalid data entering the system by user error, or by parts of the system outside the control of the developers, or by bugs in the compiler or libraries used in the system that only show up during run-time, or by
Re: (Score:2)