You are not my scammy developer
March 16, 2014 4:17 AM   Subscribe

I volunteer for a non-profit organization. We've had a work agreement with a small company (Basically one or two guys) to do Drupal development work for a year. Short story: the point person in our organization is suddenly no longer with us (deceased), the developer has terminated the contract, almost none of the specifications are complete. "Agile development! Hand waving! You don't understand." We're out a LOT of money and he is holding any not yet tested code hostage for another 15K in billing. All invoices past (approved by previous guy) and present (which I don't want to approve) consist of a single line: "X number of developer hours at Y rate = gimme Z money". They are autogenerated since the number of hours is always the max allowable under the work agreement and still addressed to the deceased. We are going to the lawyers soon, but...

A: Am I wrong in assuming this kind of invoice is total BS and not acceptable?
B: Is there a sort of Better Business Bureau for indie developers where we can find out if this guy has scammed other people before? Tried some Googling, but.... (Power in numbers!?)
C: Am I correct to think that if a competent third party arbitrator gets access to the github repository they can make a reasonable estimate of the actual hours of coding time for the code that is in there?

posted by Gotanda to Technology (15 answers total) 2 users marked this as a favorite
A. no, depends on the agreement you had with the developers. Billing hourly is perfectly normal for ongoing work. On a large, specific project, it might be more typical for payment to be tied to specific deliverables but that's the sort of thing that has to be agreed upon in advance and can often lead to a major headache for the developer as clients have a tendency to move the goal-posts and change their requirements but don't expect to have to renegotiate the goals to accommodate new requirements, especially if your point of contact is the actual developer rather than a manager who is job it is to say no when clients are being unreasonable and to renegotiate so the dev team isn't out of pocket.

C. not really, If I had access to the code, I could estimate how long it would have taken me to complete the same task - but the agreement you had was not with me, it was with these other guys. I also would have no way of knowing how much progress was slowed by the client - development is often a 2-way street and who you client is can make a big difference to how quickly things progress.

It really all comes down to the contract you guys had - if you agreed to pay them $x per hour for up to y hours then you're probably out of luck. You'd have to be able to prove that they hadn't spent the time they said on the project and that's likely going to come down to your opinion vs their word. They are right to hold the rest of the code hostage though if you've not paid them. You're not entitled to the work you haven't yet paid for.

It sucks but unless you had an agreement that included dated milestones, you're probably out of luck. Why did they terminate the contract? If they really work just slacking off and billing you for it, why wouldn't they want to continue that contract? Or did you stop paying them first?
posted by missmagenta at 4:37 AM on March 16, 2014 [2 favorites]

Response by poster: Thanks missmagenta!

There were no dated milestones. But there were vary detailed specifications and requirements in the work agreement to track development using Pivotal (They stopped) and to send "change orders" for work other than what was in the specs. No change orders ever, but lots of other work because... agile?

The last invoice the previous person paid was for November. Seems he was beginning to see the problem. He passed January. The developer announced at the wake that he was terminating the contract, which he had the right to do. That ended early March. He was basically off email all February but billed for it anyway. Seems we should at least get any code up until end of November and then negotiate from there.

Near the end, the developer farmed this out to another guy. I've spoken to him and he characterized the work as good, but with "a lot of unnecessary overhead". Sounds like padding to me.
posted by Gotanda at 4:58 AM on March 16, 2014

Best answer: At the wake? Ouch, that is tasteless. Its understandable he'd want to terminate if he hadn't been paid (and understandable that you'd not want to pay if nothing was getting done) but there's a time and a place...

If you're paid up til November you're entitled to that work, and if its all on github then it should be easy to get the version that current up to what you've paid for. Ideally the code should have been released to you when it was paid for, every time an invoice was paid.

It could be padding, it could also be incompetence or inexperience with the platform. If it was a major project and he hadn't used drupal much before, he could have been struggling with the learning curve. The code he wrote could have been good and solid, best practices and all that but if he didn't know drupal well, interfacing his good code with drupal may have been the problem. (its also possible he was overbooked and since your guy kept paying him anyway he slacked off on your stuff - sadly, it happens all too easily, the squeaky wheel gets the grease because its hard to get on with anything while they're squeaking at you and the nice patient client that never pressures or chases gets put to the bottom of the pile.

Lots of other work because agile? BS. What does that even mean? The point of agile is you get something function fast and then keep changing it until the client is happy. Not, you have loads of extra work to do and don't show the client anything for months.
posted by missmagenta at 5:19 AM on March 16, 2014 [1 favorite]

Best answer: This will definitely have to be sorted by lawyers, but that's an expensive endeavor that may not be worth it, depending on how much you've already sunk into this.

A) As others said, it definitely depends on the nature of your contract. Our contracts call for all paid funds to be non-refundable, the contract to be able to be terminated at any point beyond X number of sprints by either party, and a few other things that are basic recourse for us with a non-paying client, but we never hold code hostage if a client wants to switch providers or transition to an in-house resource. We might if we believed we were owed money for work performed.

I'm curious why he believes he's owed for new invoices after he indicated he was terminating your contract. It seems like a bad faith approach to dealing with you.

B) No. And you should be very careful, since they could make a claim of libel, even if what you're saying is factually accurate. That kind of stuff gets really, really sticky really quickly, because they can argue that your defamation of their character cost them their livelihood and seek additional damages and if a judge were to believe that they were in the right by the terms of their contract, and thus it *was* libel, that will be a rough time for you. You can report them to the BBB, but it doesn't matter. The BBB is somewhat functional for service providers, but for consultancies like you're describing... it's not really relevant. It's also an organization with no real power besides the ability to publicly post that complaints have been filed, and then they'll badger the company to become a dues-paying member, work towards a resolution, and help them be "BBB Accredited", which is of dubious value anyway.

C) GitHub will show a timestamped record of all commits made to the codebase, including how much code was changed, and by which developers. However, that can be misleading if, for instance, they were working in a local development environment for some time before committing a large number of changes. Moreover, "a reasonable estimate of time" is difficult to ascertain because people have different skill levels and a lot of "these features would take us this long" has to do with the holistic quality of the project: how complex it is, how good the code is in general, what sort of processes and testing do they use, rather than a hard-and-fast number. That is to say, you could get 6 different answers, they could range from 1x-3x of each other, and each could be accurate for *them*.

Sorry you're in this situation. It sounds like they're handling things extremely poorly, for no good reason. We're actively being asked to look at the codebase of another project in a similar case: bills keep coming, even though requirements are nowhere near met, with very little by way of an explanation of what's actually being done. A lot of time, those situations appear to be "developers are underwater and need bailing out, even though they don't have the work to show for it" and it's a shitty thing to try to pull on a client.
posted by disillusioned at 5:30 AM on March 16, 2014 [3 favorites]

Best answer: One of the main points of agile software development is that you have completed and tested code that you can deliver at the end of each sprint. The length of a sprint depends, but is roughly 2 weeks.

The user stories are ranked during planning, and then assigned out to each sprint (with some give, because things don't always work out right). Then at the end of each sprint, a demo is given to the client, to make sure it is per their liking. If it is, then the development team has the go-ahead to move on to the next sprint. If not, then they can deliver right there.

I'm telling you this because:
- Hand-waving about agile is not their smartest move, and you should know why it doesn't make sense.
- You need to see their board, with all the stories on it, and progress made on each story at the end of each sprint. You also need their sprint calendar, so you know when each began and ended, and who attended the demo. Those are the things that will give you the info you want.
posted by Houstonian at 6:13 AM on March 16, 2014 [3 favorites]

Response by poster: Not to sit on this, and it seems silly to mark every answer as "best answer" but you all have been very helpful. He announced terminating the contract in January after being paid November, but not yet December (well before 30 days on the invoice). And, actually notified first week of February, so billed for January and February.

Looks like we're screwed, but just wanted to get as much out of this as possible before turning elsewhere.

Thanks for all the help. I really appreciate it.
posted by Gotanda at 6:26 AM on March 16, 2014

The previous comments are on-point, so I'll just point one thing out:

Just because code is on github doesn't mean it's available to the OP. We usually think of github as a place for public open-source work to live, but it does have support for private repositories.
posted by Tomorrowful at 6:30 AM on March 16, 2014

FWIW, I've seen "agile development" misused to mean "we're making it up as we go along instead of working from a detailed and thought-through specification and plan." I've seen this a lot. This may well be what's going on here.

A.) As a freelancer -- my invoices often look like that because I'm actually working from an agreed-upon flat rate, but the client's internal accounting systems need me to bill something that looks like hours. This is not on its own a red flag to me.

B.) Alas no, there is not.

C.) You might be able to get a ballpark, but not one that could hold up in court. As Houstonian says, what you need is an accounting of milestones and deliverables.

You say the developer's contract was for a year, but... how much of that year has elapsed? Were they signed in August? Last January? It definitely sounds like they're screwing you over -- billing you after canceling the contract and refusing to turn over code is about five different kinds of uncool. But knowing how long the timeline is would help to establish just how uncool we're talking.
posted by Andrhia at 6:32 AM on March 16, 2014

Not sure what you mean when you say the specifications are not complete, since you later say you gave the guy very detailed specifications. I'm assuming you mean the development is not complete?

Here's what I would do (IAAL, IANYL):

1. Make a list of all the ways the developer did not live up to his end of the bargain. Go back to the original contract and specifications and see what the developer agreed to in writing. Document the ways his conduct or deliverables have not met those requirements (e.g., he stopped using Pivotal; he hasn't delivered code to you for months despite using Agile which is based on short development cycles; maybe there was a timeframe in the original statement of work that shows that development should be 80% complete by now but he's only finished 40% of it)

2. Go to the developer with that list. Tell him he needs to give you all code and documentation that he's created (there should be something in the contract saying he's required to do this). Say you'll pay him 1/3 of the amount he claims you owe him and call it even once you get the deliverables. If he accepts (or bargains you up), put something in writing documenting that the contract has been terminated, he is accepting X amount, you are accepting the deliverables, and you both release each other from any further claims. If he argues too much, threaten him with the lawyer.

Unfortunately for you, there's a concept in contract law of looking at your past course of dealing with this other party, and assuming that whatever was done in the past was what you both deemed acceptable. Since your predecessor presumably accepted these invoices and regularly paid them without arguing, it's hard for you to say now that the invoices are unacceptable. Same with the development practices -- if your predecessor agreed with what the developer was doing and didn't make a fuss about tracking or late deliverables or most of the things on your "here are the ways you screwed up" list, if you really went to court that would not work in your favor.
posted by chickenmagazine at 8:11 AM on March 16, 2014 [2 favorites]

A. The invoice was acceptable to your deceased boss, then it needs to be acceptable to you.

B. No, not really.

C. Other people have explained this well. A project is a dynamic process between you and the consultant. As so thought 'small change' can really mean hours and hours of work. Based on your company's communication skills, ability to plan out what you want in the beginning, and the consultants skills to explain what the programming entails and any changes entails in number of hours worked. Unless there is simply nothing at all you really don't have an argument. Untested code is still code. It may not have full functionality but it was still written and in progress. Think of it like a house, you may have a frame with none of what you see when it is finished. The frame is really really important, but you never see it when you buy the house.

It sounds like in your post there is tested code he has released to you? What is the quality of that work ?

Unfortunately it is kind of a business loss. No matter what employee even if they are doing nothing your responsible for paying them until they are fired or they quit. It doesn't matter if they are a consultant or front desk staff.
posted by AlexiaSky at 8:19 AM on March 16, 2014

A few comments.

Free legal advice is worth less than you pay for it (IANAL, etc.) but there is a big difference between terminating a contract and not paying on a contract. If you stop paying your cable bill, you still owe the bill, and they can keep sending you a new one every month that they are providing service. The cable company may cut you off until they get payment, but that's completely independent of the fact that the bills are piling up. Hopefully the contract you reference is a clear, specific document with more than just an hourly rate, but with a tiny shop maybe not. The contract may or may not say that any termination must be in writing, which would make the announcement at the wake not just ill-timed but also inoperative.

It's not even really possible to estimate the number of hours given the codebase. Developer productivity varies by 10x or more. That said, because as others have mentioned the Agile development cycle is short. Even if things are dragging you should be able to find changes every few weeks at the latest. But what would that get you, anyway. Proving that somebody is not working on something basically means understanding what they are working on, which clearly wasn't happening here.

It's really, really unusual for a yearlong software project not to have changes. Completely unpossible. But that's neither here nor there if the contract just says hours. Given that you have bills for many months of work, a lawyer's read of the contract is probably cheap compared to what you have to pay. They can probably help with the negotiation too. Realistically, the software house will probably be willing to settle for a portion of the contracted payment just to avoid having to sue the company and go through the trouble of collecting. Feel free to use any evidence that they were not doing the work as leverage in these negotiations.
posted by wnissen at 8:36 AM on March 16, 2014

This really sucks :-(

Did this happen in the US or in Japan? Depending on your location, breach-of-contract laws may be different...
posted by Tsukushi at 12:21 PM on March 16, 2014

Response by poster: Just to clarify in case anyone else finds this useful. I think I now know we had a bad contract. It didn't specify milestones or a one year end date. We did have a lengthy and detailed list of specifications (created by the developer after consulting with many users).

We have code on our server for testing that has passed their internal testing (if that makes sense).

We've paid out a year's worth of invoices. The remaining unpaid are December through February. So, we don't actually have much to bargain with and it looks like since we have an hourly contract a lawyer will probably tell us we have to pay them.

There have been changes over time, but we can't really tell what they were. The repository is private and they moved code over from their test server to our server early February. The code we have gives us very little functionality--nothing really useful yet. The "agile" card was not that they had to do other work for other clients (though that may have been the case) but there was stuff not understood in the specification that required other "foundational" work to be done first. Seems odd, though and not particularly "agile".

Seems they started well, slacked off in the middle, started to try to make up for lost time, and then split when asked, "What's up with these invoices and nothing that works yet, no specs met, no change orders?" *sigh*

Milestones would have prevented this millstone.

Thanks all. I think that covers everything.
posted by Gotanda at 1:42 PM on March 16, 2014 [2 favorites]

Wow, what a yucky place to be. Without actually seeing the contract, I can't comment on that part of it, but if you are going to try to salvage as much of the work as possible, it's probably worth hiring someone else to come in and evaluate the code status. They may be able to tell you whether "nothing works" is 20% done or 90% done by evaluating the specs, the code, and the test suite. Then you could hire them/someone else to finish it, if they can confidently tell you you're not throwing good money after bad. If you do that, get the new developer(s) to give you much more detailed estimates, a timeline, milestones, periodic deliverables, and *real* agile code-- which is to say, they should be rescuing the functionality feature by prioritized feature. Get someone good enough, and you should be able to have at least skeleton functionality in a couple of months, and build out from there. The *whole point* of agile development is to be able to call it quits at any given two week sprint, and still have a shippable product.
posted by instamatic at 5:32 PM on March 16, 2014 [1 favorite]

Response by poster: Thanks all, this has been really helpful.
posted by Gotanda at 7:31 PM on March 22, 2014

« Older Should our website be in both European and...   |   [Study Filter] Neck and back tension while... Newer »
This thread is closed to new comments.