Ask Slashdot: Moving From Contract Developers To Hiring One In-House?

Have u thought about.. by woja · 2013-05-21 21:22 · Score: 5, Insightful

Hiring contractors you can trust and pay them to fix bugs?

Re:Have u thought about.. by Anonymous Coward · 2013-05-21 21:32 · 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.. by Half-pint+HAL · 2013-05-21 21:38 · 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.

--
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Re: Have u thought about.. by erapert · 2013-05-21 21:47 · 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.
Re: Have u thought about.. by Half-pint+HAL · 2013-05-21 22:00 · Score: 4, 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.

--
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Re: Have u thought about.. by gnasher719 · 2013-05-21 22:25 · 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.. by XopherMV · 2013-05-21 22:46 · Score: 4, Interesting

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.
Re: Have u thought about.. by gmclapp · 2013-05-21 22:59 · Score: 2, 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?

--
Common Sense (+1)
Re: Have u thought about.. by home-electro.com · 2013-05-21 23:10 · Score: 2

You are correct, with one exception - if I hire a contractor on a per-project-fee basis, then I'd fully expect to have bugs I find to be fixed for free. Not forever, but give me a couple of weeks for testing. The problem with this approach is that not a lot of people are experienced in pricing per-project work. It can be a really guessing game with outcome varying from 1x to 3x, for larger projects even more. So closer towards the end when they realized how much more work there actually is than what they anticipated, you can see them lose their motivation.
However, if you hire them to do bits and pieces of the project and pay per hour, then no, bug fixing can't be included.
So I would never recommend hiring people on per-project-fee.
Re: Have u thought about.. by Xest · 2013-05-21 23:13 · Score: 4, 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: Have u thought about.. by Anonymous Coward · 2013-05-21 23:21 · Score: 2, Insightful

Reductio ad absurdam, eh? The reason "programmers [are] exempt from workmanship standards" is, ultimately, the Halting Problem. 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.
Re: Have u thought about.. by Registered+Coward+v2 · 2013-05-21 23:43 · 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.

--
I'm a consultant - I convert gibberish into cash-flow.
Re: Have u thought about.. by neonedge · 2013-05-21 23:43 · Score: 2

I disagree. It was written in an 80-hour weekend, and admittedly had a few bugs during beta testing, but once those were resolved it went into production and there was never a single bug reported. In fact this was probably 8 years ago and although it has mostly been replaced by other applications, it is still in use at a number of customer sites. Writing code with bugs is inevitable, however refusing to fix them because "there is no such thing as bug-free code" is just asinine. It's like saying "car accidents are inevitable" and then driving away from an car you just smashed into. You're as responsible for the bad code you wrote as you are for the good code. If you weren't then you probably shouldn't get paid at all.
Re: Have u thought about.. by Registered+Coward+v2 · 2013-05-21 23:48 · Score: 4, 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.

--
I'm a consultant - I convert gibberish into cash-flow.
Re:Have u thought about.. by Half-pint+HAL · 2013-05-21 23:51 · Score: 2

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 spec, barring exceptional (and very clear) circumstances.

--
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Re: Have u thought about.. by Anonymous Coward · 2013-05-21 23:59 · Score: 2, Interesting

Why are programmers exempt from workmanship standards?
Because almost nobody wants to pay what it would cost to write programs that are mostly bug free. Mind you, there are applications where correctness is valued high enough to invest the time and money to get it right. Most people have decided that it's not worth the wait or price though and prefer to live with functionality now and updates later.
Re: Have u thought about.. by DarkOx · 2013-05-22 00:00 · Score: 2

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 lots of contracts are written block of time. In which case I think you are obligated to pay for additional hours if that is what is needed to make something work or decide not to continue, but you still pay for the time used so far. Now you still may have issues with the quality and quantity of work falling below industry norms. If that happens you maybe don't hire that person again, and if its really really out-of-line that is what courts are for.

--
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Re: Have u thought about.. by Joce640k · 2013-05-22 00:02 · Score: 2

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 price for software maintenance that kicks in after a grace period. This makes both parties understand that all software is imperfect.

--
No sig today...
Re: Have u thought about.. by Shadowmist · 2013-05-22 00:04 · Score: 4, 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.. by Joce640k · 2013-05-22 00:06 · Score: 2

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.

--
No sig today...
Re: Have u thought about.. by parkinglot777 · 2013-05-22 00:14 · Score: 2

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 I take the OP words, his answer is in his post -- "... then shop it around to developers who are interested." In other words, the contractor must understand and agree to work with a fixed amount of payment before starting the work. If the contractor thinks that the money is not worth the work or he/she is expecting a certain hours of work, he/she should have negotiated before working on it. If he/she gets paid the full amount but could not deliver the work as the given spec (good enough with bugs), what do you think who is responsible for the extra work afterward?

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.
You are taking it quite far when you talk about legal. To do so, you have to be sure about your written contract with developers that ensure you to do so. It is not easy though because interpretation of laws is not the same for everyone. If you have even a hole in it, you will waste both time and money.
To me, the OP is not clear on 2 parts. One part, he/she said that he/she is an excellent product spec writer. My question would be how excellent? If his/her write up is that great, then the bugs in the software would be from the contractor (developer). However, if it is just good enough and the software produces bugs that are hidden (or not obvious) in his/her spec, then it is his/her responsibility (and the write up is not that excellent).
The other part when he/she talks about his/her client complains about bugs and he/she wants the developer to fix them for free. This is very important. What kind of "bugs" he/she is talking about? End users usually do not know what they want, and may expect something different from what the software introduces. As a result, the users complain and report the issue as a bug because it is not exactly what they want. If that is the case, the responsibility is for the OP himself/herself. However, if the bugs come from misinterpreting of the spec or incomplete implementations, it could be from the developer. I said it could be because there are some cases that the spec is not written clearly. This then refers back to what I said earlier, how excellent the spec writer the OP is?
Re:Have u thought about.. by Cenan · 2013-05-22 00:16 · Score: 2

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.

--
... whatever ...
Re: Have u thought about.. by pmontra · 2013-05-22 00:20 · Score: 2

There are "hard" bugs (let's call them so) as in "a +=2 instead of a += 3" and there are "soft" bugs as in "neither the customer nor us thought about that (possibly very complicated) combination of inputs and internal state, and our code doesn't yield the right result". That's the "what do we do when..." question that many times developers ask to designers. Unfortunately hard bugs are relatively easy to find with test suites and code reviews but soft bugs can accumulate unnoticed until the end of the project. Some become apparent only after it goes to production and the real world finally hits the code. Then the development team starts feeling like they're not their bugs (probably fair) and like they're working for free so they ask for more money just when the customer is least happy with them. There are technical and contractual ways to protect both parties against this kind of problems but they increase the costs and are not always appreciated by customers, not even after bad thing happened in production.
Re: Have u thought about.. by HungryHobo · 2013-05-22 00:23 · Score: 4, 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.. by pruss · 2013-05-22 00:37 · Score: 2

Though for sufficiently serious problems, one can have recalls many years later.
Re: Have u thought about.. by Xest · 2013-05-22 00:40 · Score: 2

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 would say to me that they didn't have the necessary experience to understand the way software is built and what can go wrong because both I and they would be exposed to far too much risk to be healthy.
Re: Have u thought about.. by Dr.+Sheldon+Cooper · 2013-05-22 00:43 · Score: 5, Interesting

I have had the pleasure of being the project manager on several fairly large software projects during my career. These projects were finished on time and to spec. Everything the customer asked for in the agreed-upon scope worked. Everyone was happy...

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.

--
Bazinga.
Re: Have u thought about.. by Shadowmist · 2013-05-22 00:45 · Score: 2

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.. by Xyrus · 2013-05-22 00:56 · Score: 2

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 who use your software in a way never thought or intended. Look at how long some software products have been around. Look at the Linux kernel for example. There's a team of crack programmers hammering on that thing year after year and yet they still find bugs in OLD CODE.
Using your line of reasoning, software developers would never get paid and would have to give lifetime support for their product for free. That doesn't make any sense.

--
~X~
Re: Have u thought about.. by sycodon · 2013-05-22 01:20 · 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.

--
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Re: Have u thought about.. by pla · 2013-05-22 01:24 · Score: 3, Informative

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?

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: Have u thought about.. by beelsebob · 2013-05-22 01:35 · Score: 4, 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.. by ArhcAngel · 2013-05-22 02:47 · Score: 3, Insightful

You said you were a programmer once. What made you leave the field? As a "former" programmer myself I left because of the pressures that came from employers who demanded that a feature in the newly released competitor product A must be implemented in our product by the end of the week or the company would fold. Customers who demanded a feature or functionality they never requested but demand that they did be added or they sheepishly request new features at the end of the project and want it added gratis. Add to that a programming landscape that shifted so frequently it was impossible to stay on top of the language du jour. I used to love to program but after doing it for a living for a few years I find it hard to this day to even look at code without painful memories.

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.

--
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
Re: Have u thought about.. by Belial6 · 2013-05-22 03:47 · Score: 2

The hourly vs. deliverable is likely the biggest conflict he is facing. I have found that virtually 100% of the time customers want hourly if the project is done early and by deliverable if it runs late. This problem gets way worse when the customer is another contractor sub-contracting out their own work. The fact that he didn't mention whether his rates are hourly or by deliverable implies that he is playing this game.
Re: Have u thought about.. by idontgno · 2013-05-22 04:58 · Score: 3, 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.

--
Welcome to the Panopticon. Used to be a prison, now it's your home.
Re: Have u thought about.. by Zalbik · 2013-05-22 08:34 · Score: 2

Bugs do not just "appear"
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).

If, due to bugs in your program, it does not perform exactly as specified
I have yet to see the customer that wants to pay to have the developer specify "exactly" how software will perform. I could see this being easily as expensive as the actual development cost (after all if every coding path was perfectly documented, it should be pretty trivial to actually write the code).
Additionally, requirements can be misinterpreted between the customer and developer, such that the developer believes the system is working perfectly, while the customer thinks it is broken.
Look and feel "bugs" may exist where the customer expects a certain usability that is either non-standard or not explicitly covered under the requirements.
The problem is he OP hasn't specified exactly what kinds of bugs he won't pay for.
If it is a case of scope creep, poor requirements, poor communication of requirements, new operating environments, new data configurations, etc and he wouldn't pay, then I'd hesitate to work for him either.
A much better practice would be for him to pay for bugs, but be choosy on which developers he re-uses. In any other profession, the cost of "mistakes" are passed along to the customer. While building a new building, if the electrician installs a plug then realizes "oops, this is supposed to be a GFCI plug", it's not like he stops the clock, goes and gets a new plug, removes the old plug, installs the new one and restarts the clock. He gets paid for the cost of his "mistake".
My question would be: Why is the customer seeing these bugs at all? Sounds like more of an issue with a poor software development lifecycle than an issue with coders trying take advantage of him.
Re: Have u thought about.. by Xest · 2013-05-22 19:46 · Score: 2

"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 everything you write is new (and if it isn't, you're doing it wrong, why aren't you taking advantage of reusable components?) so you simply cannot predict ahead of time how long something will take with any reasonable degree of guarantee. The same is true for many research projects, the same is true for a lot of engineering projects. Projects in industries like these aren't like production lines where you have masses of historical data on identical or near identical tasks to go on - you know your factory can churn out 10,000 chocolate bars in a day on average, but you don't know that your team of software developers can definitely solve problem x in a day.
"When requirements change, you change the contract through a renegotiation. If they don't want to change the contract, you don't change what you provide. That's standard practice for contracting."
This shows a complete lack of experience on your behalf on dealing with clients. If you act like this you'll a) often be wasting more of your time and their time renegotiating contracts than you will just doing the changes because the changes rarely come in one big bulk lump, but normally come in at a trickle, and b) Your customers wont be your customers because forcing them to waste time with a contract renegotiation over say, roughly a days work is the quickest way to piss them off and show how inflexible you are. They'll go elsewhere.
There's also the fact that it's impossible to write down a perfectly solid spec, if they want something different and you try to demand they pay for a change request or you demand contract renegotiation they're just as likely to find a hole in the spec (and there will be holes, writing a hole-proof spec is more difficult and time consuming than writing 100% bug-free software) and use that to make your life difficult. You may not even have a leg to stand on to even claim it's a change request or a contract renegotiation.
You have to allow at least some flexibility whilst also catering for that fact. You can't apply programmer binary logic of "It's a change, therefore contract renegotiation is required" in the real world - real clients wont go for that, there are shades of grey in between that you absolutely have to cater to if you want to stay in business, especially if you want repeat business and to grow your business.

Wake up by Cenan · 2013-05-21 21:22 · 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.

--
... whatever ...

Re:Wake up by merovingi · 2013-05-21 21:28 · Score: 3, Insightful

It's good to vent out our frustrations and anger on others especially when they are asking for ideas.
Re:Wake up by KraxxxZ01 · 2013-05-21 21:29 · Score: 5, Insightful

Signed. Also "empathy for developers" and " I do not pay for bugs" does not compute.
Re:Wake up by Joce640k · 2013-05-21 21:30 · Score: 3, Insightful

if your specs were so masterfully created there would be no bugs.
does not compute.

--
No sig today...
Re:Wake up by complete+loony · 2013-05-21 21:45 · Score: 4, 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.

--
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Re:Wake up by jellomizer · 2013-05-21 21:50 · Score: 3, 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.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Re:Wake up by ShakaUVM · 2013-05-21 21:55 · Score: 3, 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 by jellomizer · 2013-05-21 21:57 · 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.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Re:Wake up by BasilBrush · 2013-05-21 22:08 · 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...
Re:Wake up by Cenan · 2013-05-21 22:11 · Score: 3, 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.

--
... whatever ...
Re:Wake up by CptNerd · 2013-05-21 22:13 · Score: 4, 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.

--
By the taping of my glasses, something geeky this way passes
Re:Wake up by Bearhouse · 2013-05-21 22:19 · 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 by Cenan · 2013-05-21 22:25 · Score: 4, 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.

--
... whatever ...
Re:Wake up by Cenan · 2013-05-21 22:32 · Score: 2

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.

--
... whatever ...
Re:Wake up by Cenan · 2013-05-21 22:37 · Score: 3, 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.

--
... whatever ...
Re:Wake up by Kjella · 2013-05-21 22:44 · Score: 3, 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.

--
Live today, because you never know what tomorrow brings
Re:Wake up by Cenan · 2013-05-21 22:58 · 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?

--
... whatever ...
Re:Wake up by Impy+the+Impiuos+Imp · 2013-05-21 23:32 · Score: 2

A house builder typically gives 1 year to find problems. After that year, you do a walkthrough with them and show them a list.
So give support for bugs for a limited time, and then that's that. Bigger companies with ongoing multiple contracts or a desire for more work would be more flexible. Also, slightly different features are not bugs, but sometimes you cover those,!too, for the same reason.
Ironically, I think it would be easier for an independent contractor to fix their own bugs since they could do it on their own time if necessary. If you bid poorly such that that is costly, over and over after you should have learned, stop being unethical.

--
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Re:Wake up by Andover+Chick · 2013-05-22 01:14 · Score: 2

Two hallmarks of an extreme narcissist is that they lack "empathy", even if they speak of empathy, and they are self congratulatory. A person saying they write "excellent" specs is clearly an egomaniac and someone asks for bug free code in no way has empathy.

Sounds like a partnership by Anonymous Coward · 2013-05-21 21:23 · 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? by Anonymous Coward · 2013-05-21 21:24 · Score: 2, Insightful

How about hiring a decent tester and catching the "bug" a lot earlier?

Completion Bonus by CaptQuark · 2013-05-21 21:29 · Score: 5, Interesting

Hold back 10-15% of the total cost as a completion bonus. Pay the completion bonus when the project reaches a completion milestone of no critical bug reports for three weeks or version 1.1 coding begins.

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! by Kwyj1b0 · 2013-05-21 21:29 · 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...

There's no such thing as non trivia bug free code by HungryHobo · 2013-05-21 21:54 · Score: 2

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

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.

Pay for the tests by mangu · 2013-05-21 21:56 · Score: 4, 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:Pay for the tests by Anonymous Coward · 2013-05-21 22:58 · Score: 2, Insightful

That's test-driven development. Write the tests first, then write code which satisfies the tests. Done.
It doesn't work like that, because there is no way to completely specify a non-trivial program through tests. For (a trivial) example, suppose I specify that I want a program which takes two numbers, adds them and outputs the result. For acceptance, the program shall be tested with the following test cases: "1+1=2", "2+4=6", "100000+234=10234". Now if you're a good programmer, you're going to write the program such that it takes any two numbers (positive, negative, large, small, integer, non-integer) and adds them arithmetically. That program would surely pass the acceptance tests. A lazy programmer might just write a program which looks up the result in a table and consequently satisfies only the acceptance test but is otherwise useless. Note that the specification was vague and didn't include any information about the types of numbers you want to add. Was it wrong not to include imaginary numbers? What is the input format for floating point numbers? Decimal comma or decimal dot? E-Notation? What about rounding and input and output ranges?
Program specification is like writing laws. It's not context-free (in the real world sense, not in the computer language sense). We all make assumptions about the scope of the specifications. Almost always a programmer can only decide what the actual requirements are by making use of extensive application knowledge.
Re:Pay for the tests by biodata · 2013-05-21 23:05 · Score: 2, Funny

So sorry to point this out but 100000+234=100234, not 10234, so your test spec contains a bug itself. You need to hire someone else to test the tests.

--
Korma: Good

Project management includes handling QA. by joe+user+jr · 2013-05-21 22:04 · Score: 2

"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.)

--
.sigs: Just Say No!

Sounds reasonable to me by GeoSanDiego · 2013-05-21 22:07 · Score: 2

I am a developer who also has some experience paying other developers for a project. I do not agree with some of the criticism you are getting. If you say up front you won't pay for bugs then the developer should not accept the work if they don't want to work under those conditions. It is easy to say "all code has bugs" but it is also true that cleaner and well thought out code will have less bugs and the more unit testing that is done on code the less bugs it will have. Why reward sloppy behavior? Nothing wrong with getting developers to own it. The project I subbed out was a fixed priced project. Bugs and omissions were plentiful, and although I wish the developers were more careful, at the end of the day it was their own time that they were expending on fixes.

Re:Software *is* bugs by CptNerd · 2013-05-21 22:07 · Score: 2

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 changes in the business rules after development starts, and many many other causes. To hold the developers responsible for finding these beforehand, and refusing to pay for any work needed to come up with fixes or work-arounds, sounds like he's not really interested in maintaining the systems he builds.

He also sounds like a real peach of a guy to work for in other respects, as well. I wish him good luck in finding his cheap experienced expert developer.

--
By the taping of my glasses, something geeky this way passes

Not in touch with reality by eennaarbrak · 2013-05-21 22:11 · 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.

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.

Cars dont have bugs WTF ?? by johnjones · 2013-05-21 22:42 · Score: 2

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:scrum by crutchy · 2013-05-21 22:47 · 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 penis" and go from there. by the way, the price will be a lot less because i don't spend all your money fucking around, but you will spend some money working closely with me. we'll be so close it'll probably get creepy :)

Forget it by Opportunist · 2013-05-21 22:50 · Score: 3, 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?

--
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.

Sigh... repeat after me by mwvdlee · 2013-05-21 22:51 · Score: 4, 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.

--
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?

Can't afford a good developers' salary? by Afty0r · 2013-05-21 22:52 · Score: 2

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 by gr8_phk · 2013-05-21 23:01 · Score: 2

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.

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.

To Pay or Not To Pay, That is the Question by neoshroom · 2013-05-21 23:04 · Score: 3, Informative

Really is all depends on how he pays, doesn't it? I am a contract freelance software developer and I use the exact same policy he does with clients.

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.

--
Big apple, new Yorik, undig it, something's unrotting in Edenmark.

You want the best of both worlds? by RobinH · 2013-05-21 23:12 · Score: 2

So you're paying these developers some kind of contract rate "by the hour" but you then want to impose a fixed scope and hold them to it later? I mean if you're providing them with a complete (perfect) functional spec, then ask them to bid on it as a fixed price, make sure they include a 1 year warranty for any software defects, and then by contract they have to fix the bugs. Sounds like you just want the benefits of paying by the hour without any of the negatives.

--
"I have never let my schooling interfere with my education." - Mark Twain

Hey Slashdot, racist jokes are not OK anymore by I'm+New+Around+Here · 2013-05-21 23:20 · Score: 2

The QOTD at the bottom of the page is currently this:

Q: What do you say to a Puerto Rican in a three-piece suit? A: Will the defendant please rise?

WTF?

--
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.

Re:Stop being cheap. by scrib · 2013-05-21 23:43 · Score: 2

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?
You find bugs in the code during development and testing.
You find bugs in the spec when you deliver.

--
Help! Help! I'm being repressed!

Why do the bugs only surface toward the end? by Stolpskott · 2013-05-21 23:46 · Score: 3, 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 by bugnuts · 2013-05-22 00:00 · Score: 2

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:Stop being cheap. by MrMickS · 2013-05-22 00:10 · Score: 3, 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.

--
You may think me a tired, old, cynic. I'd have to disagree about the tired bit.

*How* do you pay? by bradley13 · 2013-05-22 00:13 · Score: 2

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.

--
Enjoy life! This is not a dress rehearsal.

Being a Publisher on the Cheap by Shadowmist · 2013-05-22 00:20 · Score: 2

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 ? by mrmangosir559 · 2013-05-22 00:24 · Score: 3, Insightful

Sounds like to me there is no UAT going on. Old method but, Development->UAT->Product, should be the most basic method. Sounds like you are handing over the software without any sign off from the customer. If they are signing it off, are you getting them to test it first? As part of your contract with the developer, you should be making sure the developer is aware of this process. That "within reason", the customer should be testing the software according to your specification. Any bugs can be returned to the developer. Once it meets the specification, then the customer signs it off. The customer is then aware, any issues after that period they pay and the developer knows after that period they get payed. Having an employed developer, means you have an overhead if you have no business coming in.

Thoughts from an Analyst by realsilly · 2013-05-22 00:43 · Score: 4, 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.

--
Life takes interesting turns, but the most interest is when you're off the beaten path.

Re:Thoughts from an Analyst by gnasher719 · 2013-05-22 04:22 · Score: 2

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 by MadKeithV · 2013-05-22 01:09 · Score: 5, Informative

What is missing from the question, and being filled in by expectation by many of the previous posters to this story, is how you define your bugs that you want your developers to fix for free.

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 by drinkypoo · 2013-05-22 01:09 · Score: 2

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.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"

Let's pick apart your requirements by satch89450 · 2013-05-22 01:33 · Score: 2

"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. by mcmonkey · 2013-05-22 01:40 · Score: 3, 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 by holophrastic · 2013-05-22 02:24 · Score: 3, 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.

Comment removed by account_deleted · 2013-05-22 02:29 · Score: 2

Comment removed based on user account deletion

Feel for you. by DarthVain · 2013-05-22 03:52 · Score: 2

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.

Slashdot Mirror

Ask Slashdot: Moving From Contract Developers To Hiring One In-House?

93 of 524 comments (clear)