What to do as a Dev when for years their team has lacked product innovation, not used project mgmt methodologies, and kept bad Software Dev practices? [closed]

Question

I am interested in knowing how to deal with a current software development process that has not been changed for years and will eventually lead to product and team failure. Yes, probably the easier way to solve this is changing jobs, but with this economy is easier said than done. However, if you have specific examples and have seen or been multiple times in same situation and think that the best solution to address these issues, is to leave the company, then please support your answer. The point is, this question really has an answer especially if multiple experts on the subject end up indicating that the best route to go is : route A.

I know tons of developers have been or are in similar situations. This is one of the main reasons why companies go from being # 1 in their market to becoming last or even off the market. Hopefully the answers in this post will help other developers facing similar obstacles. In a small or large development team this usually happens:

• Some developers seem not to care and decide to go with the flow and prefer to leave code with lots of code smell the way it is and development process as is,
• Others get tired of no change and resign and move to another company,
• Others seem to be afraid to talk and prefer to stay quiet,
• At times very few developers or just one tries to speak up for improvement of product, and tells the team how important is to follow best coding practices and benefits of doing so for clients, users and team. These type of developers usually decide to stay with the team due to reasons such as company offers benefits that very few software companies offer, or the product has lots of potential, etc.

The product in our team is just a fraction of where the company gets its revenue from as it has an umbrella of products (this company is not a software/hardware company; therefore, no constant patent litigation, at least for now, which creates job instability). What I have learned so far during these years from other developers’ experiences and my experience is that to really know a development team, it takes time, not days, nor weeks, but a few months. During the interview process if the team wants to hire you, or needs you; they make everything sound great, and they might tell you what you want to hear. However, the reality is different when you start working in that team and begin digging inside the code and moving towards the complete SDLC process. This is when as a developer, you start seeing the reality of the job you got into. This reality makes it difficult to want to move from one company to another because it is hard to know if the company you move to will be better or worse. Yes, you can read Glassdoor reviews etc.., but how many of those online reviews are real, and not from HR?

What would be the best way to tackle the issues outlined below considering that manager from the beginning has always resisted to change, and previous developers have been doing the same for years?

• Lack of product Innovation for years: Product has lots of potential and brings good revenue to the company, but product looks like it was made 20 years ago. Some users have complained that product is not user friendly nor intuitive, and others have mentioned that are used to apps like Gmail and get frustrated when using the product because of not having similar features. The main issue here is that when you try as a developer to make changes to the product and start to move main elements of product around just a couple pixels away (to make it more user friendly, or intuitive), manager panics, and tells you to put it back where it was. If you try to add a feature that will benefit productivity for users, manager asks you to remove it because of "users are used to doing the process the way it is etc.." I think you got the point of the resistance to change, improvement and innovation (manager is not open to change, even when you as a developer provide strong arguments of benefits). Company has a few competitors in the field (the products of few of them are way more competitive), but somehow the company has maintained the current clients for years.

• Lack of project management coordination: As a result of this, some projects are delivered late, with bugs and some clients complain (clients report the bugs too), or budget is used too fast prior to delivering project etc.. I've provide them a few project coordination tips and the ideas are now being used regularly to track progress of projects and tasks to be done.

• Bad software Development Practices: Code smell is seen on most if not all files, no documentation, code redundancy, front end tier and back end mixed on same file, outdated development tools, no a real testing environment nor test tools (just copy and paste files from dev environment to production, and then test manually that things look good and release) . Most of the development tools I use for development and testing where unknown by team, as team only uses 2 IDEs for code development and source control is only available for development environment. Other developers have tried to use latest frameworks to improve current issues, but manager does not like it because of "what if you leave, then who is going to maintain that code?, let’s leave it the way it is" Some of those developers already left and moved to another companies.

In summary, I am sure similar situations happen to many developers in other companies but due to different circumstances, a developer might prefer to stay in the team than going to another company for reasons like (convenience of job, work flexibility, company benefits, or just because a better opportunity has not arrived). There is not perfect company that I know of, but how would you as a developer behave and approach all these issues in order to keep things positive and ultimately promote change for the improvement of product and betterment of the software development process (whether you have many years of development experience or just a few)? I know this is post is long, but I preferred to give extra details to increase chances of getting more useful feedback.

Thanks a lot for your all your feedback and time

Answer 1

Martin Fowler's quote is relevant: "You can change your organization or change your organization." Given that you've apparently decided to change your organization (make it better) instead of change your organization (work for a different organization), here are a few suggestions.

First, a lot of your course of action depends on details about the power structures and politics at work. Is there one software development manager, or several? If several, are there any of them who aren't change-averse? How many software developers are there? Are the developers interested in changing? If so, there are some changes that you should be able to make even without management approval. (As Fowler suggests in Refactoring, you may not even have to tell management. You're presumably hired to develop software as best you can, so if there's a better way of doing it, then just do it.)

Second, keep in mind that management may have good reasons for what they're doing. You're a software developer; your job is to develop good software and to know good techniques for doing so. Management's job is to understand bigger picture issues and business considerations that may be beyond your purview. Even if you're right and they're wrong about what the business considerations are (your concerns about lack of innovation, late delivery, customer complaints, etc.), understanding where management is coming from will help you communicate in their terms, alleviate their concerns, and so on.

Third (and related), make sure you can speak the language of business. A business is (rightly) not directly concerned with good software development practices; a business is concerned with serving customers' needs and making a profit. (And many businesses will obviously do the minimum needs-serving possible to make a profit.) You'll be more effective at promoting change if you can explain how bad software development practices and lack of innovation will hurt the company's profit or long-term health.

Fourth, changing a company culture from the position of a rank-and-file worker is extremely hard. James Shore (an agile consultant and author) wrote a Change Diary describing his own efforts at doing so. I'd strongly recommend reading the whole thing. A few relevant points:

• Don't try to change everything at once. Find the biggest pain points and start there. Get everyone on board by helping them to see how your changes address those pain points.
• Understand others' perspectives. Shore talks about how the changes he was pushing from a software development perspective were resisted by the project manager because he (Shore) failed to consider how the changes would affect the project manager.
• Eventually, you'll need some support from higher up, even if you're prompting most of the changes yourself. Shore talks about his champion ("somebody I work with who has more clout than me and thinks along generally the same lines I do").

Answer 2

The obvious short answer is to leave the company. Others have already left, and your manager is an active obstruction to progress. If you stay in that position you'll slowly decay (both in morale and skills). Finding a new job isn't always easy, but in this case it is necessary.

Just in case you chose not to leave the company (the first line of your question kind of gave that away):

Does your manager have a boss? If so, how does that boss view the product? Can you (dare I even say it?) go over your manager's head and approach his boss? Don't nag him with technical details, just express interest and enthusiasm in growing within the company. Present tangible ideas for improvements that would measurably affect the bottom line. You might get promoted out from under the obstacle.

Be warned though - while some squeaky wheels get greased, others get replaced. You WILL cause your manager to strongly dislike you. He will hear about this, and he will say unkind things about you to his boss. Tread carefully, but remember - no risk, no reward.

The worst that can possibly happen is that you'll be looking for a new job, which you should be doing anyway.

Answer 3

Sounds like it's time for you to learn about cash cows. Go here and here. And take a look at the Growth Share Matrix. The GSM provides some additional information on why cash cow is a good state to be in.

Investopedia (second link) probably has the best quote in this case.

1. A cash cow requires little investment capital and perennially provides positive cash flows, which can be allocated to other divisions within the corporation. These cash generators may also use their money to buy back shares on the market or pay dividends to shareholders.

As you noted, there are some upsides to being on a cash-cow project.

• It's stable
• A modest degree of new development is guaranteed
• There's always bug-fix work to tackling.

And as you also noted, there are some downsides to those projects.

• It's stable and the code base doesn't turn over much
• New technologies are generally ignored (too expensive to bolt on)
• And things get ... stale.

I once worked on a project where I had many similar complaints as what you've raised. I distinctly remember sharing my concerns about the code base with my boss at the time. His insight wasn't particularly enlightening so I won't share it. But I stuck out the project and truth be told, it was one of the better projects I've seen. No, it wasn't flashy. Yes, we missed deadlines. Yes, I racked up a few death marches from there. No, the code technology wasn't all that innovative but we did generate some amazing solutions.

The problem was me. I didn't have enough perspective to understand what a code base really requires in order to survive. I didn't have the experience to see where the innovation was truly occurring. I didn't understand the market fundamentals that dictated what the appropriate level of funding was for that cash-cow project.

I would encourage you to see this as a learning opportunity to better understand how business works and how you can improve your skills in adapting a product to the business' needs. While the work may not be flashy, the learning potential is high and those skills will stand you well later on in your career. The majority of corporate level development revolves around all of the constraints you just mentioned. The code stinks; things were slapped in place to contain deadlines that had already escaped; many developers are resistant to change.

At some point, you'll still move on from the project. The lessons you can take away with you can be real career making lessons.

Answer 4

I think that this is a really hard problem with no direct solution. Here are some ideas on what you might try doing:

Fear of Change On the subject of changing things for the better I get why management fears change. People are used to things a certain way and if you change it the users will revolt (maybe). Change is a scary things and usually requires a lot of thought and study before done. What you need is data to show that this is better and that users want it. Speaking of gmail you might look into doing something like "Google Labs" where you could enable/disable new features so that users can give them a try. Then hook up some data collection around this to help back up your changes.

Changing the Software Development Process Again change is hard people don't just change because you say there is a better way. I think that in this scenario my best recomendation is to lead by example. Do things that way that you want them to be done and show people how much better it is. Also, and this is key, you need to find the others that share your thoughts. If you can get a few people on board that will greatly help your cause. Once you can show some results then you can approach management about making these changes wider. I find that a top down and a grass roots effort really does help with making changes.

Also on the tools side companies fear upgrading/changing these because they cost money and the results of new tools are not always measurable. My recomendation here is to make your own tools. If you make your own you will save yourself time and do better work. Hopefully people wills start to notice and then want to use them too.

Changing management This is hard and I am not sure how do it aside from being someone who produces results and has their opinion valued. Once your opinion is valued people may start to listen or they may not.

Lastly remember change is hard and takes time. Hang in there and start small and build up.

Answer 5

Your manager probably is resistant to change because he sees no (business) value is changing practices. The business sees no real problem because whatever is asked of the development team eventually gets done and client complaints don't make it to the people that care and/or can do something to ensure a better result. Either that or the business has come to accept the current state of affairs as unavoidable.

If you are going to change development practices, you need to show them that the current state of affairs is not unavoidable. And the only way you are going to be heard is by building a business case showing how the current state of affairs is running up the cost of the product and holding back the revenue potential given another state of affairs.

To build that business case you need to be talking to the product manager of this piece of software. The product manager being the person who decides on the priority of items to be developed based on the business value they represent. The product manager is (should be) the one that can see the benefit and business value of being able to build better software more quickly. (And I do hope it is not the same one as is in charge of the development team.)

The business case needs to address what the effects are on business revenue of:

• Features that are not (yet) implemented that would generate more customers or retain more customers had they been implemented.
• Features that are inadequately implemented that generate customer dissatisfaction and lead to attrition in customers.

The business case also needs to show how current development practices are affecting the speed and cost of developing much needed features:

• How long it takes to make even the simplest changes.
• How many bugs are introduced as a result of developing new features, both in the new feature as well as collateral damage in other features.
• How much time is taken up with fixing these bugs that can't be spent on implementing new features.
• How many support calls are generated because of these bugs and how much support staff needs to spend on these calls.

And of course needs to show how adopting better development practices is going to affect these figures.

You are probably facing the need for a (major) rewrite of (major) parts of the software. Even if you don't, then How To Survive a Ground-Up Rewrite Without Losing Your Sanity is a must read in how to approach these kinds of projects.

Final note: if the product manager isn't interested in all this, you're lost: jump ship.