Slashdot Mirror
Ask Slashdot: Moving From Contract Developers To Hiring One In-House?
An anonymous reader writes "I run a small software consulting company who outsources most of its work to contractors. I market myself as being able to handle any technical project, but only really take the fun ones, then shop it around to developers who are interested. I write excellent product specs, provide bug tracking & source control and in general am a programming project manager with empathy for developers. I don't ask them to work weekends and I provide detailed, reproducible bug reports and I pay on time. The only 'rule' (if you can call it that) is: I do not pay for bugs. Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code. Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs. Then all of a sudden I am asking my contractors to work for 'free' and they can make more money elsewhere. Ugh. Every project ends up being a battle, so, I think the solution is to finally hire someone full-time and pay for everything (bugs or not) and just keep them busy. But how can I make that transition? The guy I'd need to hire would have to know a lot of languages and be proficient in all of them. Plus, I can't afford to pay someone $100k/year right now. Ideas?"
Hiring contractors you can trust and pay them to fix bugs?
Pay for the bugs. Done.
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
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.
How about hiring a decent tester and catching the "bug" a lot earlier?
Outsource to someone who can understand English, has good reputation, from countries with smaller pay / hour.
àà®à¥à®à¾à¦ààYà¥àà àà
....payment by results, where results involve sign-off for the code after it has passed through the customer's independent test and acceptance process?
Are you actually saying that you do not have such a process, and that people get paid once they have delivered code which they claim meets your specs? If so, that's where the problem lies...
You will get sued for that crap here.
Well, you should be paying them to fix bugs really... it's analogous to not paying a sports team if they lose. I'd be surprised that you'd get developers of any real quality with that approach, especially if you're mentioning it up front. Despite best intentions and well authored specs even the best developers are going to miss some things. Maybe some Utopian world exists somewhere where bugs don't exist, but it ain't this one. A better approach might be contracting a decent tester to work with your developers?
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.
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...
That said, you could offer principle in your business in addition to direct compensation. Someone disciplined and good probably expects more than 100k/year.
And now for a derail: There are always bugs, and for a reasonably complex project they're probably most of the actual development time (testing or not). I'm surprised anyone agrees to your terms.
Every project ends up being a battle because they aren't writing 100% bug free code first time (for anything moderately complicated no one can) and you refuse to pay them to fix bugs?
Am I missing the point or is this entirely a problem of your own creation?
in general am a programming project manager with empathy for developers. I don't ask them to work weekends and I provide detailed, reproducible bug reports and I pay on time
hardly true. If you want 100% bug free code then expect the devs to take twice as long to provide the solution (and that's being optimistic). If you don't want the tested-to-death solution, and want to take a pragmatic approach where you assume some bugs will fall through the dev process, then you'll get the solution quicker overall. (obviously there are some devs to whom a bug is a way of life, I assume you will not hire them again)
BTW good for you, not wanting devs to work weekends. Do they get national holidays off too? You are just the kind of empathic boss Dilbert would die for.
specs? are people stilll writing specs? how wonderfully waterfall of you.
use agile techniques.
for example...
2 week sprints. you are the product owner. split your "spec" into stories (thin vertical slices of the system). you and the contractor negotiate how many can be done in a sprint. at the end of each sprint he delivers you *working software*, you (or the real customer) test it and pay for the two weeks. if its buggy you dont pay. if all was well you pick the stories for the next sprint.
repeat.
if you've never come across scrum or xp before you have some reading to do.
I need a full time bug fixer but I'm too cheap to pay one.
Please help me.
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?"
Yup: Get a new business plan where you can afford to pay for that which you wish to purchase. You know - services in, money out. It's like yin/yang - a balance.
Every project ends up being a battle [...]
Dare I suggest that it just might be possible that you are not the genius project manager that you think you are?
This must be the dumbest thing I have ever read here. That OP is a total idiot is one thing but why is Soulskill not doing his job as a shit filter? This should have been sent to write only storage as soon as it got here.
"I do not pay for bugs" Actually you do, but you clearly don't like it.
If you are going to be wishing for things like the perfect employee (knows lots of languages, is proficient in all of them, is cheap) then you might as well just wish for peace on earth, good will to mankind .. and a pony.
And while you are doing that, take a look a what people with experience in only a few areas are being paid, and then factor in some overheads. Or in other words, is that $100k as salary to them and you will have a bunch of overheads to carry, or is the $100k including overheads? Because if it is the latter then you are going to realistically be offering well less than $100k salary.
You get what you pay for, and if you cheap out on a salary you are not going to get people anywhere near as good as you think you need which has the potential to damage you business.
I am Slashdot. Are you Slashdot as well?
Do your job properly first time round. Done.
Seriously, aren't you upset when Microsoft sells you a new operating system and it's buggy? Didn't you pay for finished, working software rather than an extended beta test version? The whole software supply-chain would be much better managed if everyone was held properly accountable for their failure to produce code to the contracted specs.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Sounds like a nice setup you have there, but seems odd that either you or the contractors are surprised that there are bugs come the end of the project. Also sounds like the contractors are might be in the easier position at that point because they can just walk away.
Is there any way that you could alter your project plans to catch bugs before the end of the project? Smaller deliverable within larger projects?
Or employ someone at a more junior level (easier to teach and mentor?) and use them to look for issues as code is created by your contractors?
So, do I understand you correctly, if the code you get has bugs, you don't pay the developer for it? Well, hopefully you then at least consider the code copyright still belonging to the developer. Because otherwise, it sounds like a scam to get code for free (because face it, every non-trivial code will have bugs). I can understand that the developers would not be happy with that.
I think you just a marketer. get 40% down payment. push to developer to build. then paid the developer 10% value. if bug you chase developer. lol..
If I'm reading this correctly, all your issues come from one assumption: you are assuming that "the right spec should produce no bugs". I'm afraid that's impossible. Bugs don't occur because incomplete or missing specs, at least not only. At the end, they occur because probrams are written by humans. And humans make mistakes. A spec, no matter how well written, can't "fix" that.
You are not structuring your incentives to match your needs (or your clients') on that false premise. Once you have payed them, the devs will (naturally) not have any incentive to fix any bugs for free.
Most projects actually accept that bugs are inevitable, and set aside an amount for fixing them. It is usually called "maintenance". I encourage you to try that. Your developers won't work for free, and everyone will have the right expectations.
Also, notice that this doesn't mean you will pay more; you could try lowering your rates per hour a bit, so that the project costs you more or less the same (less $$ per hour, but more hours). Etc.
As in any other business, the trick is knowing what everyone wants, and finding the right compromise.
Go fuck yourself!
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.
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.
Wow, lots of vitriol in this thread. I think you pissed off some developers >: ).
Based on what you've said, and the sounds of having done multiple projects, you should just switch your tactic but still using contractors. Personally, using contractors can be cost effective, but managing them is the difficult part. It sounds like with the exception of bugs, you're managing them well enough.
The best approach is to negotiate milestones and have your contractors sign off on it at the beginning of the job. The most important milestone being acceptance of completed project by customer. This is standard practice, I agree you shouldn't be paying for bugs. If your spec is detailed enough, you shouldn't be paying by the hour but I understand some guys do to keep contractor costs under control.
Empathy is a good skill to have, but remember this is business on all sides. Contractors get the benefit of charging more than full-time employees, but you have advantages as well when you hold the purse strings.
"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!
Writing very good specs means having a good understanding of the business needs for that project.
Both getting to understand the needs and writing great specs take a lot of your time and effort.
So perhaps you should learn how to code yourself. Spend just as much time understanding the business problem, then write the specs in a brief way (you obviously know what you need to do anyway), then code it yourself. No miscommunication possible. Any bugs are yours and yours alone.
I'm pretty sure you will gain a lot of respect for those who do coding as a living..
To Terminate, or not to Terminate, that's the question - SCSIROB
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.
In your contract, you should have acceptance tests specified. The contractor that hires you should test and approve the product. If it's not what they want, contains bugs, or is not as specified by them, they should not accept. When they have accepted the product, they should pay for bugs. You should agree about this before starting.
For now, fix those bugs, and think of it as a good and valuable lesson.
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.
Quote:
"I market myself as being able to handle any technical project, but only really take the fun ones..."
"I write excellent product specs, provide bug tracking & source control and in general am a programming project manager with empathy for developers."
"I do not pay for bugs."
"...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."
"Every project ends up being a battle."
"The guy I'd need to hire would have to know a lot of languages and be proficient in all of them."
So you're a great salesman with a perfect pitch, until it's time to deliver the final product and the whole project unravels as a sordid mess. Of course, "bugs" are the developers fault, and as long as "they are fine with it", everything looks great! Until the customer sees the final result of course, and starts demanding getting value for money..
The best advice I can give is: Be completely honest with yourself! Question everything!
You're a great PM? Says WHO? I'm sure you have a great personality and are a good marketing / salesman guy, which is a good start to start your own business. However, if you're going to stay in your current role without burning out, you and "your" developers, you need to completely rethink your attitudes towards project management.
To start:
What are the critical success factors, the most crucial outcomes, for the customer?
Did you spend 50% of the time on gathering and refining requirements from the CUSTOMER? Are you completely sure your customer knows what he wants, and that you FULLY understand the scope of EACH and EVERY requirement? How many iterations did you walk through the specs with your client and developer?
Did the customer sign off the specs, SLA and test cases (what is the acceptable level of quality?), and you are fully confident the customer knows what he's getting and what he's not getting? Are you fully confident all the developers and customer is on the same page?
If you truly want to improve the process instead of blaming your developers and neglecting your customers for lengths of time, I suggest you learn "Lean IT", and apply what you can to yourself and the processes you can affect positively. Sadly, you can't really change all customers / clients, so a PM should expect some fires in their projects. However, with the right focus on quality and drive to get ROI, you should be seeing improvements quite soon if you're truly any good (DO expect to work weekends in the beginning). To succeed, you NEED to be hungry for it, and stop patting yourself on the back!
To be blunt: Going the other way, from lean to a "thicker" model, where you're expected to provide to the livelihood of someone else, I suspect these same problems will pop up, but then you're stuck with what you have so it's either do or die. I suspect you stay afloat now by running away from your problems, which is not going to work when actually hiring someone for good.
I like the fact that you take on the fun projects! When you truly follow the heart, you will find ways to make it work and things will go more smoothly. Just make sure it's not just fun for you, but also for the customer and developers. I sense you have a happy spirit behind this all, and that is a great start. So what can be done as early in the process as possible, to keep the happy spirit throughout the entire project? True happiness is the only true measure of success, and also, with happiness and good spirits, success will tend to chase you, and not the other way around.
The guy I'd need to hire would have to know a lot of languages
There's your problem right there. If you are doing in-house development, you should stick to one language. Especially if you have a small company, but it kind of holds up for larger companies as well.
e.g. if you have four programmers, two proficient in C, two in Java and a Java programmer quits, then suddenly your single Java programmer needs to do all the Java work. If you have 4 programmers proficient in Java, then if one quits, you still have 3 Java programmers left.
In the end multiple languages just means less flexibility in capacity.
if your problems are bug related, maybe focus your contracting efforts on testing, validation and verification because that's the stuff that you shouldn't rely on yourself to do, and you shouldn't rely on your contractors to test their own code either.
you then need to write your code to take most advantage of the testing. don't just test once. test, record the test, and use the recorded test in automated regression testing so that the test can be repeated for every build (without having to pay for a tester to repeat the same test manually).
also, everyone knows how important it is but few do it... unit testing... code the test before you code the function to be tested, and don't skimp on unit testing. some think you must unit test absolutely everything, but they are fruitcakes. test what you must, but test those things properly. a poorly designed test isn't much better than no test at all.
I'm not sure what the outrage is about - not paying for bugs is a reasonable policy to strive for. But you DO have to pay for testing and bug fixing as they are important pieces of the software production cycle.
In my experience for general-purpose development you need a project manager, developer, tester and designer. Those don't really need to be four different people, but it's also unreasonable to expect one guy to do three or four of those jobs while being proficient in all languages and technologies required for your various projects. It's also generally more expensive to have your developer twiddle with UI or do his own testing.
Anyhow, I think you can still pull it off given a certain definition of in-house. Example: I'm from Eastern Europe and I've worked full time for US-based clients (with contracts and everything). $50k is quite enough to get a top-notch developer here. Personally I've done projects for iOS, Android, Windows mobile (complete with reading credit card data and payments over 3G), both front-end and back-end development for web sites, C++/Python search engine, plugins for Photoshop, small Java desktop apps and even software for car clusters (FYI that's what they call the dashboard electronics) in C. While it's not exactly easy to find good experienced developers here (or anywhere else) it's definitely possible.
In short there are quite a few places in the world where $100k per year gets you a small office and a competent development team that will work for you full-time.
if you're the boss then
hire one in house
if you're the contractor
don't accept in house job
you seem to be the boss. Want to hire a real good one?
aim for 25-30 years old with not so much professional experience BUT a huge amount of collaboration on open source projects that can show off his own projects via github or else.
Put priority on the young geek with a decent ego that has 10 years+ of linux background as a hobby.
It's hard to find but not impossible. You'll get more for your money than say a 30ish contractor like me who will charge 5KE net/month.
It can be the other way around depending on the length of your projects (6 months ? then go for a contractor, more than a year? go for inhouse)
you have to balance the length of the projects where your geek will be active, the knowledge required for the project and how much who want to put in his salary.
there is no fitting response to this question, it's a balance between your requirements (type of project, length, money to invest etc...)
I had a problem when contracting that the client didn't want to pay me to fix bugs. I told him he could either pay me to test it for 8 hrs, or he could pay me for 15 minutes here and there to fix tiny bugs.
Then you're doing it wrong. Let me try and explain with your points:
I run a small software consulting company who outsources most of its work to contractors. I market myself as being able to handle any technical project, but only really take the fun ones
Fun for who exactly. You should be taking work based on your known good contractors, their availability and the cost of the project. Fun is a meaningless adjective you've added to make yourself seem like a nice guy. This is a lie any programmer will see through.
I write excellent product specs, provide bug tracking & source control and in general am a programming project manager with empathy for developers. I don't ask them to work weekends and I provide detailed, reproducible bug reports and I pay on time.
Paying on time is the only thing of worth here. It's not hard or expensive to set up bug tracking or version control. If they're contractors they work their own hours, so your weekend point is totally redundant.
The only 'rule' (if you can call it that) is: I do not pay for bugs. Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code. Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs. Then all of a sudden I am asking my contractors to work for 'free' and they can make more money elsewhere. Ugh. Every project ends up being a battle
Oh boy, Mr Empathy has turned into Mr Hollow in one sentence.
I'm guessing you're the type of employer that doesn't pay people when they get sick? After all they could have taken more precautions, right?
Contractors should be measured by cost vs average, quality vs average, ease of working with vs average, time to deliver vs average. You're so far off the ball here it's not even a joke.
If you're wondering why each contract is a fail (in your words) this is why.
Solutions:
Pay for all the work, bugs, feature changes, everything that person does.
Pay on time.
Listen to your contractors and make sure they listen to you.
Choose contractors that don't make thousands of bugs to pad their payslip, make working relationships with good contractors, make sure they're available for the jobs.
Question their bugs if you think something is fishy. Get advice from a contractor you trust.
If you've burned all your bridges by burning all the good contractors then honestly you're stuffed. Stop exploiting people so you can make a living.
If you want some-one cheap, then get someone who you can train. Can't train them because you don't have the knowledge? A bit of a pickle really.
Bottom line is, treat your staff and contractors as human beings and maybe you'll reap the reward. Treat them like thieving sub humans and enjoy a stressful and unhappy life.
I am a contract software developer and have this exact same same policy myself. That is, when I get a client I ask for detailed specifications and we put them on paper. Then I go to work on the project. If when done they want a feature that isn't in the spec, we create a new milestone and they pay for it. If they find a bug and want it fixed, I fix it for free. It's just another way of saying "I guarantee my work."
There is no possible way that masterful specs can eliminate all bugs. In fact, I'm guessing you don't quite understand what he is referring to by "specs." Typically, specs from non-developers are a list of features they want, things they want the program to do, what they want the workflow to be and possibly how they want the program to look or wireframes. This isn't things at the level anywhere near code or pseudo-code and so it isn't really possible to eliminate bugs at this level. Putting a fault tolerance number wouldn't even help because whether something is one bug or two bugs is often somewhat arbitrary and some mythical evil programmer could easily put intentional bugs in the program to run through this artificial limit (which is why I'm pretty sure Microsoft uses the system you described...;) ).
I've been using basically the same policy he describes for years without issue. So, my advice to you is chill out and my advice to the poster is I'm sure there are other developers like me out there who you could use for contract freelancing. I mean, you wouldn't hire an architect who would built you a house but if there are structural problems post-construction would refuse to repair them at no cost (or would only repair three and after that you have to pay him extra). It's a pretty reasonable policy.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
It may be expensive to write bug-free code, but it is always better than having software with bugs in it (which you then have to test and fix).
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
Include in the specifications the bugs you want. Problem solved.
My suggestion is you look at your current list of contractors, order them by how well they cooperate with you, and make the "best" an offer. You won't find anybody perfect, better the developer you know than the genius you don't!
Who?
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.
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?
If you want an excellent engineer, you need to pay at least reasonable.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
1) If you want bugs to be their problem, agree on a fixed project/product price beforehand.
You set the priorities, they set the planning, you only care about the finished product/milestone which is of course bug-free.
Its near impossible to get this planning right though: often development is research, and (i found that) research can inherently not be scheduled in a strict sense, only time limited or at most steered/supervised to align with priorities. An answer of research can be "no", in which case more research is needed unless you've foreseen this casus and have a workable alternative to drop in (always wise to accommodate for / have in engineering).
2) If you want to prevent bugs from being a (contractor) problem, work agile / in sprints. Short reviews each week, allow you to prioritize bugs instead of these being piled up. Of course, some bugs are better left for last.
3) If you want to hire someone new, consider hiring an intern first. Or two. Get some first hand experience in managing an IT project, agree on a schedule and try to stick with it, and you might just end up with some insights that help understand why your contractor works/talks the way it does.
Also,
You shouldn't save bugs for last. Aside from the "working for free", in software development 1 bug + 1 bug is 5 bugs and a lot of confusion, so this results in more work/costs anyway.
Also, there is a difference in "getting functionality complete" versus "postponing bug fixes until later due to priorities" and you should never do both at once, for any given part of the software.
Hivemind harvest in progress..
I was in the exact same position a year ago, and decided to try out an option suggested to me by a veteran in the IT outsourcing business:
Realization: Nobody write bug free code, not even the best coders on the planet. Writing buggy code is part of the process towards a finished product.
1. Use only established contractors you know provide good quality artifacts. Getting these at a price you can live with is the hard step.
2. You pay for bug fixing like everything else.
3. Pay a bonus if hours spent bug fixing 5% of total project hours. This is an incitement to have focus on quality.
It works amazingly well.
What's harder to deal with is misinterpretation of specs. This has killed a couple of projects for me. Spend a LOT of time initially getting the spec right and communicate every detail about it so you know contractors understand it.
It's not easy. But done right following an Agile implementation, like Scrum, will allow you to monitor progress, let the customer decide what get's build, allow you to make reliable estimates and more.
As a contract programmer I don't charge for bugs. Because I'm my own employer, I account for the bugs I expect to make in my rate. Moving from contractors to employees, this is just another hidden cost you have to account for. You should also account for ongoing training and so on.
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.
I don't know how anybody could think that all software bugs should be the "fault of the contractor who should fix them for free".
Even if the meaning of bug is "not what my spec says should happen" that's still impossible. And in the real world, not even specs are ever perfect.
Sometimes the customer is only able to see that what is necessary is the opposite of what is in your spec. Is that now a Feature, not a Bug?
W
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.
Not paying for bugs makes sense, there is no reason you should release code to someone if it doesn't work. That being said any new graduate should be willing to work for about 50k out of school and they usually come equipped with lots of languages. Just make sure you pick from the middle of the grade pile, the people at the top are usually just show boaters with no real programming skill and the guys at the bottom just don't give a shit.
Always better? Rubbish. Whether having software with no bugs is "better" or not is determined by a cost/benefit analysis between the business impact of having the bugs versus the cost of fixing them.
Real businesses make decisions this way; at least the ones that plan to be around for a while.
If I were in your shoes...
1) Do you provide Unit Tests for your code
2) When you write your specs to your clients, you probably breakdown your project into phases, so, for each phases, do you clarify the deliverables and the expectation of functionality?
3) Based on number 2), you should be able to provide functional testing, which in this case, if it passes and your unit tests passes, would then qualify your product as deliverable and I would make sure that these would be the criterias for the software I'm writing.
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
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.
Dilbert knows what to do.
"No matter where you go, there you are." -- Buckaroo Banzai
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.
As a contract freelance software software developer (and I happen to be one as well) nobody else is determining how much work you need to do for a fixed amount of money. You are the one determining this. Really the trick is just getting a detailed feature-set and being good at estimating how much time things will take you. After you do that then you simply double the amount of time (because things don't always go smoothly). On half the projects where things actually do go smoothly it will work in your favor.
If someone else says "I think it will take this amount of work to write this iPhone app and I am willing to pay this amount of money" and it isn't in your opinion enough, you can just walk away and not take the contract.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
This one guy, assuming he has a finite amount of time, and you have a lot of projects, would barely have time to flex his muscles at each language. Descide if you need designers or implementers or stenographers, (in that order) and realize you might be better off with 2 (cheaper) implementers, even if they should climb some time consuming learning curve for some project.
Hivemind harvest in progress..
Pay bonus for product of acceptable quality and make sure contractors confirm online that you are actually paying bonuses. Build yourself a reputation of trustworthy client and you would attract qualified contractors.
There is nothing wrong with your model, you just to be up front about it. You have delivery X with features A and B and then .
However the "respect developers" part must include that not everything is a bug even if it's unexpected. If something is unspecified then it's "according spec". Also if the customer changed their minds, it's not a bug. You have to be able to show it's not done upto spec. Changes cost money.
How about you go fuck yourself, you fucking cheapskate.
Remove the quotes around "free" and put them around "empathy".
Your in the wrong business, start a lawn service!
Make sure to explain the scenario to the contractor up front. In detail. More than once. Give them a chance to raise their offer to include this. Ask them again how certain they are about their ability to estimate their bug rate. Let them sign a separate page describing this in simple language.
Have a process to clearly separate bugs that are covered by this from modifications for which they are paid separately. For some small things that are arguably not bugs but modifications let them have the benefit of the doubt and pay them for it, anyway. Make sure they know it.
I think it can be done.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
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.
I work for a software contracting house. We do some work at fixed price so we get paid X to finish a job, no hourly pay. This means we work until the job is done, even at our own expense as long as the customer does not ask for anything beyond the initial contract.
If you have good specs why don't you require unit/system tests? The overhead is about 30% for writing testing code.
My contracts were: 25% down, 50% on completion, 25% when they were 'happy'. If the customer was dishonest I found out when I lost either the 50% or the last 25%. If they had bugs they could withhold the last 25% until they were satisfied.
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.
I'd clean toilets before working for this guy. He's pretty clear on the fact that he doesn't pay his 1099's
(I didn't say he was stupid, but it's clear he's paying his employees on 1099 to leverage his negotiating
position to get "free" labour) "employees" in a timely fashion - I've see how these guys are which is why
I never contract on 1099 (in the USA 1099 treats an employee as a regular creditor unlike W2 which has
very strong laws to protect the employee - in some states, failure to pay a W2 wage is an indictable offence).
This is probably the worst kind of person.
The fact that he uses "software" as a vehicle for exploiting people for his own gain doesn't give his terrible
business practices any more credibility or justification.
and I'm pretty sure the /. crew (or my cat) could come up with a relatively simple technical challenge that even
he couldn't deliver bug-free the first go-around (no offence to Fluffy, my cat).
Just sayin'
CAPTCHA = 'careen' ?
He commits another basic sin of having no provisions in his contract for handling bugs, and is now surprised that it got him stuck.
Wait, are you sure about that? He called this a rule of his and so I assumed it was in the contract. Basically, if he didn't put this in the contract it is his bad and he should pay extra for bug fixes and if he did put it in the contract then the developer shouldn't complain (as long as it is a real bug and not a stealth feature). You'd assume if this was a rule of his though he'd spell it out formally in his agreements with developers.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
1) Given any sufficiently complex real-world programming task, the avoidance of bugs is actually *impossible*. That's even true under the gracious assumption that the true nature of some things you end up calling "bugs" aren't actually caused by deficiencies in your requirements. It's not just that one or two bugs will slip through occasionally as a result of programmer shoddiness. All complex software *always* has many bugs at any given time. Even if you go years with nothing but bugfix work trying to perfect the codebase, you will never rid the codebase of bugs. It's fundamental to the nature of software. The complexity is far, far higher than you think it is even for relatively "simple" programs.
2) Contract programmers are never a good solution if you want a stable long-term codebase of high quality. You need developers to *own* their code in the long term if you want that. The same guys that wrote it need to be responsible for maintaining it and debugging it in the long term. They need to refactor it as their own skills grow. That you've been trying to build higher-quality code with contractors is a really bad smell that you don't understand so many fundamentals about how high-quality software actually gets written. It's a slow process that involves art and love. A good codebase gets that way after years of evolution. An initial write of a chunk of software is never great. It's not like hiring a contractor to pour a new driveway for your house.
3) You'll never find your one highly-skilled in-house multi-language developer for under $100K. If whoever you hire is that cheap, they're not as good as you want. Hiring one badass developer to try to wrangle the efforts of all those contractors is a poor plan anyways.
In short: you're way off base in your thinking. If whatever you're doing is making you a profit as a small business and you can sleep at night, just keep making a profit and be happy. But don't delude yourself into thinking that you're currently producing great software, or that your business model is even remotely close to being capable of such things. Sometimes contract programmers happen to be richly-talented awesome programmers; this isn't a dig at the contractors themselves. But the process of contracting programmer effort pretty much kills your ability to generate a high-quality codebase even from high-quality programmers, and your view of software bugs is juvenile at best.
Can you really say that all the bugs your customers are complaining about are the developers' fault? Are you making developers use libraries or frameworks they wouldn't have chosen themselves? Are the deadlines sufficiently loose to allow time to do sound analysis, engineering, testing, and refactoring? Are you contracting developers with sufficient experience and education, and paying them competitively?
If you dictate the technologies, leave the spec open for interpretation (did YOU specify how the app should behave when various hardware fails, a third-party service is slow to respond, etc?), have tight deadlines, or recruit inexperienced developers then you're as much to blame for the problem as the developers.
When you buy software it should work without bugs. And I'm sure those lazy programmers could do it too!
Only drawback would be that software would take a lot longer to make. There would be proper designs, actual testperiods and no managers shouting "ship it already!" behind them. Be prepared to pay an obscene amount of money for properly designed and build software.
Or quit your bitching and accept that you get a metric ass-ton of software with not-a-lot of bugs for less money than you spend on "designer coffee" in a week.
As a software engineer working for a managed engineering services firm mostly in the Avionics and embedded fields, what it sounds like you need is an in-house tester. Forget them coding anything other than test harnesses and/or regression scripts, assuming you don't use one of the few test development tools out there such as VectorCast or Rationale (which would further increase costs based on it's own cost-quality analysis), as a dedicated tester would simply be designing requirements based tests for the specs you provided. It more effectively solves the problems with both your requirements, which I doubt are perfect, and any code implementations, which I doubt are perfect. A tester only needs to know enough about any given language to write a test case which is also the case for the lower pay of a quality control engineer which satisfies one of your other needs. Not wanting to "pay" for bugs is fine, no company wants to, but facts are facts: You're going to because they'll be there in either the implementation or the requirements. Minimize the potential issues with a dedicated test team to validate both the requirements and the implementation. Solid quality control requires time and budget but is realistically the only way to reduce the error overhead while providing faster feedback to the dev team: devs code, testers test and the PM keeps it all straight until delivery of all artifacts, including 'valid' PRs.
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.
I don't think you quite grasp the scale of "expensive" in this case.
Even with modern processes it can still come to hundreds of dollars per line to actually be certain.
http://www.mail-archive.com/sc-l@securecoding.org/msg01278.html
Though that only covers making sure it does what you think it should do, it doesn't cover making sure what you think it should be doing is what the client thought they were telling you it should be doing.
What you actually want is code which *probably*
has very few bugs which you can create for a sane price and at a sensible speed because most clients want their software this year, not 10 years from now.
There's always a tradeoff.
>Developers can make more work for themselves by causing bugs And project managers can attempt to get free work by disguising features as bug reports.
And yet, what would the programmer do in this case? Code to spec, code as he thinks it should work, or go back to get better specs?
In a fixed price project you bet I'd do the first! I don't have time to do the correct thing (get better specs) and I'm not failing any tests on my own dime.
Remember this guy:
http://it.slashdot.org/story/13/01/16/0354218/employee-outsourced-programming-job-to-china-spent-days-websurfing
Obviously perfect for the job. He might even be available due to his former employers lack of vision.
AC
I will prove you wrong right here:
#import "stdio.h"
int main(void)
{
printf(''Hello, world!\n'');
return 0;
}
(Really, it has a bug and I proved him right.)
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
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.
You are not qualified to supervise someone who does code. People who view themselves as "project managers" who manage by purchase order or with "specifications" and "bug reports" but do not possess the actual knowledge of how to code simply do not have the right to any opinions on the subject. Most of these 100% skill-free people were laid off during the Great Recession.
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.
I wouldn't work for you if you 'could' afford to pay a decent wage you prick. Shove those bugs up your ass.
However, I'm wondering about the 100k price range. In general, as in life, you usually get what you pay for. But, if you happen to find someone good in your price range, they will likely change jobs as soon as they find something better.
But I see a few ways to save money. Your best bet is to move away from SF, NYC, Boston, Seattle, or any other major city. You can also consider recent college grads. Though they may not have lots of experience, you can possibly find a true hack0r that spends all their free time doing coding for fun and has learned lots of languages and tools. Also consider H-1B workers. They usually have lower salaries. (You can also go for the trifecta, recently graduated international student in a small college town)
However, given that you keep hiring poor contractors, you should carefully examine your interview process before hiring a full time employee.
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.
First, good project manager with empathy for developers knows that bugs are fact of life and plans ahead for them. No amount of threats will make your developers bug free, in house or contracted. Second, if you truly believe that your specification is so perfect, then there is no chance for you. No analyst is perfect, just as no programmer is perfect. Those two facts of life are the the core of your problems.
Add freaking testing into your process. Hire capable testers. You do not mention testing at all. Get customer feedback as early as possible. Issue tracking and source control are easy to set up and maintain. The real value is in testing.
You do not pay for bugs, do you pay for changes caused by faulty or unclear analysis? Or by analysis not being in tune with what customer want? Or do you call everything programmers fault and ignores when they are trying to point mistakes in your analysis? If it is latter, then you should stop believe your own marketing.
"I market myself as being able to handle any technical project, but only really take the fun ones, then shop it around to developers who are interested."
So, he's lying to his potential customers. He can handle any technical project, but in most cases, he's not the one doing the work. Right out of the gate, he's setting himself up for failure.
"I write excellent product specs"
Oh Lord, if I had a dollar for every time I heard that. I'm sure he THINKS he writes excellent product specs. Let's ask his developers. I'm willing to bet they have other opinions. In 20+ years of software development, I have never seen "excellent" product specs--ever.
"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?"
Yeah, here's an idea--do all the work yourself. Here's another idea--stop being cheap--you get what you pay for.
One last thought. If you're having some issues in Production, get used to it--that's the nature of software development. If you're having serious issues in Production, then your software development process is flawed. Fix that first. Blame the developers only when you know (that is, can quantitatively prove) they are the problem.
Don't "don't pay for bugs"!?? Code of sufficient complexity will ALWAYS have "bugs" especially when deadlines are tight and it inevitably uses third party libraries/frameworks. Nothing in the universe is bug free. You're either an incredible egomaniac or you don't understand basic engineering. You're both asking developers to work for free and you don't want to pay market rates, how does that provide "empathy"???? If you want cheap coding then outsource to a developing country where coders w/poor communication skills will write obfuscated code to guarantee their employment, then you won't be able to get rid of them so you might as well make them employees.
... you're an asshole.
Seriously, you are. I own a small development company with a handful of contractors, and I treat them just like my regulars. Bugs are par for the course, and your "I don't pay for bugs" attitude simply betrays your lack of understanding a) of how to treat employees and b) how software engineering and development actually works, or worse, c) you're clever means of exploiting contractors for free work.
To sit there underneath your little tin foil hat assuming your contractors are trying to take advantage of you is no way to run a business, and there is probably a two-way street there as well. I would venture a guess that you have probably succumbed to the temptation to file a "bug report" that had a new feature or specification change cleverly disguised in it, and had contractors tell you to go fuck yourself.
In any case, you're not someone I would ever do business with, let alone hire to manage anything, because the only thing you've made clear here is that you're a terrible person to work for, don't know how to run a business, and don't have any clue how to manage software projects.
Scruples are important if you want to be successful in running a business. I didn't get to be the owner of a multi-million dollar company by scamming my employees out of work. They're your most important resource, above everything else, and you have no idea. I have; however, summarily fired plenty of people like you over the years.
"I write excellent product specs, provide bug tracking & source control... with the specifications I write there is no excuse for not testing their code."
You, as the owner of the company, are responsible for the code you ship to customers. If you write excellent specs and feel there is no excuse for dev's not testing their code, then YOU, as the owner, ALSO have no excuse for not testing the code you ship to customers.
The good news is, testing should be very easy because have such excellent specs to work from. Right?
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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.
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.'"
By "not paying for bugs" it seems that you're paying hourly. If you can't trust your contractors, pay them by the project. Sometimes you'll "lose" money if they finish it under budget, but you know up front what the project will cost (assuming no change requests). Just pay them 50% up front and 50% at the end.
How are you billing your customers? Are you billing them by the hour worked or by the project?
I work for a major consulting firm, and the way we handle it is dead simple:
We deliver the code, and our clients know that we will only stick around for three months after we deliver it.
They will pay us for those three months, and we will fix any bugs they find in that time.
Do the same with your clients and your contractors.
You're just a bit too much a programmer, and a tad too sharp an entrepreneur.
Become somewhat more a manager and factor in some 'fat' -- both in the invoices you charge your customers, and in the time you allocate your contractors. Remember, crap happens. If it doesn't, and your contractors manage to deliver bug free code ahead of time, give them a 'performance' or 'quality' bonus (i.e. payment for the full time allocated). Do not chase profit maximisation like big shops do. They have adequate manpower buffers to beat you at your own game.
Alternatively, hire someone skilled --- but don't be cheap. Remember, if you chase cost reduction like the small shops, your employee obtains the hunger (he already has the skills) to beat you at your own game.
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.
Sounds like you're screwed.
Look, if you're not willing to pay for talent, and consider that a cost of doing good business, then you have no right doing what you're doing. Speed, cost, quality: pick two.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
Only unintended features
1. Write very good project specification so the client and the developer know exackly what is expected (changes in scope cost you and the client).
2. Only write fixed cost contracts.
3. Structure the delivery of software and money in equal parts (exa. pay one half of the money for delivery for one half of the software).
4. Warn the developer that he (an you too) only get the final payment when the client accepts the final project as specified in step one (bugs fixed and all).
"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.
... so I can be sure to never interview with him or send someone to him. This is either a joke or the guy knows nothing about software development.
I have more sympathy than some here. I know from experience that all of the regulatory hurdles associated with hiring full time employees are a pain in the ass. Going from 0 to 1 is a big leap.
If you can't afford $100K (don't forget benefits, matching FICA taxes, etc.) forget looking for an underling well versed in multiple languages. I think you should be looking for a business partner instead of trying to get a developer on the cheap.
You come off as supercilious and holier than thou. "I keep the fun ones for myself" and leave the scut work for my lessers? "perfect specs, perfect bug reports" It's just those pesky lame coders who keep making mistakes and I don't pay them for mistakes.
Unless it is a trivial homework problem in school, there is no such thing as a perfect spec. What are your statistics on number of issues that turn out to be "misunderstanding of requirement" or "change in user needs"?
Pay for decent workers, pay them to solve all the problems during the full life cycle, and they won't go elsewhere. Adjust the rates you bid to account for it, which is what *real managers* do. You're acting like a slave master on a plantation: "more cotton! work all night, work all day, don't drop any!"
This must be a spoof article or a troll on a large scale.
You don't state what types of bugs that you are finding.
Generally speaking, developers are good at testing functional issues - for example, if they are asked to code a "print report" function, they typically will be able to test the "print report" function so that it works as expected. What developers are poor at testing are use-case issues, where you are integrating a function within the larger scope of program. They test to make sure that the "print report" feature works, but not check to see if it handles cases where someone logs out before printing or if someone edits the data right before printing.
You have 3 choices.
1. Hire a separate tester who tests from a use-case perspective.
2. Pay for your contractors by the hour, instead of per-project.
3. Pay for a full-time employee.
As others have mentioned, developers are notoriously bad testers, especially since it sounds like that you are hiring developers for one-off jobs. A lot of development knowledge comes from working and refining the same code. Hiring one-off developers will generate more bugs than having a single person working and re-working the same code.
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 see a lot of assumptions in these comments, like the OP is an ass, doesn't know what he's talking about, etc.
How about this: Programmers are NOT gods, and contractors will ALWAYS try to get out with the minimal amount of work done that gets them paid.
If I hire a contracted programmer to build something and deliver it, and it turns out it has bugs in it, then I'm going to demand that they fix them - after all, the contract required that the deliverable actually WORK to the spec I provided. Why this is such a foreign concept to so many people on here I'll never understand.
If you're a freelance programmer - great, I think that's awesome. Working for yourself is incredibly rewarding. That said, if I contract you to complete a task, and you deliver something that's buggy and doesn't work right, you haven't fulfilled your contract until it meets the specifications that I provided and that were written into your contract, even if that means you have to spend more time on it than you originally estimated because you didn't do it right the first time. I'm not going to pay you for that extra time, as it's your fault.
If, on the other hand, I wrote a bad spec and the software you deliver works to the spec I gave you, but not what I actually need, and I need it changed, then I WILL pay you for the extra time to modify it, because I didn't do my part correctly.
Use your specs to write your acceptance tests and your acceptance tests to write your specs. There are plenty of tools available. We use cucumber.
Cucumber comes with a very English-like language (Gherkin) that can easily be converted to actual tests. We pay our contractors only when all tests pass.
No confusion: The actual spec is also the acceptance test.
Our 'user stories' in Gherkin get written by business analysts, not programmers.
Hajo Monogamy: Belief so strong that millions of people end perfectly good relationships in order to start a new one.
I don't believe in "insourcing" on these types of project work - you're not going to find the kind of resource you want with the skillsets you desire. The right approach is to explicitly have the contractors understand the cost of fixing bugs needs to be baked into the project estimates. Additionally, ask for a 30 day or 90 day warranty under with bugs would need to be fixed. Fixed bugs would extend the warranty (for the bug fix itself and resultant issues) by the number of days it took to fix the bug.
I do believe in using bonuses for deliveries with exceptionally few number of bugs. But I am concerned that this can be abused if it is not an objective measure.
I also believe payments based upon milestones achieved and delivered - with a penalty for late delivery when not accompanied by a change order justifying the delay.
YMMV.
Find a good coder and make him/her a partner in the business. Eat what you kill. Stop trying to profit disproportionately off the labor of others.
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 based on user account deletion
Do the specs include unit tests?
I could see that if the requirement states that the code must meet spec and demonstrate it by passing the provided unit test that might be reasonable.
This would be part of the review process and acceptance testing, not as you quote:
"Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs."
Don't wait until the end of a project to demand what your project management is supposed to provide.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
The solution should be to hire a QA subcontractor. Yo can never trust the developer to do 100% of the testing because he's too familiar with the code. Hiring a subcontractor to do QA should be cheaper than hiring a full time developer and more flexible.
IMO, the main problem is that you are giving contract programmers an incentive to do the wrong thing.
If I am reading your submission correctly, you are paying programmers hourly only for time spent writing code before handing it over to you. If issues are found after handoff, you expect them to fix the issues without being paid anything additional.
If I were your subcontractor, the first thing I would do is hire a subcontractor of my own to do QA. And I would bill you for his hours plus mine. As things stand, your subcontractors have a strong incentive to take as much time as they need / bill you for as many hours as they want in order to ensure they give you perfect code.
If you want to keep a similar arrangement in place and improve code quality, you need to add a positive inducement rather than just pushing them to fix bugs without being paid. At present, you are asking them to take all the financial risk related to bugs while you get all of the potential reward from finishing quickly. Look for a way to flip that around, perhaps with a fixed dollar amount budget for bug fixes. If they spend fewer hours than expected fixing bugs, they get the bonus of a higher than expected hourly rate. If they have more bugs than you forecasted, they get paid a lower hourly rate but they still get paid something.
Do you have acceptance tests define before farming out a project to contractor? Are the bugs outside of those caught by these acceptance tests?
If you can afford to hire consultants, and you're keeping a little for profit, you're probably able to hire full-time employees. That's making some assumptions about lags between jobs, what the employees expect in terms of "bench time" and corresponding pay.
You may not be able to hire the same consultants as employees at the same rates, as you may have to reduce your pay rate to cover some of the employee overhead. Reasonable contractors willing to work full-time should be able to accept this as they would then not have the same responsibility for accounting for their own taxes, and may appreciate whatever benefits you may be able to offer.
Consider not only the obvious things like health insurance, but also the PTO and sick days where you have to pay even when they aren't earning; built into the overhead correctly, it still comes out of the billable hours. It may be that you have to offer a package that includes a "base" rate that covers what they'll get paid on the bench, and a "job" rate that pays more while they're working; it might be that you have to do some math and figure out that less pay means more bench buffer; perhaps even build in a "profit sharing" mechanism that returns that buffer to the employee if the bench fund isn't used. None of this is new; check around the Interwebs for what other small houses do.
As for the bugs, I would stake a cross-country ride on the back of my motorcycle that at least some of the time something changes, and that's why there are bugs.
You hear the customer requests and from these you make outstanding designs and documents. After whatever negotiation and complete requirements gathering and design review they accept the designs and documents and your bid. Your programmers see and understand these documents, and their code reflects them beautifully. Then the customer sees the work at the delivery points, and perhaps finds things that aren't right. Maybe they see what has been delivered is right, but want a little more; or they see that it works in the cases everyone thought of, but not in the cases no one thought of; or they see that you've built what they said, but not what they wanted.
This could be the result of an iterative development cycle, communications, or straight-up missed things. This could be because something was done right, then a change was made (a new idea, incremental development, or previously undiscovered use case)...now the code and plan and customer are out of sync.
The hard reality is that bugs occur.
I understand the sentiment of avoiding developers who make bugs to extend contracts, but you have to realize that none of us is perfect, as hard as we may try, and any time another party is involved, there's an increase in opportunity for things to not go right. Work hard to compromise on fixing the things that have gone wrong (charge the customer, pay the developer) and things that are "malicious" or otherwise on purpose with an intent of dragging on contracts.
Be critical and strict with your developers, and keep them in line in terms of design compliance and coding standards, and make sure they aren't trying to stretch contracts; mitigate it with TDD or TDD-like practices like using unit tests to conform code to contracted specs. Also be aware of customer changes that sneak in...even little things like "that should be over more or bluer or say this instead of that" can introduce both distraction and unintended changes that can lead to the deviations from existing code or on code for which future work may depend.
It's a chore, but you can either build some "bug time" into your estimates and project plans, be hyper-vigilant about change control, or be super-strict about deviating from the plan. Somewhere between the first two is where reality lies, if you were thinking about the last two.
End the FUD
Comment removed based on user account deletion
When your business model depends on the charity of employees, you need a new business plan. An above average programmer, fluent in a plethora of programming languages, for under $100k? Apparently your business is not successful enough to actually pay for the requisites needed to survive.
The only real solution is to do the work yourself, small business man. You cannot expect an employee (or a contractor) to sacrifice for your dream, particularly when only you will reap the rewards. Otherwise, bring them in as a partner, so you can both scrape by for your joint business. Someday, you may be successful enough to hire help at the prevaling wage.
Quality code is something you should think of as a commodity.
Apply the laws of supply and demand to that, taking into account how hard it is to write perfect code, and how much you're willing to pay for it.
However you decide to pay them through the course of the ongoing project, hold back the last 33% payment until all possible bugs have been fixed, so if they don't fix them or want to work somewhere else at that point, they will not only lose that 33% of whatever they had agreed for the job start to finish, but they will be blacklisted by you and will hopefully find themselves in a world of shizzle they have created for themselves, being not able to get work elsewhere when their names pop up on the shizzle list of all shizzle lists for all the world to see with a master shizzle list you create, starting with the people that have already dissed you, complete with profile pictures and details.
Then you can take that 33% and strike a deal with someone else possibly familiar with the project, and finish the job, toast a toast, and move on.
Good Luck!
Just kill yourself. Your sweatshop should die.
P.S. Hire a a functional and performance test beginner.
Bugs don't just appear out of thin air. If you are only discovering them at the end it means you are not doing sufficient testing along the way. Either that or the scope of the requirements is changing. Pick a few key milestones and run through your test scripts (you do have test scripts, right?). If a bug is found at the next milestone that didn't exist at the previous one then you know where to look for the issue. Maybe think about contracting a dedicated tester? There is no such thing as bug free code...it's all about mitigating risk.
Correct me if I'm wrong, but is this the core of the problem?
"I contract people to do a set amount of work at a fixed rate, and have no problem getting them to work for me. After that's done I offer them a new contract where they continue working for an unspecified time and not get paid at all, but for some reason they refuse to do it. What is wrong with them?"
If this is really what you're asking, and you actually have to ask it, then I think I see where the problem lies.
Take advantage of the modern slave labor force and contract out to India or China. You'll be glad you did.
Relocate somewhere that coders are cheaper and hire who you want. Or hire someone and let them work remote.
Asking for a bug free code is asking to pay for a car that will never break down. In the real world there is no such product.
However there needs to be a certain amount of measurement what is considered bugs and all this is back to the spec. As a developer, you will need to have time to review the spec and ask any question, however small, that you may have. If the spec hasn't change and the code doesn't perform as described then it's a bug. Otherwise any changes, however small, is considered scope creep or scope change.
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.
Any development model that puts the onerous of testing on the developer and the customer, skipping QA, is bound to fail. Developers are very unlikely to effectively locate all the bugs in their own code, that's just a fact. You seem to think that your amazing specs are sufficiently detailed so that if followed to the letter QA should be unnecessary. I think you are highly delusional in that thought.And then you want to hire some sort of universal genius at sub-par pay to shield you from the hassle? Good luck with that/
Who QAs the software before it goes out to the customer? Having the developers test their own code does not count, and is no substitute for running it through an independent QA process. Sending untested software to a customer is just asking for trouble. If the customer is complaining about bugs towards the end of the project, why were the bugs found earlier? If the bugs were found earlier, then metrics need to be taken to ensure they are being addressed in a timely manner and not allowed to pile up.
Also, if you pay cut rate wages, you will likely get cut rate developers. In the end, that approach often costs more than paying the going rate in the first place. This seems to me a business management issue rather than a developer, quality or cost problem.
Keep the programmers as contractors. But hire a full time test team in house to make sure the bugs are found and fixed before the customer gets the software.
How about letting go of some of the profit put in your own pocket?
The OP does not formulate his options to pose a question to the community. I am sure he has thought long and hard on his problem but has not formulated something other than send in your fix for my vague options. Really it is not worth our time, and as it is I have wasted 10 min reading the thread and 5 minutes commenting on it. I am billing at 300$ /hr as an analyst, so where is my money?
Same old stuff. I'm a career contractor, I have several small companies like this contact me every month, they want some one who is highly experienced, highly skilled, and willing to work for well below market rate. World is full of loosers trying to get something for nothing. These people have never written any code, yet they always think there an expert with the technology. They have no experience with software ENGINEERING yet they want to be in the software business. Maybe they should move to India , lots of cheap crappy coders for you to hire over there.
MM
Okay parent.
AC is now curious about your shop.
But I can't tell if you're actually genuinely competent and have had bad luck, or are an idiotic douchebag. You sound like you're reasonably competent, but don't quite *really* understand programming.
But maybe you're one of the incredibly rare gurus that exist in about 1/2 of a % of the s/w population.
So...
Please post three sample specifications.
And the subjects of your bug reports
Because based on your tone and the way you phrased things, I'm... more confident than not that your specifications actually cause bugs by being internally inconsistent, incomplete, or through total failure to understand the real operating environment.
But maybe, just maybe... I'm wrong.
I'd like to be wrong.
Right, wrong, or indifferent, you always have to pay your contractors for their time. Big fixes must be included. If someone is writing shoddy code, you should be able to pick up on this early in the process and replace them. You get what you pay for, and if you want good work done, you're going to have to pay for it--no way around that. If you're going to udercut and push back about bug fixes, a contractor is going to tell you to get stuffed.. Our skills are simply too highly sought after to put up with people who nickel and dime and complain how much we charge.
And really, you're congratulating yourself for paying on time?? Is the bar for a good manager really that low? To quote Chris Rock, that's like bragging because you "ain't never been to jail."
I particularly like "I can't afford to pay someone $100k/year," which is junior rate for a contractor while he's expecting a flawless product.
Buddy, NASA, the guys who put people in orbit, spend an order of magnitude more on software development than a dev shop spends, and they still have two or three defects per thousand lines of code. I can't imagine you've never had a coder laugh in your face for your "no bugs" policy. What will you do when your contractors quit? Sue them? Factor in the cost of bugs and quit being such a pussy.
It may be expensive to write bug-free code, but it is always better than having software with bugs in it (which you then have to test and fix).
That's pretty naive I'm afraid. Let's go back to the all-popular house analogy. When you build a house you expect it to be correct within tolerance. Countertops level to within a certain amount of slope, et cetera. You can get a "more perfect" house/car/software-product, but there are always tolerances - and reducing tolerances begins to cost orders of magnitude more the further you go.
Most specs are also dreadfully naive (they have to be). They will almost certainly contain contradictions, such as a maximum size (database should grow no more than xxGB/day based on current user growth projections) and a flexible entry system (comments should not be limited in length) - in the Real World those requirements will almost certainly work, but if someone (who is a projected user) pastes in the Linux source code into new comment blocks all day every day it'll fail pretty quickly). Is that a bug, or (like demanding .01mm tolerances in house construction) just an unreasonable expectation?
You're special forces then? That's great! I just love your olympics!
Yeah I dabble -- but I cannot rent myself out as a programmer. So I don't have baggage here. The following sentence however scares me;
"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?"
"
Transition? This guy sounds like the Art director who hires me because I know all the apps, and can do everything including put it on the web and make it dance in multimedia. So he writes "specs" that are perfect? That's like a description of the "perfect art piece for the client" without anyone being the artist and seeing the art. Neither of the people in this situation has the ability to 'visualize" what they want or they wouldn't hire you.
The "transition" is difficult because finding that perfect programmer who doesn't need OTHER programmers is a person who doesn't need a glorified agent.
I would appreciate a well specced out job -- but I'm not going to long suffer doing 90% of the work for someone taking 90% of the profit.
There isn't enough to PAY both you and the perfect developer.
>> The PERFECT SPEC here, is obviously under-budgeting the De-Buggging process. Having done graphics work for people who don't know what they want -- 50% of the work occurs AFTER they say; "I like it, but can we try this other thing for a second?" I suspect programmers spend 50% of their time in debugging as the application meets the real-world. So this person is has a little bit of knowledge which is more dangerous than none. He THINKS he could be the programmer but doesn't have time for the "details".
I don't know for sure, however, but the problem described here would "send my spider senses tingling." We have a delusional dabbler coupled with pimp/contractor.
>>"ad space available -- low rates!!!"
If you want to do this for a living, start by getting a job in a company that does this kind of thing and learn how to do it. Perhaps you've been lucky to get this far, but the way you're doing business it's just a matter of time a pissed off client takes you to court and strips the skin off your back.
So what's missing? How about you include acceptance criteria with your subcontractor as well as client? Include support clauses on both sides? Include unit test code coverage requirements? etc.
1) Contract 3 developers:
- Developer to develop the code
- Tester to test the damn thing and find bugs
- Bug fixer to fix the damn bugs
2) From your experience, you should be able to set bonus related targets for each guy...
3) ????
4) Profit!!
Atheist: Buddhist in a Prius
If you are not reporting bugs until the end of the project it sounds like you are not testing and signing off on the components in a timely manner. Developers need quick feedback about issues and it is your responsibility to ensure they get it. A developer friendly approach would be for you to guarantee signoff to the developers within x days of the date they delivered the software. You can and should highlight this in your contracts and discuss your policy up front. If you are unable or unwilling to guarantee signoff then you are being disingenuous.
Software is a living thing with ongoing needs throughout its full life cycle, including BUG fixes. You need to understand and acknowledge this and communicate it to your clientele. Inform them that they will have "software needs" well beyond the duration of your contract. This is why maintenance support exists which might be another source of revenue for you.
Ignoring the nature of the product you are delivering will not do anyone any good.
For one, as others have noted, no code will wind up bug-free (except, of course, for *mine*....). Why is it that the *customer* is finding them? You say you hire programmers... but do you hire *testers*, a *whole* 'nother skillset, and who will do things like regression tests? If you're not hiring them, you're doing an inadequate job.
For another, you say you can't afford $100k/yr - well, I know a *lot* of folks who don't make that - hell, I'm not there, and I've been working in the field nearly 30 years. But what *are* you paying them... and if you're in the US, do you provide a health plan they can buy into? If not, why shouldn't they look for more money, given the insane prices that the health insurance monopoly charges for their extortion?
If you can't afford what you need, perhaps you're not ready to run that larger business.
mark
Fix the bugs yourself you insensitive clod.
I like the idea of using a bonus driven bug system. Tell the customer that he has X days to get them fixed for free, tell the developer that every bug resolution comes out of the bonus structure.
B) Eliminate all the stupid users. This is frowned upon by society.
You will always pay for bugs. Money to fix bugs will either get rolled in to the project cost with the initial bid or bugs will be invoiced when discovered. If the subby expects certain functionality, then it needs to be in the contract with appropriate means to verify acceptance.
I do not work with clients that expect bugs to be fixed for free. It's a strong indication that no amount of money will make the project worth doing.
So basically you want your cake and eat it too...we all want someone that knows everything and never makes a mistake. That doesn't exist. There are several problems with your business model, all of which are self-imposed:
--I can guarantee you your specs aren't as fantastic as you think they are, your own story gives it away. What you want us to believe is that your specs are always perfect, yet you "get toward the end of a project and the customer is complaining about bugs" but that clearly none of your developers are perfect. Nobody is perfect and that includes your part of the job of nailing down iron-clad/unchanging specs
--No one is perfect and your "logic" for describing how bugs should not be possible is flawed. After all, clients almost never pay for adequate testing (unit and user testing) and when you pitch a deal with adequate testing in your estimate, you find you are not selected, your competitor gets the contract instead.
--Telling programmers you are going to expect them churn out perfect code in unrealistic time-frames guarantees unhappy employees (if you got the job, there's a 99% certainty that adequate testing hasn't been budgeted for, and I've NEVER seen a 100% accurate up-front requirement doc that didn't involve clarification, changes, and feature-creep)
Now how do you fix all this? The above should be self-evident, you need to recognize reality a little bit more, but the bigger problem that sets you up for all this trouble is this: "market myself as being able to handle any technical project, but only really take the fun ones"
You claim to offer your potential clients something you really don't have: the skills for any job that comes along! Instead of that (false) advertisement, and "only taking the fun ones" you need to target contracts you have the skills to deliver on. To expect you are going to hire someone that is perfect in every language/tool that exists so you can go after every opportunity is very unrealistic indeed, and you set yourself up for the types of failures you are describing in your post.
Who do you hire? Well look at your strong skill set and compare it to your most successful (and plentiful) contracts. Find someone with a cross-over and complimentary skill set and hire them. Yes you will have to pay them appropriately. Then only market your business to clients with contracts you are actually capable of delivering on, only taking additional jobs that might require occasional additional temp-contract-employee hires to round out your skill set and that of your hired employee's skill set.
I've run a small company in several jurisdictions now, and my SO does small business accounting. I generally run my own taxes and I've had a good look at the tradoffs of hiring an employee versus hiring a contractor.
Every time, in every jurisdiction: Thou Shalt Not Hire.
Between the additional paperwork, onerous red tape, and ridiculous unemployment regulations and fees, I've decided vehemently against hiring every single time. IMHO, the only place where it makes sense are things like fast food, where you have a ton of necessary employees, can amortize the costs, and don't really have any other options.
YMMV, but in my opinion, local and state governments have seriously screwed themselves in this regard. The hiring environment is so business unfriendly that contracting will win pretty much every time.
Alter Aeon Multiclass MUD - http://www.alteraeon.com
Not to put too fine a point on it, but I think this is precisely why contracts exist...so people can't commit to something, not deliver and expect to still get paid. If they refuse to fix bugs, have someone else do it, then take the dev to court and get damages in the amount of your costs of having someone else fix their bugs.
Have you thought of another occupation for yourself?
....but you have to be a lot bigger fish than you are.
Outsourcing generally comes in two flavours "time and materials" or "fixed price quote". Small contractors will generally always go TM, but medium sized consultancies like to chase FP because taking on more risk equate generally to more reward.
I've worked for a few investment banks that have large internal development teams, but still outsource certain components of work to FP companies...which components? The high risk stuff...that stuff that is technically complex and likely to end up with a high defect count.
So, you identify the stuff that's going to be high risk, you shop it around to small shops that want to increase their profile by working with [insert multinational name], you get them to do a fix price quote...and here's the trick, you get your team of lawyers to draft an absolutely iron clad contract with specific UAT milestones including acceptable defect rates/priorities and knife edge specific definitions for each defect type/priority....you also include tiered financial penalties for missing milestones and/or metrics, ensuring that top level penalties are capable of recovery of monies over and above the total cost of the contract as required to cover things like marketing campaigns that had to be pushed back, opportunity costs, re-engagement etc etc. You then have your lawyer brief the testers on what they're trying to break, and what financial penalties get enacted if they do. If you have good enough testers you can really screw down the cost of delivery.
So:
1) Get realistic about what someone will charge you to take on all the risk of your product. Risk and reward go hand in hand in life, if you don't want the risk, you're gunna pay.
2) Get a bigger name....consultancies will drop their quote to get a known brand on their books.
3) Get better lawyers (yes, multiple)....you're gunna need them for the multiple drafting of the contracts and the ensuing law suit if you're looking to enact penalties.
or...you could just realize that TM means exactly that, pay your contractors what both you, and they, know they're worth and be thankful that they even work for you, because without them you're a very small fish with a pretty spec that's worth nothing to no one.
"I write excellent product specs" is bullshit, for bad requirements lead to most of the sloppy code out there. The choice of "programming project manager" as a title is a clue that anonymousreader has no clue of what else goes into SW development. Things like requirements gathering, test planning, code review, release planning, etc. Igorance is further displayed with the expectation that programmers "test their code"; assuming that they should, wouldn't this be restricted to unit testing? Are the same programmers also responsible for the system, integration, and user acceptance testing? Quality assurance is not the programmer's responsibility. Don't blame code-flunky for your incompetence.
-- Jimtown Kelly
"Developers can make more work for themselves by causing bugs" Your trust issues are sufficiently bad that you can't see what a stupid position you've put yourself in. Stick to the contractors.
It seems to me that he is admitting that his current system does not work, and he want to hire someone full time. So quit bashing him about the system that doesn't work already. How does he find the right guy to make the transition to full time?
This question clearly demonstrates that the OP has no understanding of the software development process. I've been doing software development for the last 15 years, mostly as a consultant, and have been on A LOT of projects at many different clients. I have yet to see one with "excellent product specs" completed up front. Why? Because customers never know what they want until they see it. And even when they think they have defined something well, they don't understand what they will actually get back.
Software is very abstract and unless you are a developer or a technical person (which most customers/users aren't), then it's very difficult to conceptualize how it will work once implemented. Then there's the reality of changing customer requirements and priorities. I'd like to know how the OP is writing perfect specs when such a thing doesn't exist in the real world. And there are many other aspects to development which the OP doesn't seem to understand either. Who is doing the business and technical analysis of these requirements? What's the process when requirements change? Where is QA and user acceptance testing in all of this?
I suspect nobody is doing these things. What's really happening is that he writes something up based on vague requirements (which are likely to change), throws it over the wall to a developer, and expects a polished product to be thrown back over. Meanwhile the customer didn't understand what they were asking for in the first place, changed their requirements, increased scope, got something back that was maybe close to the written spec but actually wasn't what they wanted in their mind, with no analysis or design having been done, that wasn't ever tested by anyone other the developer who wrote it. And all of those scenarios are called "bugs" by the OP. This is a dysfunctional process that is unfortunately all too common. No wonder your developers balk at fixing this stuff for free.
I don't doubt that there are bugs in the code, especially if the OP is trying to do this on the cheap. There is no substitute for experienced programmers, and there's a reason that people who are experienced cost more. So the first problem is that the OP thinks he can get something for nothing or next to it. But the main problem here is the OP's lack of understanding about the software development process.
If you want to improve things and not have your customers complaining all the time, then start with yourself - read up on software development methodology, ditch the waterfall/throw over the wall approach, and pay up for developers who know what they are doing. I'd suggest a more agile method where customers are very involved in the process, are able to get their hands on the product as it's being developed and provide continuous feedback. Otherwise, look in the mirror and expect more of the same. Developers don't need your empathy, they need a competent project manager.
Major bugs have little bugs,
which being fixed, can cause'em.
And little bugs have tiny bugs,
and on it goes ad nauseam.
The bigger bugs themselves can be
pernicious, tangled creatures;
So suck it up and ship the code
and we'll just call them "features".
(author unknown)
Why does it have to be a "guy"--or do you mean like "dude" in the generic, gender-neutral sense? At any rate, it sounds more like you need a partner--offer someone the promise of making even more money, should your tiny consulting firm make it really big and/or get bought by some big company (like, one you've done many projects for--worked for a place I worked at), or stock, and this person may work for less. If you're in the US you could also consider hiring someone on an H1B visa who's scurrying to get a new position--almost all of the folks I've met in this position are hard working and know a lot of different programming languages--and if you make a pledge to help them with Green Card issues, you could definitely negotiate a lower salary. But think about the hire as more of a stakeholder in your enterprise--you can still be the boss, but you're looking for a trusted deputy. It will be cool, trust me--just pick someone smart you feel comfortable with, with a varied resume and good contacts/references. Maybe even one of your past contractors.
"Developers can make more work for themselves by causing bugs..."
Many people have an element of dishonesty. Any management system must be robust to that.
On the other hand, working honestly, we still end up with plenty of bugs. As comments on this page attest to.
A disincentive might help (e.g. lower rates for maintenance than for initial development), but it's no good asking to do maintenance for free, because you'll soon lose your best developers.
A disincentive will also help the honest developer slow down and take more care with their coding, which will boost productivity enormously.
Better testing, you say?
Try to count every possible combination of ways to interact with the software that was just coded.
That's how many tests a programmer would have to run EVERY time a change is made in order for him/her to prove the software is bug free. It's not practical.
I don't know about other companies, I can suggest you to work with http://www.softteco.com./ Rates are between 20-$35/hour. They have different developers in the company, QA, marketing, support and you can check their profile. It's anyway cheaper and faster to deal with a company that has everything in one place than to hire a worker and believe that he can do the same cheaper. One person will need a hell of time to do the same job. Don't you agree with me?
Look long enough, throw enough input at it and anything but the smallest, self enclosed program will have "one more bug", with each subsequent bug representing a diminishing return. I'm sure some talented users could even find defect in "Hello World". Therefore from the contractors perspective, there should always be a "good enough" clause - often timeboxed/as a % of project at the end.
Or, perhaps, if his specs are as good as he claims, he should be writing the test cases and paying developers to pass them?