Page 1 of 2
Too many "rock paper scissor" "deadlocks"
Posted: Mon Dec 28, 2009 4:37 pm
by josh
On a project I am working on I keep running into deadlocks, someone asks me to code a feature adding some enhancement to their store's products for instance. So I do it, since I didn't write the store software, and am only offering a "plugin"... parts of my system are bound to depend on parts of their software.
Well it turned out after I developed this feature, the thing I "depended on" doesn't work with that web store's import. So now we have to back track and depend on some other equivalent feature that does work on the import, but was worse suited to doing what we needed to do with it.
So basically we ran into a rock paper scissors problem. Client asks for feature, I depend on Company's feature, Company then says feature won't work client's import.
Can't blame the client, he just wanted the functionality I offer, and doesn't care about Company
Can't blame the company (although they "should" have made their system more orthogonal), but they didn't know what I or the client intended to do with it
Can't blame me, client said the feature we were going to depend on was fine
So what do you do to prevent these kinds of issues? The system I am extending is complex and would be time consuming to duplicate, but when I keep running into these types of issues it is costly too. I was planning to make a stripped down version of my plugin and incrementally start supporting other web store software, but the one I am using now has the most market share.
So I am thinking something along the lines of a contract template for custom development clients to sign, that will transfer responsibility of research and specifications to their end? Do you think that would be a good approach? This is a more of a product business than a service business, so if they want the full blown "custom" experience they should go somewhere else, for now...
Re: Too many "rock paper scissor" "deadlocks"
Posted: Tue Dec 29, 2009 2:36 am
by greyhoundcode
I suppose it comes down to whether they properly understand your problem.
Re: Too many "rock paper scissor" "deadlocks"
Posted: Tue Dec 29, 2009 4:03 am
by omniuni
Find a CMS you can better work with, or write your own. I did, and my clients know exactly what they're getting, and I know exactly what I can do with it!
Re: Too many "rock paper scissor" "deadlocks"
Posted: Tue Dec 29, 2009 1:39 pm
by Christopher
I think this points up a larger issue of what happens when an unexpected problem occurs -- even after you and the client have done due diligence in investigating the work required in a contract. It seems like some combination of specifying the expected work and contract language to say what happens when there is excessive unexpected work.
Re: Too many "rock paper scissor" "deadlocks"
Posted: Tue Dec 29, 2009 7:46 pm
by josh
Yeah I told the client I got it working but they're going to have to pay $x amount ( I discounted my rate a bit and multiplied by the # of hours that I thought were excessive).
I would like to make a Magento equivalent, but I have prior commitments to finish an equally large system for a client.
Re: Too many "rock paper scissor" "deadlocks"
Posted: Thu Dec 31, 2009 1:44 am
by alex.barylski
So I am thinking something along the lines of a contract template for custom development clients to sign, that will transfer responsibility of research and specifications to their end? Do you think that would be a good approach?
What system are you extending just curious, obviously not Magento as you just said above.
How well is this product supported? Do they offer commercial support? You could inform clients that fully integrating your solution "might" require feedback from product X support team and thus they will be billed for X hours consulating. Get company to sign off on a approach and then you have someone to blame when s**t hits the fan.
Cheers,
Alex
Re: Too many "rock paper scissor" "deadlocks"
Posted: Thu Dec 31, 2009 7:09 am
by josh
No, it is Magento. The problem was Magento had attributes as well as custom options. Both are used to make a "configurable" product but attributes are shared by many products, custom options are like duplicated attributes but do the same thing.
Neither is supported by Magento when importing your products. However a hack existed for custom options only. I had written a whole mechanism that traversed the DOM looking for the id of the attribute. If custom options were to be used all that jquery had to be changed, and a bunch of magento "layout XML". A seemingly trivial change but the difference was custom options' ids are going to be unique, so in order to hook into any dropdown that was labelled "paintable" I had to traverse the DOM reading the <label> tag looking for which select boxes should be modified, Before the user simply choose which attribute ID is being used for the "paintable" drop down. Now it was like gymnastics to find those drop-downs.
The problem is when you make one XML change and suddenly get unexpected results, where do you even start when there are 5,000 lines of XML in the system, and another 5,000 lines of PHP code used just to parse & merge that XML
One useful tool is Alan Storm's module,
http://stackoverflow.com/questions/1087 ... ml-problem
In this case using Alan's module I saw the XML was being parsed & was present but was not rendering the block to my page, took me ~5hrs just for the .xml change, and an hour for the jquery change, and another few hours to polish it all = more than 1 full days work. Turns out my XML was wrapped in a "reference" tag that referenced a non existent block because I thought another "handle" was being loaded
http://www.magentocommerce.com/design_g ... to-layouts
I think this is just a contract ammendment thing for whenever I offer to add extra features to my extension, I need them to sign off. Just not sure how to even go about wording that.
PS> will not give Magento a dime

I try over and over to contribute code to the project but they censor my blog comments because I ask if we are allowed to refactor the 1,000 line conditional in the view script. I guess they feel embarrassed and don't want to deal with me on a serious level, so I try not to bump heads with them at all
As you can see this pesky XML architecture is the main issue here. Wasn't this the problem with the original SPRING framework? What did those programmers do? I even have been having to write patches for this code
http://joshribakoff.com/?p=81
But it would be even worse to try to take something like os commerce and port my extension to that. At least Magento uses MVC and objects. And forking or rewriting Magento is likely a year long project (which I will do some day, but I must be pragmatic and run my existing businesses too, or I wont be able to pay the bills long enough to complete said rewrite...)
Re: Too many "rock paper scissor" "deadlocks"
Posted: Thu Dec 31, 2009 9:29 am
by Weirdan
josh wrote:PS> will not give Magento a dime

I try over and over to contribute code to the project but they censor my blog comments because I ask if we are allowed to refactor the 1,000 line conditional in the view script. I guess they feel embarrassed and don't want to deal with me on a serious level, so I try not to bump heads with them at all
From what I read on the net (and knowing one Magento developer personally) I reckon Magento is an open source product, not project. Meaning you get the source code, but it's almost impossible to get your patches accepted back into project (unless you work for Varien, of course).
Re: Too many "rock paper scissor" "deadlocks"
Posted: Thu Dec 31, 2009 5:30 pm
by josh
Yep thats exactly correct. They ignore perfectly good patches so they can make more for paid support. That is how a lot of the end users are feeling right now.
Re: Too many "rock paper scissor" "deadlocks"
Posted: Tue Jan 05, 2010 10:17 pm
by Charles256
Hey Josh. When it comes to dealing with something like this I normally would tell clients that I'd have to research it first before giving them a quote if that's an option in your case. I imagine you spotted the problem almost immediately. Your best bet is probably to just always do this whenever any modification is requested to any outside system regardless of whether or not their documentation says their good to go. Hope that provides some insight, if not let us know what you eventually come up with and how it turns out.
Re: Too many "rock paper scissor" "deadlocks"
Posted: Wed Jan 06, 2010 12:17 pm
by omniuni
I'd actually say Charles is very right. If you don't have 100% control over the system (Like having built it from the ground up) it's always best to give yourself some time to research and be sure before promising anything.
Re: Too many "rock paper scissor" "deadlocks"
Posted: Wed Jan 06, 2010 3:53 pm
by josh
Hey Charles! good to hear from you, been a long time..
You mean you would research it initially? Or research it when they came back and asked to "make it work with the import"?? Because I don't see how I could have researched it initially (it could just as well have been some other feature they expected me to integrate with and neglected to specify)
Re: Too many "rock paper scissor" "deadlocks"
Posted: Wed Jan 06, 2010 4:39 pm
by omniuni
Well, that makes it rather easy! If they didn't specify it, you simply say, "Well, you didn't specify that. Let me research it, and get back to you."
Re: Too many "rock paper scissor" "deadlocks"
Posted: Wed Jan 06, 2010 6:23 pm
by Christopher
Yes, but the question really was: who is responsible for the unforeseen? Typically a client was expect a quote to be inclusive unless there is some language about contingencies.
Re: Too many "rock paper scissor" "deadlocks"
Posted: Wed Jan 06, 2010 7:31 pm
by omniuni
arborint, some clients just don't even think about stuff like that. Somehow they just expect that initial quote to mean the whole project even with unforeseen complications.