Iyfjky

Question

I work with really old technology which takes ages to create websites. The security is also bad (tons of vulnerabilities such as XSS, CSRF...).

How do I change to a better situation? The guy who makes the decision in IT does not want to listen. He is proud of what he did; he made those websites.

The site is actually base on a big system that our boss want to sell to others developers (not in house) which will be terrible for that company since it's not coding well. I personaly don't care, but since the boss is a good guy and has no idea what's going on behind the scene, I feel bad. It took them 3 years to make this system. In my previous company, we did the exact same thing within 4 months using the latest technologies. I already suggest to use "new cool stuff" and fix security issues, but I just got ignored because I'm the "new guy" here.

EDIT

Thanks a lot guys for your answers. It a lot more clear now and helped me a lot.
@jmac, for answer to your really interesting topic :

Understand the current system :
I already spent over 8 months working with it. The thing is, this project (as all the other projects we are doing) have no plans or structure at all. When we start a new project, we basically receive an email saying "Make this project please". We don't have any project manager (that is also a part of the problem). On my hand, I'm trying to get the maximum of information and plan before start to code. The other guy (the developer who takes the decision), let's call him X, jump on the code right away without even thinking how he gonna do it. That's why the current system sucks. It's basically a website, but since this website get a lot of visitors, they simply thought "Oh this thing is great, let's turn it into a big engine we can resuse and sale".

Don't criticize/condemn/complain : Here again, I didn't say at all "It sucks..." for the same reasons you mentionned. I know being negative can for sure push poeple to be negative as well. First time, I wanted to give X some suggestions about the UI/UX on the website and I told him over an email (there's no real communication here, we talk through a chat or email) : "Hey, I may have some UI/UX suggestions that I think could be great in order to give our visitors a better navigation on our website". X simply ignored me. He didn't even answer.

Build trust : That's the part I don't really have now. I'm new, yeah, but I also need to work with this messy "engine". They already told me, that they want to keep me because they are satisfied of what I did so far. The thing is, the only time, I was asked to create a new website from scratch on my own, they again told me : "You have to use this X and Z tools". In all my previous work in the past, one of the main aspect for any projects was productivity. So I was use to work with productive tool. I'm frustrated to have to write 100 lines of code with the current tool, when I can write the same thing using 30 lines with another tool. I also already show them this gain of productivity, but again, I was ignored.

Clearly outline the benefits of any change : Thanks for this point as I'm gonna work on that to explain all my arguments.

Have you considered that there might be a downside to your suggestions? If not, then think a bit about if I tried to talk you into writing all your scripts in Common Lisp. — Jun 10 '13 at 11:42
Your edit made the question worse not better. Your edit should provide a clearer question not respond to existing answers. — Jun 10 '13 at 16:35
"The thing is, this project (as all the other projects we are doing) have no plans or structure at all." Switching to modern frameworks does not change this; you'll create the same bad products with a newer tech stack. — Jan 16 at 15:45

jmac 19.4k763137 · Answer 1 · 2013-06-10 00:13:37Z

Executive Summary

When making suggestions, especially in a new job, you need to make sure you follow these simple guidelines:

Understand the current system

Don't criticize/condemn/complain

Build trust

Clearly outline the benefits of any change

Be prepared to compromise

If you do not do these things, your suggestions will likely be shot down outright.

Understand the current system

So it has taken them 3 years to develop this system. There are specific development decisions they made, and specific development challenges they overcame in those three years. This is invaluable. Before getting excited about what other technologies could do, be sure you understand what the current system can do. That will make your opinion more valuable because it is an opinion made with understanding of what the current situation is (both good and bad).

Don't criticize/condemn/complain

So you understand the current system and all the issues with it. Don't focus on the issues. If you come to the person who developed the system with a list of reasons it sucks, you will only serve to make him defensive and fight harder to protect the thing he created.

Suggestions should be brought up as positive improvements that sounds more like "wouldn't it be cool if..." rather than complaints, "this sucks because...". Negativity breeds negativity, so rather than people viewing your suggestion as a better way of doing things, they may view it as a less worse way of doing things. And that isn't a very compelling sales-point.

Build trust

Especially if you are new, the people in the company may not trust you yet. If you want to propose large sweeping changes you have to make sure that people in your company actually trust you first. The easiest way to build trust is to do a good job (do what you're told on time, with minimum of complaints, and exceed expectations). Once people start seeing that you're good at getting things done, they will be far more likely to listen to suggestions you have to make.

Clearly outline the benefits of any change

Ultimately, someone in management is going to make the decision. In order to help them make that decision, you have to put together information on why your suggestion is the best option. That means clearly listing out the benefits with clear examples of how it will impact the business if they don't change.

For instance:

Prevent XSS

There were 200 XSS attacks on the site last year, which have the potential to steal customer information

Prevent CSRF

Malicious coders could use our site to cause customers to buy subscriptions for other people without their knowledge. Last year we spent $Y on refunds to customers which this vulnerability could be partially responsible for.

Reduce Development Time

Currently we spend X hours/week doing web development for the site. By using tools A, B, and C we can reduce that by 20 man-hours per week, giving more time to work on projects D, E, and F increasing business by $Y.

This will allow management to look at why the site should be changed, and what the consequence of each issue is.

Be prepared to compromise

So let's say you present all the above to management, and management says, "CSRF isn't really a big issue because of X, Y, and Z. But we do need to fix XSS because of the importance of customer information. What's the best way to fix just the XSS vulnerability?"

Your job is not to sell them on the same system, you need to be willing to compromise to fix the problems rather than just pushing to use different technology. Focus on meeting the needs of the business in the best way, rather than the way you want it to be done. After all, you're not currently the decision-maker on this project, and if you want to be given responsibility to decide you need to first show that you can respect the decisions of people who have that authority now.

Business is People

From what I've seen on this site, many developers tend to lose sight of the fact that business is people. No matter how fancy the technology is you want them to use, no matter how objectively good you think it will be for their business, if you can't convince the people making that decision it won't matter at all.

Understand that people have feelings, and that means that coming in and telling folks, "Yeah, you guys are horrible at your job" won't win you any friends.

Communityâ™¦ 1 · Answer 2 · 2017-04-12 07:31:57Z

EDIT, reflecting on more info added the question:

IUC the boss, who is a "good guy" is not the same as the one unwilling to listen and responsible for the overall mess. Did you sit down with the boss, explaining him the problems you discovered? Pointing out that if he goes ahead with sale, he could be easily burned for bad delivery, maybe even attempted fraud? That if they turn out not very happy (for whatever unrelated reason), it would be not hard to find a lawyer who can convince the jury that XSS and other things are considered against "good industry practice". With all kinds of consequences sensible people would like to dodge.

If he's hooked you can even drop in the other part about aged technology and suboptimal progress.

If your boss also refuses to listen, guess you can wash your hands as one tried to turn all the stones. Or maybe he orders a shootout between you and the creator. Where you have good chance to prove your right, if you actually have it. Possibly resulting in switch of positions. And your gaining the task to clean up all the mess. Consider alternatives if you don't like that either...

One way of the golden smile

-- previous answer

It's probably a trick question, but I take it literally: if you're not happy with what happen in your job, leave, and find or found one that aligns with your ways. I'd suggest doing it ASAP, as my experience shows broken things do not repair.

More accurately, if you see the vector of how company, environment, etc moves, it's pretty save bet it will not change overnight in drastic ways. (And if it points negative, the drastic way will likely mean bankruptcy...)

EDIT:
For all those who sit one-sided in the 'irreversible move' camp: staying and wasting more of your time is exactly as irreversible in nature. And not accepting "my experience" on good faith without any proof to foul play is less than nice too. What I write is backed up by 30 years of experience in our industry. It includes several years of fighting exactly these kinds of guys who have good position and no motivation to listen, especially as that would lead to being exposed as one responsible for ton of security foulups and other bad things.

If this site is about pushing for false hope rather than facing the ugly truth in real world, just say so, I'm happy to leave it to you.

Here you can read some on my past, noticing like 6 years wasted for no good reasons like fear and false hopes for improvement. I never get those back do I?

-1 The OP obviously knew these technologies were in place when he/she took the job. This doesn't seem like a sufficient reason to leave even if it can't be changed. — user8365, Jun 9 '13 at 17:47
guess in that case you should -1 the question not the answer for lack of telepathy — Jun 9 '13 at 17:52
Just telling someone to quit as an accpetable answer has been reviewd quite a bit on this site: meta.workplace.stackexchange.com/questions/1692/â€¦ — user8365, Jun 9 '13 at 17:57
@JeffO: though reading it I disagree with your position and action. OP precluded the only way of resolution. What remains is really just the subjective choice. — Jun 9 '13 at 18:11
@jmort253: I didn't think for a moment that there's anything about me. It's about the truth and real help. I agree it's way too easy to give any kind of advice, including bad one, even with best intentions. And the link above has good conversation of pros&cons, with most up answer acknowledging it may be the correct answer. In any case those using advice are responsible to evaluate it carefully. My original answer did not match the form in the problem statement. — Jun 9 '13 at 18:54

user8365 · Answer 3 · 2013-06-09 17:54:57Z

I don't think you have thought through what is involved in recreating this entire website in another stack. Proud of it or not, rewrites cost a lot of time and money. The project lead is still responsible for the site's functioning, so worse case scenerio, he has to know how to fix the site. Just because you don't like the existing code base isn't good enough. Will it take additional amounts to time to make corrections or add inhancements? Start doing some more research to make your point.

Security would be a good place to start. Look for previous breeches or attempts. Depending on the nature of the website, there may be some standards on what strength of security is needed.

Review the current list of bugs and feature requests. You could do a proof of concept in another stack to show how much easier making some of the changes would be. Maybe there is a chance to use a different stack from the one you're using on a completely new section of the website.

Were you given any indication this job would allow you to explore new technologies? Didn't you know what you were getting into? Seems like you should have asked about this during the interview process.

You ignored the essential part with "The guy who makes the decision in IT does not want to listen. He is proud of what he did; he made those websites.". Would be -1 if I were not involved. — Jun 9 '13 at 18:13
Thank you. Let me explain a little bit. The site is actually base on a big system that our boss want to sell to others developers (not in house) which will be terrible for that company since it's not coding well. I personnaly don't care, but since the boss is a good guy and has no idea what's going on behind the scene, I feel bad. It took them 3 years to made this system. In my previous company we did the exact same thing within 4 months using the latest technologies. I already suggest to use "new cool stuff" and fix security issues, but I just got ignored because I'm the "new guy" here — Jun 9 '13 at 20:44
@user1965817 - and if you keep hoping from job to job, you're always going to be the new guy and not have as much influence. Unfortunately, a lot of software becomes marketable dispite the poor design and not using the latest and greatest. — user8365, Jun 10 '13 at 15:53
@BalogPal - I'm not sure you can define someone as "not willing to listen" just because they don't want to rewrite an entire application. It can take time to gain credibility in a new job. Few people are going to build new software with COBOL, but to suggest all apps written in COBOL should be replaced is not econimically and to a certain extent technically sound advice. — user8365, Jun 10 '13 at 15:55

bethlakshmi 70.4k4136277 · Answer 4 · 2013-06-10 14:22:02Z

Love jmac's answer and upvoted, but wanted to leave more than a comment will allow...

Based on the update...

Baby Steps

A project with a serious technology lag in multiple areas can't necessarily address everything all at once. "Burn it down and start again" will seem terrifying given that it took so long to build in the first place. It doesn't really matter that you know it can be done in 3 months, the group perception is that this functionality takes 2 years. And no one ever really wants to call their own baby ugly. :)

Instead, figure a path of least resistance. What's a good first, small change? What could it led to. Don't worry about a 20 step roadmap, find the first 1-3 baby steps. It could be a prototype, it could be coding a single feature in the new way. It could be a first techology replacement - it largely depends on what work needs doing and how the team does the work.

Sell these baby steps, instead of trying to fix the whole thing. You may very well tip a move to a change.

Support the needs of the team

Make sure that the human developer end is supported. New technologies mean new information, new ways of working and a learning curve. Make sure that everyone has the resources they need - a repository to links of helpful information, instructions for changing any processes. Figure that if you do get the trust of the head decision maker, that he'll need special attention to get a chance to learn the impact of this new decision.

Know the market

Know your customer market. While it can be true that ancient technology and horrible design practices won't sell in the majority of market places, there can be cases where it will sell. So before you say "this is horrendous, we'll loose customers over it" - know your customers. Know what their needs are and what their developers will expect.

One of the hardest things to know when you are new to a company is the real business model and the keys to its success. Bosses (in a good case) get promoted because they have become smart at this aspect of the work. I'm not saying you're not right - you may very well be correct. But in big projects, I've seen some astonishing cases of old technology being a must-have for particularly risk-averse customers.

jmac 19.4k763137 · Answer 5 · 2013-06-10 00:13:37Z

Executive Summary

When making suggestions, especially in a new job, you need to make sure you follow these simple guidelines:

Understand the current system

Don't criticize/condemn/complain

Build trust

Clearly outline the benefits of any change

Be prepared to compromise

If you do not do these things, your suggestions will likely be shot down outright.

Understand the current system

So it has taken them 3 years to develop this system. There are specific development decisions they made, and specific development challenges they overcame in those three years. This is invaluable. Before getting excited about what other technologies could do, be sure you understand what the current system can do. That will make your opinion more valuable because it is an opinion made with understanding of what the current situation is (both good and bad).

Don't criticize/condemn/complain

So you understand the current system and all the issues with it. Don't focus on the issues. If you come to the person who developed the system with a list of reasons it sucks, you will only serve to make him defensive and fight harder to protect the thing he created.

Suggestions should be brought up as positive improvements that sounds more like "wouldn't it be cool if..." rather than complaints, "this sucks because...". Negativity breeds negativity, so rather than people viewing your suggestion as a better way of doing things, they may view it as a less worse way of doing things. And that isn't a very compelling sales-point.

Build trust

Especially if you are new, the people in the company may not trust you yet. If you want to propose large sweeping changes you have to make sure that people in your company actually trust you first. The easiest way to build trust is to do a good job (do what you're told on time, with minimum of complaints, and exceed expectations). Once people start seeing that you're good at getting things done, they will be far more likely to listen to suggestions you have to make.

Clearly outline the benefits of any change

Ultimately, someone in management is going to make the decision. In order to help them make that decision, you have to put together information on why your suggestion is the best option. That means clearly listing out the benefits with clear examples of how it will impact the business if they don't change.

For instance:

Prevent XSS

There were 200 XSS attacks on the site last year, which have the potential to steal customer information

Prevent CSRF

Malicious coders could use our site to cause customers to buy subscriptions for other people without their knowledge. Last year we spent $Y on refunds to customers which this vulnerability could be partially responsible for.

Reduce Development Time

Currently we spend X hours/week doing web development for the site. By using tools A, B, and C we can reduce that by 20 man-hours per week, giving more time to work on projects D, E, and F increasing business by $Y.

This will allow management to look at why the site should be changed, and what the consequence of each issue is.

Be prepared to compromise

So let's say you present all the above to management, and management says, "CSRF isn't really a big issue because of X, Y, and Z. But we do need to fix XSS because of the importance of customer information. What's the best way to fix just the XSS vulnerability?"

Your job is not to sell them on the same system, you need to be willing to compromise to fix the problems rather than just pushing to use different technology. Focus on meeting the needs of the business in the best way, rather than the way you want it to be done. After all, you're not currently the decision-maker on this project, and if you want to be given responsibility to decide you need to first show that you can respect the decisions of people who have that authority now.

Business is People

From what I've seen on this site, many developers tend to lose sight of the fact that business is people. No matter how fancy the technology is you want them to use, no matter how objectively good you think it will be for their business, if you can't convince the people making that decision it won't matter at all.

Understand that people have feelings, and that means that coming in and telling folks, "Yeah, you guys are horrible at your job" won't win you any friends.

Communityâ™¦ 1 · Answer 6 · 2017-04-12 07:31:57Z

EDIT, reflecting on more info added the question:

IUC the boss, who is a "good guy" is not the same as the one unwilling to listen and responsible for the overall mess. Did you sit down with the boss, explaining him the problems you discovered? Pointing out that if he goes ahead with sale, he could be easily burned for bad delivery, maybe even attempted fraud? That if they turn out not very happy (for whatever unrelated reason), it would be not hard to find a lawyer who can convince the jury that XSS and other things are considered against "good industry practice". With all kinds of consequences sensible people would like to dodge.

If he's hooked you can even drop in the other part about aged technology and suboptimal progress.

If your boss also refuses to listen, guess you can wash your hands as one tried to turn all the stones. Or maybe he orders a shootout between you and the creator. Where you have good chance to prove your right, if you actually have it. Possibly resulting in switch of positions. And your gaining the task to clean up all the mess. Consider alternatives if you don't like that either...

One way of the golden smile

-- previous answer

It's probably a trick question, but I take it literally: if you're not happy with what happen in your job, leave, and find or found one that aligns with your ways. I'd suggest doing it ASAP, as my experience shows broken things do not repair.

More accurately, if you see the vector of how company, environment, etc moves, it's pretty save bet it will not change overnight in drastic ways. (And if it points negative, the drastic way will likely mean bankruptcy...)

EDIT:
For all those who sit one-sided in the 'irreversible move' camp: staying and wasting more of your time is exactly as irreversible in nature. And not accepting "my experience" on good faith without any proof to foul play is less than nice too. What I write is backed up by 30 years of experience in our industry. It includes several years of fighting exactly these kinds of guys who have good position and no motivation to listen, especially as that would lead to being exposed as one responsible for ton of security foulups and other bad things.

If this site is about pushing for false hope rather than facing the ugly truth in real world, just say so, I'm happy to leave it to you.

Here you can read some on my past, noticing like 6 years wasted for no good reasons like fear and false hopes for improvement. I never get those back do I?

-1 The OP obviously knew these technologies were in place when he/she took the job. This doesn't seem like a sufficient reason to leave even if it can't be changed. — user8365, Jun 9 '13 at 17:47
guess in that case you should -1 the question not the answer for lack of telepathy — Jun 9 '13 at 17:52
Just telling someone to quit as an accpetable answer has been reviewd quite a bit on this site: meta.workplace.stackexchange.com/questions/1692/â€¦ — user8365, Jun 9 '13 at 17:57
@JeffO: though reading it I disagree with your position and action. OP precluded the only way of resolution. What remains is really just the subjective choice. — Jun 9 '13 at 18:11
@jmort253: I didn't think for a moment that there's anything about me. It's about the truth and real help. I agree it's way too easy to give any kind of advice, including bad one, even with best intentions. And the link above has good conversation of pros&cons, with most up answer acknowledging it may be the correct answer. In any case those using advice are responsible to evaluate it carefully. My original answer did not match the form in the problem statement. — Jun 9 '13 at 18:54

user8365 · Answer 7 · 2013-06-09 17:54:57Z

I don't think you have thought through what is involved in recreating this entire website in another stack. Proud of it or not, rewrites cost a lot of time and money. The project lead is still responsible for the site's functioning, so worse case scenerio, he has to know how to fix the site. Just because you don't like the existing code base isn't good enough. Will it take additional amounts to time to make corrections or add inhancements? Start doing some more research to make your point.

Security would be a good place to start. Look for previous breeches or attempts. Depending on the nature of the website, there may be some standards on what strength of security is needed.

Review the current list of bugs and feature requests. You could do a proof of concept in another stack to show how much easier making some of the changes would be. Maybe there is a chance to use a different stack from the one you're using on a completely new section of the website.

Were you given any indication this job would allow you to explore new technologies? Didn't you know what you were getting into? Seems like you should have asked about this during the interview process.

You ignored the essential part with "The guy who makes the decision in IT does not want to listen. He is proud of what he did; he made those websites.". Would be -1 if I were not involved. — Jun 9 '13 at 18:13
Thank you. Let me explain a little bit. The site is actually base on a big system that our boss want to sell to others developers (not in house) which will be terrible for that company since it's not coding well. I personnaly don't care, but since the boss is a good guy and has no idea what's going on behind the scene, I feel bad. It took them 3 years to made this system. In my previous company we did the exact same thing within 4 months using the latest technologies. I already suggest to use "new cool stuff" and fix security issues, but I just got ignored because I'm the "new guy" here — Jun 9 '13 at 20:44
@user1965817 - and if you keep hoping from job to job, you're always going to be the new guy and not have as much influence. Unfortunately, a lot of software becomes marketable dispite the poor design and not using the latest and greatest. — user8365, Jun 10 '13 at 15:53
@BalogPal - I'm not sure you can define someone as "not willing to listen" just because they don't want to rewrite an entire application. It can take time to gain credibility in a new job. Few people are going to build new software with COBOL, but to suggest all apps written in COBOL should be replaced is not econimically and to a certain extent technically sound advice. — user8365, Jun 10 '13 at 15:55

bethlakshmi 70.4k4136277 · Answer 8 · 2013-06-10 14:22:02Z

Love jmac's answer and upvoted, but wanted to leave more than a comment will allow...

Based on the update...

Baby Steps

A project with a serious technology lag in multiple areas can't necessarily address everything all at once. "Burn it down and start again" will seem terrifying given that it took so long to build in the first place. It doesn't really matter that you know it can be done in 3 months, the group perception is that this functionality takes 2 years. And no one ever really wants to call their own baby ugly. :)

Instead, figure a path of least resistance. What's a good first, small change? What could it led to. Don't worry about a 20 step roadmap, find the first 1-3 baby steps. It could be a prototype, it could be coding a single feature in the new way. It could be a first techology replacement - it largely depends on what work needs doing and how the team does the work.

Sell these baby steps, instead of trying to fix the whole thing. You may very well tip a move to a change.

Support the needs of the team

Make sure that the human developer end is supported. New technologies mean new information, new ways of working and a learning curve. Make sure that everyone has the resources they need - a repository to links of helpful information, instructions for changing any processes. Figure that if you do get the trust of the head decision maker, that he'll need special attention to get a chance to learn the impact of this new decision.

Know the market

Know your customer market. While it can be true that ancient technology and horrible design practices won't sell in the majority of market places, there can be cases where it will sell. So before you say "this is horrendous, we'll loose customers over it" - know your customers. Know what their needs are and what their developers will expect.

One of the hardest things to know when you are new to a company is the real business model and the keys to its success. Bosses (in a good case) get promoted because they have become smart at this aspect of the work. I'm not saying you're not right - you may very well be correct. But in big projects, I've seen some astonishing cases of old technology being a must-have for particularly risk-averse customers.

Category

Random preview

Moving to new technologies when colleagues don't want to [closed]

closed as not constructive by Jim G., Michael Grubey, CincinnatiProgrammer, jcmeloni, acolyte Jun 10 '13 at 15:52

closed as not constructive by Jim G., Michael Grubey, CincinnatiProgrammer, jcmeloni, acolyte Jun 10 '13 at 15:52

closed as not constructive by Jim G., Michael Grubey, CincinnatiProgrammer, jcmeloni, acolyte Jun 10 '13 at 15:52

closed as not constructive by Jim G., Michael Grubey, CincinnatiProgrammer, jcmeloni, acolyte Jun 10 '13 at 15:52

4 Answers 4

Executive Summary

Understand the current system

Don't criticize/condemn/complain

Build trust

Clearly outline the benefits of any change

Be prepared to compromise

Business is People

Baby Steps

Support the needs of the team

Know the market

4 Answers 4

4 Answers 4

Executive Summary

Understand the current system

Don't criticize/condemn/complain

Build trust

Clearly outline the benefits of any change

Be prepared to compromise

Business is People

Executive Summary

Understand the current system

Don't criticize/condemn/complain

Build trust

Clearly outline the benefits of any change

Be prepared to compromise

Business is People

Executive Summary

Understand the current system

Don't criticize/condemn/complain

Build trust

Clearly outline the benefits of any change

Be prepared to compromise

Business is People

Executive Summary

Understand the current system

Don't criticize/condemn/complain

Build trust

Clearly outline the benefits of any change

Be prepared to compromise

Business is People

Baby Steps

Support the needs of the team

Know the market

Baby Steps

Support the needs of the team

Know the market

Baby Steps

Support the needs of the team

Know the market

Baby Steps

Support the needs of the team

Know the market

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

4 Answers
4

4 Answers
4

4 Answers
4

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor