By getefix on

I've been working with Russian contractors to implement an in-house beta of a collaborative-filtering website with wiki-style content using Drupal. The contractors are fighting against Drupal so hard that I'm remembering scenes from the movie Red Dawn and getting a warm, fuzzy feeling (and it's not from the Swayz). I chose Drupal because even though we're sure of our core service we're not entirely sure how people will best like to use that core service, so we need a highly modifiable and extensible solution to do "proof of concept". We also need a very high degree of communication with users and a way to allow user-modification of content to a limited degree, so it would seem to me that Drupal is our ideal solution. However, the Russians have been screaming and ranting about Drupal so loudly that my boss is expressing doubts about the competence of my decision. Mainly the Russians complain that Drupal does not have good structure and that module creation is not elegant and requires significant "busy work" -- they want to code the entire beta from scratch using CakePHP as a framework.

I was wondering if people could share their stories of convincing their boss about using Drupal. I've got a board meeting coming up this Friday where I'm going to be forced to publicly defend my backing of Drupal for our project.

Thanks in Advance,
Stephen Christian

⋅ Categories: Drupal 5.x

Comments

yelvington’s picture

yelvington commented

"In Soviet Russia, contractors manage YOU!"

Seriously, though ... is it not obvious that it's in the economic interests of the contractors to develop a bespoke application that will tie you to continued contracting engagements for support, security fixes, and modifications?

If a programmer adheres to Drupal coding standards, uses the API and practices just a little bit of documentation discipline, the result is a system that any Drupal-competent programmer can maintain and enhance.

We've all been through this, and it's documented as the road to Drupal hell: Refuse to use the API, refuse to learn how the hook system works, refuse to learn the forms system, et cetera, et cetera. I was discussing this with one of our managers yesterday: it seems that every programmer has to make the same mistakes and learn the hard way before converting to the Drupal Way.

I've been struggling with situations like this for 14 years now. The same issues continually crop up in ANY decisions about framework and platform, not just Drupal:

* Implementors can't understand that platform decisions are part of the business requirements process and not their private domain.
* Implementors confuse arbitrary personal preferences with technical merit. (This is why the first thing a new sysadmin wants to do is rejigger the filesystem layout. The project does not exist to make implementors happy. Get over it.)
* Implementors disguise personal agendas (X will look good on my resume, Y will keep me employed over a longer term) as technical requirements.

getefix’s picture

getefix commented

Thank you for your quick and excellent response. The "economic interests" argument was the first thing that came to mind, and I explained it to my boss. The problem is that his buddy runs the company that controls the contractors and he doesn't want to believe his buddy would work him over like that. The "economic interests" argument seems most valid to my mind, but because of the buddy issue I have to scramble to come up with other reasons. The ones you gave me at the end of your post will help me immensely. Thank you again.

jscoble’s picture

jscoble commented

I see your in a tough spot that will take all of your diplomacy skills but the economic interests of the contractors sounds like the correct answer. Also your boss's buddy may not do that to him, but does that also mean that the contractors would go against their own economic interests? After all, what the contractors are saying may seem reasonable to your boss's buddy so it may not seem like anything unseemly is happening. You said your boss's buddy runs the company that controls the contractors. That means his company hired the contractors? Or does that mean his company is the contracting company and the contractors are his employees? There is a difference when economic interests come into play.

Contractors writing code have a built in incentive to reinvent the wheel, when it breaks or you need a better wheel, you will naturally come to them. I have even known contractors that intentionally obfuscate the code, make it overly complex, and maybe even introduce bugs so that you have to come back to them. Just as some web designers will make text into graphics with intentional misspellings.

Oops, thanks for noticing that error, it will cost you $n to fix it.

I'm not saying everyone does it, but in the ISV world, contract programmers have a pretty poor reputation in general. They are usually getting paid by the hour and not by the product.

The other reason is that a lot of people really hate having to do something in a manner that is unfamiliar and a lot of programmers instincts are to program their way out of the problem in a manner that is familiar to them. Remember it will take programmers some time to grok programming against unfamiliar software apis. How much depends on their familiarity with the language(s) involved and how much of a paradigm shit is involved. There have been many times I have muttered to myself that writing a CMS would have been easier. But then I remember that I will need something more than login, registration forms, shopping cart and basic publishing. I also remember that I will want it to be robust and scalable. That's when it gets to be a slippery slope and I remember why I'm using Drupal and other open source projects.

Write down your initial reasoning for choosing Drupal. Write down your proof of concept requirements. Compare the two, how do they match up? Is it defensible? Is it marketable to the stakeholders? What about the post proof-of-concept stage?

Has Ivan given a cost estimate for writing the proof of concept? What about for production ready deliverables? When coding for a proof of concept you don't need nearly as much as coding for production ready. Make them explain what that significant busy work is and exactly what the poor structure is. Make sure you understand how to create a module. Knowing how in relation to one of the modules that they are creating would be even more helpful.

However, you should also take into consideration that they may be right and look at the arguments from their side so that you can make an accurate assessment and better defend your decision when the Russians start their attack on your decision. Being right for the meeting doesn't mean a thing if you are ultimately proven wrong later. It will actually be worse.

Some pre-meeting talks with the contractors to see if you can help address the cause of their revolt may also help your cause, if that's possible.

getefix’s picture

getefix commented

After all the work I did up-armoring my arguments and researching Drupal scalability the board heard that it would be faster to achieve a solution with Drupal and said "Great, do it! Now go away." The cleaner will no doubt be puzzled by the teeth marks on my wooden desk.

jscoble’s picture

jscoble commented

That's good the hear and sounds like a pretty good board to deal with; they trusted the expert that they hired to decide these things for the organization, you, and your decision, and let you focus on the important tasks at hand.

keith.smith’s picture

keith.smith commented

What I would do is analyze the needs of your site and then determine, as best you can, whether Drupal or CakePHP has more features "built in" that will support your needs.

If "busy work" is cut and pasting menu definitions and FAPI elements in Drupal modules, then sure, I guess Drupal module development involves some busy work.

I would define "busy work", though, with how much I had to re-invent the wheel. I assume that CakePHP already handles user authentication, session management, logging, etc., for you, as will Drupal. What features does Drupal have, though, that CakePHP does not, that will be needed on your site? You mention collaborative development and wiki, for instance. Wouldn't you have to "busy-work" reinvent much of that functionality in CakePHP where you might find a contrib module in Drupal that did some or most of what you want?

Bear in mind that I know close to nothing about CakePHP.

--keith