1

I work as a programmer, mainly as a web developer, for a company that makes use of a niche programming language that has a bad reputation.

Basically, the developers that left the company have made

A: Undocumented Code (without even comments on the classes they have made so why something that does record searching is named JBFX instead of the intuitive SEARCH I'll never know)

B: highly coupled and static systems

  • (SQL Queries are "injected" in the application, their argument being it is the fastest way to develop without bothering with stored procedures, etc.)

  • (Instead of a server that can cater different "Sites" of the company via a field (ie. Tables that have an area column in them that would contain if records are for "Manila" or "Dubai") each site has it's own server, and thus cannot relate with each other unless their is middleware for each particular table)

C. Web applications are encouraged to be POST back in nature instead of Responsive. Since it is how they have been doing web development. I tried showing a webpage that is ASYNCHRONOUS in nature and was discriminated for it, saying that I have made things complex and that customers won't notice pages that POSTBACK. (I suspect that they are used to developing the niche language in a POSTBACK manner so much that they do not want to bother studying about async)

D. No software development plan, and default of management is that (You do this project for 3 months) without any semblance of plan. No use of AGILE or SCRUM. And result is that on time of presentation MORE requirements are added that mess up the current setup of the solution with given time for you to change things being 3-4 days only BECAUSE management deems it to be a small change)

However niche the language may be (hint) I felt it could be salvageable if we changed our development techniques. The trouble is, the developers I currently work with does not want to fix any of the existing problems, and themselves develop in this manner. They still won't document, they still will create code that isn't SOLID in nature, they still won't study how AJAX is even if it is so simple with jQUery (and I've shown them how it could be done with the said niche language.) and they show no desire to do any software development planning, discriminating on the very idea ("a good programmer must adapt" they say. I say "I will never know what it is you exactly expect of me unless you tell me what those are")

I suspect that they do not want to adapt because of the added work and effort in applying all of these, and that whatever they do works. As a result, we are stuck with a system that fails every so often (every day there is a failure) and we are called to support it.

My question is, how can I make them see the light, that these techniques aren't just added work, but will ultimately be for the better of the team? Can you change a culture this deeply rooted? or should I just ultimately leave as I feel this is a bad experience to be added in my resume (not being able to change or employ any modern development strategies, bad practice, too niche technology that should be scrapped for better ones)?

This question and this one is related, but here are differences: A. I am at a "Supervisory" level, but then again everyone else on my team is as well. It may sound silly, but it's true. I have no people under me. We have a manager above us whom I must follow.

B. I an cordial with the team, I am on good terms with any other conversation. but when it comes to matters like this, topic is often set aside / dismissed (and I find that this depresses and demotivates me every single day).

C. i haven't insulted anyone on how they code, in fact I try to praise them a bit ("wow, that's a good method you've made there") and then try to inject an advice ("what if we employ dependency injection so that this method can be used again for...") but I am mostly met with a laugh and then the subject is dismissed.

This question is also related, but I am on the opposite end of the asker. I "want" to support the ideas of this boss proposing the idea (if he were a coworker)

Improve this question
12
  • 5
    "As a result, we are stuck with a system that fails every so often" - Then propose changes that address this directly. The things you mentioned, like SOLID principles, renaming a class to "JBFX" to "SEARCH", etc. do not address reliability. AJAX addresses user experience, not reliability. AJAX might even reduce reliability if clients have a poor connection. The SQL queries might be vulnerable to SQL injection, but this should be considered a security issue, separate from what you currently describe.
    – Brandin
    Commented May 15, 2017 at 5:11
  • 3
    To add to Brandin's comment, you cna perfectly use the last technologies and still have a terrible system that have troubles everyday.
    – Walfrat
    Commented May 15, 2017 at 11:06
  • 4
    Possible duplicate of Should I propose a big change as a newcomer?
    – Fattie
    Commented Jan 8, 2019 at 17:35
  • 1
    this is the SINGLE MOST DUPLICATED question on the site.
    – Fattie
    Commented Jan 8, 2019 at 17:35
  • 2
    Eh, okay @Fattie. I think 5% is a bit much, and doesn't match my observations, but I haven't been here in a few months. Either way, marking questions as duplicate when they're not is not a good solution. Remember, a "duplicate" is when ALL answers to both questions apply well to both answers. If I can give an answer that applies only to one of the questions then it's related but NOT a duplicate. I see far too much stuff being closed because questions are roughly similar, but different in details. Details are very important for questions such as this, and can radically change the answers.
    – Martin Tournoij
    Commented Jan 9, 2019 at 1:38

4 Answers 4

Reset to default
26

I see a lot of confusion between "best practices" and "I think this is the best way to do things". An informed and reasonable person could disagree with many of the points you've raised.

Your coworkers are correct when they say that asynchronous ajax programming is hard and adds a lot of complexity. You're also correct when you say that asynchronous ajax programming can add a lot of value to a system. No one is demonstrably "wrong" here; it's just a matter of preference and priorities.

I suggest you take some more time in trying to understand why thing are as they are, because frankly the text of your question doesn't seem to show a lot of understanding of your coworkers' positions. Your coworkers may be "deeply rooted" in their way of doing things, but have you considered that you may also be "deeply rooted" in your way of doing things? There are more ways to skin a cat, and there's more than one way to develop good software.

If you want to change things then all you can do is explain what the advantages of "technique X" over "technique Y" might be. Show how it will save developer time, improve stability, or show some other concrete company advantage. Don't mentions things like "best practices", "better for the team", or even "more elegant". They're not going to convince anyone. It's important to be pragmatical; you're not creating a work of art, you're creating a tool to solve problems.

It sounds like you've already tried that and failed every time. It looks like you'll have to choose between trying more, staying and "sucking it up", or deciding you're not a good fit in this team and move on.

I suspect that they do not want to adapt because of the added work and effort in applying all of these, and that whatever they do works. As a result, we are stuck with a system that fails every so often (every day there is a failure) and we are called to support it.

That doesn't sound too good, but the more you're going to change the more failures you're going to get. There's a reason banks still run COBOL and nuclear power plants still run on PDP-11 assembly.

Improve this answer
6
  • but what if the way they do things that are "deeply rooted" directly disobey proven theories like SOLID?
    – anon
    Commented May 15, 2017 at 0:03
  • 3
    @AConcernedProgrammer "Disobey SOLID" is very vague; so that's not really something I can concretely reply to. I can say that people have been successfully writing quality software for many decades before SOLID was formulated. In addition, to the best of my knowledge SOLID isn't "proven" in the sense of "empirical evidence". It may have "proven to work well for me", but that's not the same. I agree that SOLID is a good thing, but I don't agree that every dev team that "disobeys SOLID" needs a kick in the backside to immediately start "obeying SOLID". There are more than one ways to skin a cat.
    – Martin Tournoij
    Commented May 15, 2017 at 0:14
  • 2
    Why should it @AConcernedProgrammer? Just don't badmouth your previous employer when asked why you want to leave (you could say something like "great people but different approach to development than what I'm used to" or "not fitting in the team").
    – Martin Tournoij
    Commented May 15, 2017 at 0:59
  • 5
    Great answer. I see a lot of developers these days that would love to rewrite everything to have it solid or asyc that doesn't bring any value to the product. Put dependecy injection just to inject one class instance etc. Good answer.
    – Jakub
    Commented May 16, 2017 at 5:19
  • 2
    This. If you want to change anything - especially with experienced developers - then you need to DEMONSTRATE then that your suggestion is an improvement. Unfortunately, they may also DEMONSTRATE that they already considered it and tell you why they didn't adapt it. Do your research - you only get a few tries of this before they don't want to play this game anymore.
    – Thorbjørn Ravn Andersen
    Commented Jan 8, 2019 at 15:26
3

I'll try to address each practice that you mention:

A) Yes this is a bad practice but it is also an unfortunately common one. Not worth leaving your job over

B) There might be legitimate reasons for this design. While there may be an argument regarding SQL injection, that point is basically moot if the web dev team have done their basic homework and is properly filtering any command it comes up against.

I can certainly see why they might have different servers for different countries, as, for one potential reason, different countries have different IT laws, many of which conflict with each other and it may be damn near impossible (or incredibly complicated) for one unified server to be compliant with all of them.

C) Is your way of doing things an improvement or just another way of doing things? What is actually wrong with what they are doing?

D) What makes you so sure that there is no plan or methodology in place? AGILE and SCRUM are not the be all and end all of software development processes. And while I understand that some execs will try to put harsh time limits on a new feature that they think is lenient, it is up to you as the expert to point out the difficulties and that you might need more time. Unless your execs have personal programming experience, you will come across this a lot in any workplace.

Now don't get me wrong, there may or may not be some objective benefit to your ways. I do not know, as I am a solo programming hobbyist and not a professional. And people who aren't really aware of your ways of doing things may not know the benefits that they bring. Conversely, there may be people who DO know of your ways of doing things but are also aware of drawbacks that you are not aware of.

Lastly, switching the fundamental workings of a program from one way to another is almost always seriously hard work. This likely goes double for professional work as it means potentially introducing new bugs and both programmers and testers working overtime. You need a seriously good business case (eg: performance on either client or server is seriously and very noticeably improved, enables the company to develop a strong Unique Selling Point, you get the idea) to justify it

Improve this answer
2

a company that makes use of a niche programming language

From here I see a problem you repeat this word often it seems you're not comfortable with the stack you work with, if this tech is not of your liking plus practices you do not like it will be a really bad or tiresome experience and I suggest to find a job with your desired tech. What you said about SQL injections is really bad practice all logic should be added into stored procedures as much as it can this applies to any stack.

The rest of your question also sounds like you master this technology is this so? if yes then it's pointless to work with technology you already master when moving to a new job I believe learning is more important that seeking a higher pay

My question is, how can I make them see the light

You can't there is a reason why they do it this way and it costs money to delay delivers and it's a bad idea to attempt to push your practices into them even if you were lead or pm it would be a painful experience for all, when working with a new team you're the one that needs to adapt to the team and to your manager

Here is how I see things:
- If you master the technology then it's a posible dead end job you should then be in a comfortable workplace with practices you enjoy
- If your new job uses tech you want to learn that will allow you to get higher pay then I believe it's ok to sacrifice a little such as bad practices, outdated models or any disfunction that might happen, I personally would even accept less pay if they work with tech I want to learn

Improve this answer
2

I do have to concur that a lot of people in the software industry are confusing "best practices" with absolute programming. Best practice is a primer but if your team agrees with what is in place now, then that is good enough. If you're new to the organization, they'll see your suggestions as unneeded especially if you need help "navigating" the code. You'll just be seen as hard to work with.

Just showing that pages work the way it is with "best practice" but no added benefit except a lot of work will be seen as unneeded. Imagine if you called a painter and he said your wall is hard to work with but he shows you a piece of plywood he bought from homedepot and how easy it is to paint with. Would you agree to let the painter tear down your entire walls to put a fresh paint of coat when you know someone else can work with the wall you currrently have?

You'll have to remember it's:

  1. It's currently working.
  2. Going with current industry "best practice" is going to take time to upgrade legacy code with.
  3. You're not able to work on your own yet. You might not understand their code so you're assuming they need to have best practices just to get easier for you to work on. Learning how to work with legacy code or code in place are a huge plus and a skill hard to come by with on fresh grads.
Improve this answer

You must log in to answer this question.