17

I'm going to be developing an Intranet site for my specific plant, and our company standard for web-development is IIS + ASP.Net + VB.Net + Microsoft SQL Server (note that we have about 10+ plants). The Intranet site will only be used by my plant, and I'm the only one who will support it. I'm much more proficient with a LAMP setup, and I could do development and problem solving much more rapidly with PHP than I could ASP.Net. Even though the company "standard" is ASP.Net/VB.Net, most of what the company does as a whole is to purchase third party software (which is usually Java based), and very, and I do mean very few people in the company even know VB6, let alone ASP.Net/VB.Net.

That being said, is it better to violate the company standard and go with the setup that I can support better, or is it better to go with the setup that the company can support better if I ever were to leave, even though no one currently in the company can support their own standard anyway?

Some additional factors to consider in my personal case:

  • Again, this is only for my plant, and I'm the only one who will ever be supporting it unless I leave the company, and then my replacement would be supporting it. Not someone else already in the company.
  • The company does very little development with their standard anyway.
  • Hardly any of the companies existing software uses their standard.
  • If I choose the company standard, then I have to use the Express version of Microsoft SQL and a Windows 7 OS. From my readings, the Express version is okay for business use, but the database size is limited.
Drew Chapin
  • 355

7 Answers7

37

Again, this is only for my plant, and I'm the only one who will ever be supporting it unless I leave the company, and then my replacement would be supporting it. Not someone else already in the company.

1 -- Don't Assume you're the only one who's going to support this. You do like your sick time and vacation, right? What if you need to take extended maternity/paternity leave or something? Who's going to support your app then? Also, what if you'd like to talk to someone about technical problems specific to your company? What if you'd like to have code reviews? Or need help with a tricky bug? In all these cases it helps to be amongst others with insight into the technology you're using -- specifically how it can be applied to solve your company's specific problems.

The company does very little development with their standard anyway.

2 -- Just because some document exists doesn't mean its really the standard or means anything. It may simply mean that there's a group of politically influential individuals advocating this approach, and it may turn out there's other sub groups taking different approaches.

Your problem may simply be that the "standard" has evolved to some de-facto, undocumented state that conflicts with the documented "standard". Or there may be many little unofficial groupings of people using different "standards" -- with one of those groups managing to make their "standard" made official. You probably need to ask around to figure out what others in your group -- who might also support you and your app -- consider best practices. Ask what they feel comfortable with you using. Map out the real technology landscape of your company and figure out where the know how is. Just like any good piece of evolving tribal knowledge the only way you're going to know how to proceed is to talk to people.

3 -- Don't pass up professional opportunities to learn new things. You have to guard against being pigeonholed in this industry. Be nimble. You may have an opportunity to gain some breadth and learn a new way to solve a problem. Not to mention you're gaining new skills for your resume. It can mostly only help you to have to step outside your comfort zone to do something new. That being said, if the different/new thing is so extremely niche that you don't think you or any future employers will get any value from those skills, then maybe this isn't such a great opportunity. But getting a chance to be both an ASP.net and LAMP expert will certainly open your eyes and can only help your career. There's nothing like a real project with a deadline to force you to really learn something.

So my advice, don't go it alone. Figure out where people really stand and decide where you can best fit in. If you need to step out of your comfort zone, use this as an opportunity to grow professionally.

Doug T.
  • 11,737
9

That being said, is it better to violate the company standard and go with the setup that I can support better, or is it better to go with the setup that the company can support better if I ever were to leave, even though no one currently in the company can support their own standard anyway?

It is a management decision. Make them know your concerns and insist formally on changing.

That said, a language is a tool and you must choose the right tool for a job; make them understand that you don't screw a screw with a hammer.

Fabián Heredia Montiel
  • 294
8

Do you have any aspirations for promotion, or working on other projects? If so, I suggest that "doing your own thing" will have two negative effects almost certainly resulting in (paraphrase) "I will be the one supporting it, until I leave"

  1. Because you chose not to follow the company standards shows you are not particularly suitable for more senior roles, as you are unable to follow simple instructions.
  2. Because you chose not to follow the company standard, it will be your problem that no one else in the company can support your code.

If you choose to use the standard, it will not be your responsibility to continue to maintain the product when (if) an opportunity for promotion or another project arises.

The other way to look at a ludicrous analogy. I move to a country where they drive on the left, however, I am much more used to driving on the right, I prefer to drive on the right, because of this, I am better at it and can drive faster. Should I drive on the right?

abatishchev
  • 111
mattnz
  • 21,490
5

Companies have standards for a reason, if there is a formally stated standard that says to use x, then youu need to justify y.

This doesn't mean that you can't use y, it does mean that you should understand the reasoning behind the standard and and get approval before violating it.

Perhaps after you understand why, you'll no longer want to violate it, perhaps you'll see that it needs to be changed or scrapped, or that it doesn't apply in this instance so that using y isn't a problem.

If it applies, then unless you can get it changed, you should follow it. Company standards aren't quite on the same level as direct orders, but your employer has a reasonable expectation of you following both unless they violate the law.

jmoreno
  • 11,238
2

It all depends on whether you are going to get fired or not. If you are going to get fired, don't do it. If you are not going to get fired, then by all means go ahead with it.

Mike Nakis
  • 32,803
1

I think that you can anticipate many of the problems that could arise from this and make a detailed plan for if and when you ever had to leave the company.

One problem that could gum up the works would be if you left and HR had to search for your replacement. Given they either actively try to understand what you did and hire according to the skills needed -or- simply look at the original document that spec'd out the policy of IIS/ASP.NET/etc. and blindly hire someone with those skills to maintain your LAMP code (on the "because it says so" principle), I think the latter is much more likely.

The easiest thing (in the long run) is to do what fabianhjr recommended and change the standard. Change it to include both Microsoft and LAMP if they are resistant to a full switch.

jonsca
  • 585
1

In this case you need to follow the standard. If the standard doesn't seem to apply, you need to talk to your manager about doing it in a different language.

Of all the standards to follow in development, I personally feel that language choice is the most important. Ignoring the standard language choice in favor of one you are more comfortable with leaves co-workers and/or successors up a creek without a paddle, because they may not have the skills to work on your project. A company's hiring decisions are based on language choice so decisions like these can have a major impact. Introducing yet another platform/language may force the company into a tight spot when they start hiring other people.

Beyond the language you have to consider internal support for the LAMP server. Who is going to administer Apache? How about MySQL? Does the company's software run on a different database? Will the administrators be willing to administer a new platform. Even if you plan on administering these services, the duties could eventually fall on somebody else. If you plan on administering the services, will the network/server admins allow you to do so?

The ramifications of introducing a different platform can be wide and deep. Not following the standard may end up affecting many people besides yourself. Even though you are more proficient in LAMP than ASP.NET, building on that platform could end up costing your company much more in the long run. Key here is communicating with your manager and understanding the effects of the final decision.

Mike Cellini
  • 1,875